http://www.catb.org/~esr/jargon/html/F/fork.html
A term with its genesis in
FreeSoftware/
OpenSource; it refers to when some of the people using a particular bit of software can't play well with the developers, so they take their copy of the source and start a new project.
"Can't play well" is a little misleading. Forks can occur for experimentation or specialized needs.
The CodeFork Fear
CodeFork is a particularly effective
FearUncertaintyDoubt device, as in "Use our proprietary software. Don't go
OpenSource, then you might have a
CodeFork, and you will forever have to deal with divergent versions." Alternatively, "We can't
OpenSource our software, what happens if there is a
CodeFork? It won't be ours anymore, and we'll die."
In reality, social pressures make
CodeForks rare. Provided the current maintainers are receptive to the community's needs, the project will continue on largely unforked, and any forks that do occur will often die off due to lack of interest. The fear of
CodeForks can become a force on the software maintainer to continue to provide community support and insure that the software remains high quality. This force can act much more quickly and with more strength than traditional market demand in the proprietary software arena.
The programs that haven't had a CodeFork are more visible, because they've survived. That doesn't mean the others are rare
Is it really true that they're rare? There's a few well known examples where they haven't happened (Apache, Linux), but the more-normal lifecycle of a open source program seems to me to be initial effort by one person, the development of a community, no Linus-like figure emerges, and the program stops development having split a dozen ways with a consequent lack of enthusiasm from everyone involved (LiteStep being the one I've looked at most recently).
Everyone who worries about forking should read this essay:
In summary, forking is very rare for social and technical reasons, not that much of a problem anyway (as long as you chose a sane license, and as long as 'forking' hasn't just become another word for 'stealing'), and, sometimes, absolutely required to keep the project as a whole moving in the right direction.
Not necessarily bad
CodeForks are not all bad, either. Often times they are indicative of a real need to take the code in a different direction, often for some experimental use or perhaps to satisfy the needs of two groups with totally different foci. One example is Samba (
http://www.samba.org/) vs. Samba-TNG (
http://www.samba-tng.org/); another long-running multiple
CodeFork is the
FreeBsd/
NetBsd/
OpenBsd family tree.
When the license of the original
SecureShell turned more and more worse, some people from
OpenBsd took the last free version of the
SecureShell and made
OpenSsh out of it. That way there is a free and uptodate
SecureShell again.
The most popular
XwindowProtocol implementation, XFree86, was losing momentum until key developers forked off. Now the development is proceeding healthily at X.org and freedesktop.org.
An important freedom
If you care about access to all the source of your work product (to facilitate reasoning from first principles when inevitable problems crop up at the last moment), and the right to fix any problems encountered, then code forks are an important freedom to be fought for regardless of anyone's opinion on how nice it would be if everyone conformed. This is Freedom 1 on the FSF's definition of
FreeSoftware (
http://www.fsf.org/philosophy/free-sw.html), and an important one regardless of how one might feel about those who advocate universal
CopyLeft.
All the above describes customers pulling projects apart, until they fission into two teams. That's organic.
The bad kind of
CodeFork - the
CategoryAntiPattern - is when your
PointyHairedBoss demands such short time estimates for each feature change that you must leave out the
SharpenTheSaw and
CleanTheKitchen phases; you must leave out turning product parameters into scripts, and you are not allowed to configure
DailyBuilds and keep them oiled. Such a boss would rather you delay integration, and fork the code when the wind blows, and won't learn from the endless repeated bug hunts and
IntegrationHell this causes everyone. Including the customers.
Is it possible to have a
CodeJoin?
- Something like this happened once, when a fork of the GnuCompilerCollection (egcs) was adopted as the "new" official version.
CategorySoftwarePolitics (sometimes)