Differences between version 13 and predecessor to the previous major change of Fork.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 13 | Last edited on Saturday, September 29, 2007 5:12:00 am | by AristotlePagaltzis | Revert |
| Older page: | version 11 | Last edited on Wednesday, September 26, 2007 2:23:36 am | by AristotlePagaltzis | Revert |
@@ -1,18 +1,19 @@
# !! A split or divergence in a software project
Projects fork when one or more groups with different visions from the original project team decide to take a copy of the SourceCode and develop it to their own ends. The SourceCode must be sufficiently [Free] to begin with for this to happen.
- Being able to do this is both a blessing and a curse. Halving the number of developers working on the source for a project more than halves the productivity of each group due to the NetworkEffect – a powerful deterrent to forking. However, a fork can also serve to dissolve the tension in the direction of the previously united project, letting each of the forks focus on a particular agenda. In many (maybe most) cases, all but one of the forks eventually withers
and dies
, and the surviving fork pushes onward with a more well-defined vision that has greater consensus. Forking may therefore contribute to the health of a project in the long term.
+ Being able to do this is both a blessing and a curse. Halving the number of developers working on the source for a project more than halves the productivity of each group due to the NetworkEffect – a powerful deterrent to forking. However, a fork can also serve to dissolve the tension in the direction of the previously united project, letting each of the forks focus on a particular agenda. In many (maybe most) cases, all but one of the forks eventually wither
and die
, and the surviving fork pushes onward with a more well-defined vision that has greater consensus. Forking may therefore contribute to the health of a project in the long term.
In rare cases (such as the Beryl/Compiz split or [GCC]/egcs), the projects eventually reunite.
- Well-known examples include:
+ Well-known examples of forks
include:
* [GCC] and egcs
* [Mandrake] and RedHat (I think Mandrake was originally RedHat with [KDE]?)
* [Emacs] and XEmacs, both branches of which continue to thrive to this day
* [XFree86] and [XOrg], where an unpopular change to the licensing terms of the former caused a wholesale defection of developers, distributors and users to the latter
+ * X Consortium and [XFree86], same as previous example, but XFree86 on the other side, and years earlier :)
* More recently, the forking of [cdrkit] off from <tt>cdrtools</tt>, because of a licence change to the latter. It remains to be seen how this one will play out
* [RPM] and RPM5 (see [http://www.linux.com/articles/114339])
Some interesting analyses of the pros and cons of forking are:
