Code Fork

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:

Fear of Forking, by Rick Moen http://linuxmafia.com/faq/Licensing_and_Law/forking.html

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)