My own experience with forks is that they usually end in more work than needed, confusion amongst the users, and more difficult bug and issue tracking. But maybe using a DCVS magically solves all of this ? Remember the core developper team is a small one. Tracking patches is already one of the big tasks, and the goal of the switch is to make it take less time. Increasing the amount of patches to handle is not going in that direction. Maybe the easier merging makes up for it ; maybe it doesn't.But forks aren't really a bad thing... that's more or less what happened with Android/Linux, and I certainly don't see it as a bad thing. Sure, there are some Linux people who are annoyed that they can't easily merge Android changes back to Linux, but I think it just sounds cranky. They chose a license which allowed it, and then they created artificial barriers to accepting contributions back, so what would they expect? Haiku, in some ways, does the same - setting a somewhat high bar for contributions - so we should anticipate (and welcome) forks. This is a good thing! If someone produces a very good fork, and the project recognizes their work as valuable, they should be welcome to merge their changes back to the master repo directly. If they choose not to (for whatever personal reasons), then it becomes the onus of Haiku's developers to do it if they wish to use the code. How is that really any different than the current situation? I think the difference is that we'll see a lot more people participating on the fringes than we do now, and more people working with Haiku code, modifying it, deriving from it, and improving it cannot be a bad thing. As long as we use a strong-enough trademark policy, we shouldn't fear someone trying to create their own "Haiku" branded operating system...
Anyway, the current process for contributors is as follow : a checkout the source b hack around and get something fixed c use svn diff to create a patch d create a trac account e report a ticket and attach the patch to itThe way I see it, a DCVS replaces c with something else. When using a dcvs alone, people have to either make a patch (which loses the point), or set up a clone of our tree somewhere else so we can get the data. This is not easier for them. Using github, this same step is replaced by :
* create a github account * create a fork of haiku on github * submit the work to it. On the contributor side, this still isn't as simple as "svn diff".It may be interesting, if it also replaces steps d and e. But Idon't know if it does. Does github or gitorious offer a way to trac the forks that were made from Haiku ? If so, how do we know which ones are ready for merging in the mainline Haiku ? Are they ready ? Are they meant for us ?
These are the questions I worry about : I'm ok with switching to a DCVS for the ability to work on separate changesets, to do more things locally before commiting to the central repository, the easier branching and patch tracking. Enough discussion was spent on that, and it's getting sorted out. Switching to a service like github, however, means a lot of changes, and I wonder if we can handle it with our long quality review process and our small developper team. Maybe we can first switch to a DCVS, then later see if we need to do more ?