posted by Vinayak Hegde on Mon 24th Jan 2005 19:44 UTC
IconIn the news media, it is generally shown that flame wars and forks are detrimental to the growth of FOSS (Free/Open Source Software) But if we see the history of FOSS, both flame wars and forks have played a crucial role in determining both growth and direction of important projects. There are also arguments that this leads to fragmentation and marginalization. There is some truth in these arguments but there are a lot of benefits which are often overlooked. This article looks at some of the benefits of forking and flame wars through history.

Why forks happen ?? - A peek at history
There are several reasons why a fork may occur - Here are some examples:

  • A particular group of members is not happy with the further technical direction of the project. An example of this is the recent fork of FreeBSD 4.x code base, by some members of the FreeBSD core team resulting in the formation of the DragonflyBSD project. FreeBSD 4.x had scalability problems and could not make optimum use of multi-processor machines. With multi-processor machines becoming cheap and common in the enterprise space, this problem had to be solved quickly. One of the objectives of the FreeBSD 5.x release was to solve this problem. The programmers who are working on Dragonfly BSD were not happy with the way this technical problem was solved and forked the project forming DragonflyBSD. DragonflyBSD is now focused on providing Single System Image (SSI) Clustering. It also aim to solve the scalability problems of the 4.x BSD series while being robust and flexible enough to run on uniprocessor machines as well as massively clustered machines.

  • Patches are not getting accepted and changes are not being done fast enough. The users/developers are unhappy with the pace of development. This happened some time back with the GCC team. Cygnus (now a part of RedHat) had based it's business around supporting the GNU Compiler collections and had several engineers working on it. The list of patches pending and waiting for the review was getting bigger and bigger by the day. Finally patience ran out and Cygnus forked the GCC project (creating EGCS - Experimental GNU Compiler System), keeping the forked branch itself GPLed as before. After and EGCS branch became the main GCC branch and hence the fork was "healed".

    Xemacs was forked from Emacs as the patches were not getting accepted as fast as some of the developers would have liked. What most people know is that Linux itself almost got forked in 1998 due to the fact that Linus was not accepting patches to his kernel tree as some of the kernel developers would have liked. Fortunately, the differences were sorted out amicably when the threat of a fork was looming large.

  • Another famous fork in recent times was the split. When releasing version 4.4 of the XFree86 Server,the license was changed and most major Linux distributions and BSD variants dumped it for the fork. Before this split could occur, there was another split lead by Keith Packard following several dissatisfaction with XFree86 development. eventually this project was merged with Among the problems he cited in the mail was limited development resources, slow release schedules, lack of co-operation with other projects (notably GNOME and KDE) and opacity of the development process. This story was also covered by OSnews .

Table of contents
  1. "Page 1/2"
  2. "Page 2/2"
e p (0)    32 Comment(s)

Technology White Papers

See More