Flame Wars, Forks and Freedom

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
    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

    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


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.


  1. dotmil 2005-01-24 8:50 pm EST
  2. M 2005-01-24 8:54 pm EST
  3. Vaporwear 2005-01-24 10:48 pm EST
  4. Smartpatrol 2005-01-24 10:56 pm EST
  5. Thom Holwerda 2005-01-24 10:58 pm EST
  6. pieter 2005-01-24 11:03 pm EST
  7. Sodki 2005-01-24 11:19 pm EST
  8. christian paratschek 2005-01-24 11:55 pm EST
  9. CE 2005-01-25 12:00 am EST
  10. Anonymous 2005-01-25 12:10 am EST
  11. dpi 2005-01-25 1:09 am EST
  12. dpi 2005-01-25 1:24 am EST
  13. David Pastern 2005-01-25 1:43 am EST
  14. Anonymous 2005-01-25 2:47 am EST
  15. Eu 2005-01-25 2:54 am EST
  16. QuantumG 2005-01-25 3:17 am EST
  17. Charles 2005-01-25 7:26 am EST
  18. Zab Ert 2005-01-25 11:36 am EST
  19. Cosmo 2005-01-25 1:24 pm EST
  20. Anonymous 2005-01-25 1:34 pm EST
  21. Xaignar 2005-01-25 2:36 pm EST
  22. Err 2005-01-25 4:47 pm EST
  23. herb 2005-01-25 5:16 pm EST
  24. foo 2005-01-25 5:24 pm EST
  25. hobgoblin 2005-01-25 5:57 pm EST
  26. Anonymous 2005-01-25 10:13 pm EST
  27. HIRE ME!(Smartpatrol) 2005-01-25 10:24 pm EST
  28. dpi 2005-01-26 11:32 pm EST