The IC² might go open source brainstorming thread.

As you maybe read in this thread, Alblaka is considering to make IC² an open-source project with the current IC² team as the main drivers and everyone else has access to the real sources to fix bugs or be able to write addons in a much easier way than before. The big question is how to do that in a way that it is more helping than hurting?

As this is all just a hobby project for Alblaka and team (surprise, they don't get payed for it), a concept must work in a way, that the team does not have more work to do than they currently have. In an optimal world they just put in their ideas and they get magically fixed and improved so we all have a perfect IC² version in the end. This includes things like:
- How to restrict write access to the source in a way that only those who really contribute have it?
- How to check progress and quality of code mostly automatic?
- How to handle code submits which are incompatible or not helping?
- How to manage the whole thing from a technical perspective?
- How can people submit bugs and verify that they are fixed?

As no one is perfect, keep in mind that mistakes in all kinds of form in this project will happen on a common basis and detecting and removing those needs to be included in the idea. Don't expect people to be all without mistakes, you might get surprised.

Repost from the other thread:

Some ideas I had during lunch on how to define the development process in an open source community version:

- Use GIT differently from how you're using it right now (~Alb). It has the wonderful option to create as many branches as you want and merge them together usually flawlessly. This allows people to submit minor changes on a one-per-branch base, without affecting development on other branches. People should do baby-steps here in the beginning as one branch/commit per bug, as I expect the code-base to be volatile once this is really open until the major things have been done.

- In general everyone can pull the code at any time from any branch. This allows devs, wannabe-devs and testers to have a look and maybe give their feedback and input.
- To get commit rights, one must first send in a patch file that is reviewed and if considered accepted, the person is granted commit rights. This is the base hurdle so only those who really want to contribute (and know how to use their tools) are able to request permission. More on the commit rights later.
- For all Alblaka as the Mod-Owner has the last word. Only he may accept feature changes and he reserves the right to reject everything he doesn't like.

There are 3 main branches:
- Experimental: This is where Alblaka (and maybe others) pur in their ideas/major code changes, the "What if?" branch. Only requirement: game must still be playable, as in "doesn't crash too often". Bug-fixes may happen but are not required.
- Development: One a feature or set of features has been accepted, it is put into the development branch. Here all bug-fixes happen and ideas/code might get improved or slightly modified (under the control of Alblaka) with the target to have a fully releasable version in the end. Requirement for all commits is to be compilable and fix bugs/improve code without introducing new bugs.
- Release: Once a development branch has been stabilized enough, it is branched out to a specific release version branch. Once this is done that version is considered released and only bug-fixes that address stability issues may happen to this branch. New features or improvements of existing features do not belong here. There is a minimum delay of 1 month per release, so not every minor change caused server admins the trouble to update.

To sort out those who contribute to the mod and those who rather don't contribute, the Jenkins build system uses a Karma-System (there are several existing plugins for that), that in general gives points to good contributes and decreases those points for bad commits. As an idea:
- Everyone starts with 0.
- Every commit that works fine and fixes bugs gives +1.
- Every commit that works but introduces more bugs that it fixes gives -1.
- Every commit that does not compile or has other very obvious bugs as in "You never tested this even once!" gives -5.
- If someone gets too low on score, his commit rights are revoked.

While the "not compiling" thins is pretty easy to measure (compile fails), the big question is how to detect the amount of bugs added/removed. Tools like FindBugs might be helpful here. On the other hand those only detect coding bugs and not logic bugs. so some kind of human interaction seems to be inevitable.

Other things:
- For every branch there is a thread/mailing list so people can give feedback to the right code and version.
- There should be a standardized way of submitting bugs/requests. The primary focus here is ease of use as I expect more non-technical feedback than actual coders to use it. This doesn't have to be a highly sophisticated tracking tool, even the forum could be a solution, just something that works fine for the task.