The conversations about OpenOffice.org and LibreOffice these past few weeks have put forks on my mind lately.
There are two long-standing opinions about forks in the FLOSS community: they weaken projects or they strengthen projects. There are interesting arguments on either side of the debate, but if history is any judge, there is a strong trend: the project that forked away from the mainline project tends to be the ultimate survivor.
If that trend holds true, then it will be LibreOffice that will last, not OpenOffice.org.
Take, for instance, GCC and its fork EGCS (commonly pronounced "eggs"). For those of you not familiar with these technologies, GCC is the GNU Compiler Collection, a free compiler developed by Richard Stallman in the mid-80s for the GNU Project. GNU has been described as everything an operating system needs except a kernel, so it was a perfect fit for young Linus Torvalds' Linux kernel project in 1991. Like Reese's peanut butter cups, ("you got my kernel in your libraries!"), it was two great tools that went together to form the operating system known as Linux, or GNU/Linux, depending on who you ask.
In 1997, about twelve years after the initial version of GCC was released, GCC development reportedly had slowed down to the point where work on the next iteration of GCC, GCC2, was frustrating to many of the GCC players. Among those players was Cygnus Solutions, the commercial vendor co-founded by Michael Tiemann (who would later land at Red Hat after the Linux company acquired Cygnus in 1999.
In fact, it was Cygnus and the Free Software Foundation that jointly started GCC2 development in 1991. But Cygnus and other players on the project, such as Linux, pgcc, and Fortran developers, were getting upset with all the work they had done not being included in the GCC2 tree. This led to a lot of acrimony on the GCC2 mailing lists and a general desire that it was time to take the code and do something else. Thus, EGCS was born.
This was, by many accounts, a painful fork. EGCS development, backed by a newly energized community, exploded. Meanwhile, GCC development would languish from a lack of impetus and manpower. Just 20 months later, in the spring of 1999, the original GCC project was effectively dead, when EGCS was renamed to GCC and the old GCC development was taken over by EGCS.
A similar set of events occurred in early 2004 when XFree86 developer Keith Packard was kicked out of the XFree86 core team after trying to start a fork of the X Window implementation that provides graphical interfaces for UNIX- and Linux-based computers. After his departure from XFree86 project, Packard would call for a more open system of governance and an X implementation that would have a more GPL-friendly license rather than the BSD-like license XFree86 had switched to earlier that year.
The result would be a community revitalization in the pre-existing X.org Project, another X Window implementation that had some backing from then-Sun Microsystems' Solaris and a few other Linux distros. By April of 2004, Red Hat, SUSE, and Debian GNU/Linux had thrown in their lot with X.org, and IBM, Sun, and HP were sponsoring the X.org Foundation. XFree86's last release, 4.8.0 was released in Dec. 2008.
The same thing happened, essentially, in 2007, when the developers of KDE's KHTML project would elect to integrate existing KHTML development into the forked project Webkit. This move came after then-Trolltech announced it "was working on bringing Webkit into Qt proper which has encouraged KDE to play its hand. The decision had to be made as to whether to stick with the home grown KHTML, or move to Webkit, KHTML's fully grown offspring."
Like the other examples I've mentioned here today, it would be the child project Webkit that would ultimately survive, with the parent KHTML merging into it.
Not all forks lead to the death of the parent project. Just look at any version of the GNU/Linux distro timeline to see that. Debian GNU/Linux, one of the earliest distros, still lives, as does Red Hat and Slackware. (Though Slackware's parent, SLS, is no longer with us.)
Nor do all forked projects succeed. I'd list some, but they're a bit hard to find seeing as how, you know, they're dead.
The difference seems to be initial impetus: how much energy is in the initial launch of the fork?
Newtonian physics can help illustrate this. If a rocket has enough thrust to achieve escape velocity, then off it goes to the depths of space. Or maybe it's slower and just achieves a stable orbit. Or too slow and crashes into the ground.
In this metaphor, the rocket, which is the forked project, will take energy from the parent project. If it doesn't get enough energy (in the form of talent, community passion, motivation, etc.), the child may fail. Or, as in the case with so many Linux distros, achieve a nice stable orbit with the upstream parent.
But when there's so much energy and so much passion in the child project, the laws of energy conservation dictate that this energy would be removed from the parent project. It it happens fast enough, sucking the parent project dry before it can recover and get energy from somewhere else, the parent project will die.
Rob Weir argued this week that forked communities are not a zero-sum game, and that the success of OpenOffice.org will not mean the death of LibreOffice. He's right and he's wrong.
If each project can find enough energy (again, we're talking resources, passion, motivation here), they can mutually succeed. In the broadest sense, Weir is incorrect about his views on zero-sum. The laws of conservation mean that everything is a zero-sum game. (It's actually worse, since we live in an entropic universe, because no one gets out alive.)
Weir, however, has also realized that the OpenOffice.org/LibreOffice ecosystem (unlike my simple rocket metaphor) is not a closed system. In physics, open systems mean energy may be obtained somewhere else. Weir believes the marketplace can provide each project with the energy it needs to survive. That idea has merit.
It may come down to timing. If history were the only factor here, it would seem LibreOffice and The Document Foundation have enough energy, momentum, and passion to suck the life out of OpenOffice.org and bring it to an end, if OpenOffice.org does not have a chance to recover fast enough. That may still happen, particularly if OpenOffice.org and its sponsors can't tap into the energy of the marketplace in time. In this scenario, it's OpenOffice.org that should be worried about resources, not LibreOffice.
But by shifting OpenOffice.org into the Apache Software Foundation, Oracle (and IBM, who also backed the move) may have done the one thing that could ultimately save OpenOffice.org in the long term. By connecting with Apache, OpenOffice.org is essentially "refueling" with the energy from Apache. It gets governance, commercial sponsorship, and perhaps manpower from those who prefer to work in Apache-space. If this works, it should be credited as a brilliant move, because it will have bought OpenOffice.org time to heal from the sharp breakaway of LibreOffice.
Now we wait and see the results of this fork and how, when, and where the energy ends up. Balanced mutual success or the end of parent or child?