In 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 X.org/XFree86 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 X.org 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 freedesktop.org. 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 .
Benefits of forking
Forks spur competition. It is a bit like evolution. In nature, a new species
survives if the differentiation from the dominant group gives it an advantage for
survival in a hostile world. That is why the dinosaurs died out and the mammals
survived. Being big and powerful is not as important as being able to adapt to
changing conditions. Most of the time open source software succeeds, it is because
the end users are included in the process of building the software and making
decisions. It is inevitable then at some point there will be a divergence of views
and a decision has to be made. Sometimes it is not possible to make the right
decision as one does not have all the information and/or one’s past experiences
have led to a certain opinion (which may not be necessarily right according
to others). This is fertile ground for a flame war and a fork.
Usually, it is possible that the fork will survive if it solves a pressing need
which was overlooked or addressed insufficiently by the core group.
Also in open source, after forks if one group is innovating more than the other
and taking the right decisions, it will also attract the userbase over a period
of time. The source code being freely available means one group can borrow ideas
from another. So the best ideas get replicated across the forks. Often it is also
seen that a particular developer is part of one or more projects (forks).
As many forks want to retain their own identity, there is more innovation for
differentiation from the other forks. Innovation is also due to the demands of
a specialized userbase (example – cryptographic implementations in OpenBSD
and implementation of ssh – OpenSSH). Now this leads to a positive feedback cycle
– all the good stuff gets picked up by everyone and everyone is free to experiment
more. An example in case are BSD variants – FreeBSD, NetBSD and OpenBSD. FreeBSD
and NetBSD use OpenSSH that has been developed by the OpenBSD team. The NetBSD
Packages collection pkgsrc has been ported to both FreeBSD and OpenBSD.
Forks also bring to notice some pressing need of the community when the lead
programmers/core team ignore them. Even Richard Stallman agreed to pursue the egcs
fork of gcc as the main branch for further development. Forks can sometimes be
“healed” and the codebases merged. The GCC/EGCS example above is a case in point.
Forks provide an opportunity for them to serve a specialised purpose while
being able to incorporate changes from the new branch.
It is possible that forks may hurt large corporations which like to be able to
control the direction of the product. This is the reason Sun will not release
Solaris 10 and Java under a OSS license. If at all they release the source
it will have some kind on a non-forking clause. Forks are always beneficial
to the end user in the long run, though they might cause a bit of pain initially.
Imposed control rather than concensus is central to the way big corporations
operate but not the way a good team of hackers operate. This is due to the
cathedral and bazaar model of development as described by Eric S Raymond.
Flame Wars
More often than not flame wars are precursor to forks – an indication that
all is not well within the project. Flame wars can also happen if a radical
new design or a drastic change to the project such as a license change or
replacing a subsystem with a better one. Flaring opinions and bruised egos
can damage the project but also enhance the project by hammering out new
ideas in a public discussion (because the discussion is public also means
the stakes are high). Bureaucracy and forced conformism
is detrimental to the growth of a project. But this is the way order has been
established in traditional companies. Flame wars and discussions are central to
the development of OSS to explore different design issues, but they also
harbor the potential to destroy the camaraderie in a project. It is
important that they be taken in the right spirit or the whole project
suffers. The reason why flame wars have got a bad reputation are they often
get political and personal. But flame wars can also bubble up
“thought leaders”. If a guy makes a convincing argument and backs it up
with working code he will definitely win the confidence of the community.
Linus Torvalds was involved in a famous flame fest with Andrew Tanenbaum
over the design of the Linux kernel and also licensing considerations.
Tanenbaum brushed aside Linux saying
“Linux is obsolete”. But Linus held
his ground and Linux moved from a toy kernel with few users to an
enterprise operating system which companies like Sun, IBM and HP have
adopted.
Conclusion
In the short term they have the disadvantage of dividing the teams and
sometimes can lead to a lot of duplicated work.
Flame wars and forking are not bad but inherent to the way Open source
software has been designed. As long as they are done for the valid reasons
and not due to political or personal reasons, they will thrive.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
Excellent essay; easily one of the best on osnews in some time. Very interesting points brought up here, and very valid ones.
I don’t condemn forks that lead to fragmentation. Actually, inspiring myself in one of the evolution’s theories (Darwin’s one) I got to realize how important these are to select who are the best evolving the product, according to users needs. Take, for instance, the XFree86 project and the fork that lead to X.org. Now, the one that will survive (considering no one more will come) is, most probably, the best.
No doubt, especially considering Tanenbaum has an OS that is only useful for educational purposes to show for his efforts and teaches at the University of Whosawhatyamacallit. If he was at M.I.T. or Berkeley, he might have some ground to stand on while he’s talking down at people.
From what i read Linus hadn’t relaized that linux had grown bigger then himself and that in order for it to be sucessful he would have to ease up on the reigns or lose it all.
You guys are dissing Tanenbaum but you have no idea what you’re talking about.
Without Tanenbaum, Linux probably wouldn’t even have existed in the first place. Secondly, the University he worked/works for happened to be my univerisity as well– It’s the Free University Of Amsterdam. Amsterdam has been around waahaay before any brick was put on its side in the US, so show a bit more respect please. Afaik, Linus never worked at a University at all so I don’t know why you are bringing it up.
Anyhow, the discussion between Andy and Linus is quite interesting; I read it from A to Z for my article on QNX, and I must say it was a learning experience. I, myself, am a strong supporter of muK(-based) designs– No wonder my fav. OS’s are all either true muK (QNX) or muK based (BeOS/OSX).
Oh and lastly, if you would’ve actually read the whole Andy-Linus thing, you would’ve noticed that Linus himself also makes gruesome errors in judgement. Find in that discusion what he thinks about the future of the Intel platform…
Now, kids, please don’t comment on matters you know nothing about.
I like both emacs and xemacs, (fork)
have respect for both the creator of
minux and linux, (flameware)
yet I never looked deep into the way
of thought that you pointed out,
one of the best reads!!!
#3 Linus produced an OS that not only has a variety of uses and is available to the whole world for free, but which even Microsoft has said they consider a threat.
Linux did produce a kernel, not an OS.
…and teaches at the University of Whosawhatyamacallit. If he was at M.I.T. or Berkeley, he might have some ground to stand on…
whoa, now that’s a retarded statement. learn some geography, then some history, and a little respect, ok?
@thom holwerda:
linus actually did work at a university, back in finland, in helsinki. he did that around 1994-97, then moved to california to work for transmeta.
christian
The kernel produced itself?
This quote from the article concerning the Linux kernel doesn’t sound like an endorsement of forking- “Fortunately, the differences were sorted out amicably when the threat of a fork was looming large.”
It’s the Free University Of Amsterdam.
Minor nitpick here Thom but its the Vrije Universiteit of Amsterdam (aka VU) whereas ‘vrije universiteit’ is Dutch for ‘free university’. Its a name.
Tanenbaum did an interesting analysis on the 2004 presidential election btw. Available at http://www.electoral-vote.com
Vaporwear apparently has reasons to believe Tanenbaum runs a bad class or something. Where’s your proof ‘Vaporwear’, other than you allege MIT or Berkeley having a ‘better name’ than VU? Stallman worked at IBM and MIT (on AI related projects). You must admire him as well, huh? *g*
As for microkernel versus monolithic kernel… here we go again! At least Hurd are slowly switching to L4
.
#3 Linus produced an OS
Ohhh… you’re the reason RMS whines about GNU/Linux
Torvalds started developing Linux, a kernel. He got help from thousands of other developers hence he didn’t do the kernel development alone. However, as noted before, he started it.
Stallman -also with help from others- basically developed ‘the basis for Linux’ which is aka GNU but, was missing a kernel. Stallman had compilers (fortran, c, c++, asm, etcetera), a text editor, a shell, and many other utilities ready but they were still busy with a microkernel called HURD. However, history turned out it wasn’t finished yet whereas Linux was — and Linux took off. GNU, without HURD but with the Linux kernel, was used in the first Linux distributions such as e.g. Slackware.
Linus Torvalds never ‘produced an OS’ and Richard Stallman never developed ‘Linux distributions’ — which are what we nowadays use as OS when we refer to “I run Linux”. What both arguably made is valuable contributions to Linux distributions as we know it — not only code-wise. Nowadays neither of the 2 icons ‘produce an OS’. They’re both trying to contribute to the F/OSS community though. Stallman with maintaining Emacs and advocacy; Torvalds with maintaining Linux 2.6 vanilla tree and developing for it.
PS: If you’re in the ‘microkernel is slow’ camp try something else than MACH.
A couple of points – Linus, whilst disagreeing with Andy, and the way he thinks that a kernel should be developed/operate, has a LOT of respect for Andy. And that respect is vice versa as well. Secondly, Andy has been a very very very well respected voice in kernel design for many years, and has taught many classes on the subject. So, vapourware, a bit of respect please. Thirdly, the US isn’t the only country in the world that has universities, or has really good universities, as others have pointed out there are European universities that pre date colonisation of the North America continent by Europeans.
Microkernel vs monolithic kernel – each to their own. Andy favours micros, Linus favours mono. Both have negatives and positives, but the important thing is that they both work, and can work very well. There are many ways to skin a cat.
Forking – it’s a solid form of evolution. Look at sendmail. x.org is doing it now, and doing it very well, we’re getting real improvements to X. The beauty of open source is that the src code is open, so anyone can fork a project if they have the technical know how and desire. If it’s a job well done they’ll be successful. Closed src does not allow this forking. It’s so heavily controlled and rigid it isn’t funny – and that is not the way that nature works.
Dave
Great comment Dave!
One of the most informative articles in a while. Given the poor writing often found in this site, your article really is a refreshing read.
It is clear that forks or the possibility of one are part of the democratic decision making process that is inherent to open source development. While the discussions can be tense and frivolous forks are not to be welcomed, good forks often do more good than harm.
Let’s not forget the ultimate reason to fork: your vision for the software is different to the current developers. I’m interested in starting a fork of an open source project. Planeshift (www.planeshift.it) is an open source MMORPG engine that is currently being deployed with proprietary art. The result? Only the Planeshift team can run a Planeshift server. Improvement of the Planeshift “world” is also strictly controlled. My vision for Planeshift is a world where trusted users are free to add new objects and extend the world easily. Of course, there’s also the little issue of Planeshift requiring all contributors to assign their copyright to the Planeshift legal entity — something very few open source projects require and most open source developers find distasteful. I wrote a rant about that: http://rtfm.insomnia.org/~qg/planeshift.html
I and some others are slowly gathering a free art package. If you’re interested in contributing, please drop me an email.
Forks happen frequently in major projects. The Linux kernel currently has 3 major forks – 2.6, 2.4 and 2.2. Apache httpd has 1.3, 2.0 and arguably 2.1. MySQL has 4.0, 4.1 and the upcoming 5.0. Php is maintaining both 5.0 and 4.3. Etc. These forks are maintained separately for the very good reason that the current userbase need stability.
At the same time developers need the space to temporarily de-stabilise the codebase, leaving a local maximum of stability vs functionality with the expectation that they will deliver better functionality (or better design that will allow them to later provide better functionality) and eventually reach the same level or better of stability.
Hostile forks are usually similar but with a flamewar accompanying the decision to fork.
THIS is the kind of article I read OSNews.com for! Excellent!
> Nobody will ever show you respect with comments like that. Don’t even try to compare
> your little school…
why don’t you get even more arrogant?
This is a well written article. Good job Vinayak Hegde.
However flamewars are not only a precurser to forks, depending on the way the forking happened, they can be a common occurance afterwards.
The particular OSS project I work on (aMule) seemed to fork without flamewars beforehand, instead only a simple disagrement between the lead developer and a new developer, however the relationship between the two projects quickly became rather sour. There is still pie-throwing from both sides even now around a year after the fork was made.
It is however interesting to note that even though there wern’t any flamewars before the fork happened, the relations within the project were definetly bad, as the fork resulted in almost every single developer from the old project migrating to the new project, with the exception of the lead-developer.
Let’s not forget the ultimate reason to fork: your vision for the software is different to the current developers.
That might be the ultimate reason, but ego clashes and refusal to compromise are right up there near the top of the list.
***
Nice of some folks to completely overlook places like India and Japan when they start discussing computing R&D.
What has more impact on your life? *nix or Tron?
Hint: It ain’t *nix.
Using evolutionary analogies may seem helpful, but are actually limited. Open source projects don’t reproduce, nor do they have genes – the projects are run by humans not genetic code.
Sometimes it seems that competition helps projects such as having a few different window managers to choose from (KDE, Gnome, XFCE), but sometimes cooperation is much more helpful: using the same X11 system, standardizing Openoffice.org and KOffice on the same file specification, or using a standardized x86 architecture (Intel, AMD). Sometimes forking is helpful if the original project leaders are incompetent, but it isn’t always helpful that the fork stays forked as we saw that the gcc fork was absorbed again.
I think the real lesson here is that having FOSS licensing makes both forking and cooperation much easier.
re: universities… pen-is mightier
re: the article. Solid stuff. The other posters were right, this is a good read.
“Nice of some folks to completely overlook places like India and Japan when they start discussing computing R&D. ”
Funny how that is. I call it cultural myopia.
rember that both genetic code and computer code in the end are just strings of signals (zeros and ones in the case of computer code). all the sicence are where they are today tanks to people putting to paper their theorys and formulas, without being protected by copyrights and patents that stay in effect long after they themselfs are gone. its a share and share alike enviroment. but allso a enviroment where people compete for the glory of being the first person to figure something out. while glory dont put food on your table, it will most likely land you a nice job somewhere as people know what your capable of
yes standards are important, but forks help with transfering new blood into what at the moment is a evolutional dead end. if the old branch still have life it most likely will be absorbed. if not it will die of and the younger branch will continue to grow. this is why people keep compareing it to biology. standards create a enviroment for this to happen, a enviroment of common ground. what would happen if say the sheep held a tradesecret on the concept of eating grass? or maybe a copyright or patent?
If the reason for Sun not making Java and Solaris open source is, it can lead to forking, can QT be forked and what are consequences for Trolltech?
The Linux kernel currently has 3 major forks – 2.6, 2.4 and 2.2.
I would not consider these forks Linus and friends moved on other took up maintaining older kernels. The logical upgrade path is 2.4 -> 2.6 in comparison of a true fork you would not upgrade from FreeBSD -> NetBSD (although some might consider it an upgrade =P )
What has more impact on your life? *nix or Tron?
Hint: It ain’t *nix.
Its not so simple. You compare a mass implemented, embedded architecture with *NIX; that’s apples with oranges. Besides what does that have to do with the subject?