Parallel forks [LWN.net]

The free software world generally sees a fork in a development project as a bad thing. The ability to fork is a crucial freedom, but the exercise of that ability is seen much like initiating a divorce. Sometimes it is necessary, but it is rarely an event which brings joy.

Little attention, however, has been paid to the idea of a parallel fork, which we will define as a fork which continues to follow the changes in the original project. The Linux kernel has been the subject of large numbers of parallel forks over the years; distributor kernels, architecture-specific trees, and development trees have diverged widely from the mainline kernel and each other, but they also track the updates to the mainline. Projects which are patched by distributors (such as cdrecord) can also be seen as parallel forks. Yet another example might be Sylpheed-claws, which functions as a testing ground for bleeding-edge Sylpheed features. Parallel forks can be the best of both worlds: they retain a tie to the original project, but also are responsive to whatever forces created the fork in the first place.

A parallel fork worthy of some attention is ooo-build, a version of OpenOffice.org maintained by the folks at Ximian. Version 1.3.0 of ooo-build was announced on August 18. This fork was motivated by several issues, which are explained in depth at the project web site. What it comes down to, however, is that the OpenOffice.org process is slow, bureaucratic, and difficult for outsiders to contribute to. As the web site says, "this is no way to create excitement and provide fast problem fixes." So ooo-build was set up as a place where would-be contributors can get their changes in quickly and, with luck, see those changes used and possibly propagated back into OpenOffice.org.

What does the 1.3.0 release offer?

This package contains Desktop integration work for OpenOffice.org, several back-ported features & speedups, and a much simplified build wrapper, making an OO.o build / install possible for the common man.

There is a detailed list, which includes a number of bug fixes, GTK+ and KDE file selector support, Lotus 123 importing, improved icons, and much more. Oh, and the obnoxious business where OOo calls your file "modified" every time you print it has been fixed.

The ooo-build parallel fork is a good thing: it brings the notoriously unapproachable OpenOffice.org development process closer to what the rest of the community expects to deal with. It can be a useful staging ground which gets new features to users quickly, and enables stability testing which can help smooth the eventual merging of those features into OpenOffice.org. It is not the sort of acrimonious separation which normally comes to mind when the word "fork" is mentioned; it is, instead, more of an impedance matching mechanism. ooo-build should result in a better OpenOffice.org experience for everybody involved.

(Log in to post comments)

There's a perfectly good reason for this

Posted Aug 19, 2004 6:59 UTC (Thu) by lacostej (subscriber, #2760) [Link]

I agree with you and I don't like the word parallel forks.
But the word branches is really generic and is used to talk about very different things.

I would have preferred something like "synchronized branches" or something that retains the word branch while adding the idea that these are longed lived branches. Maybe parralel branch if the word is to be taken from the article.

In fact there are even different ways in which these forks/branches are made:
- every now and then, a new branch is made and the collection of patches maintained localy are updated then applied onto that new local branch
- or the branch is created once and maintained. For each release the updates on the trunc are ported onto the branch.

Most projects probably pick solution 1

I would think that a parralel branch/fork would better describe the solution number 2. I don't find a good expression to identify solution number 1.

There's a perfectly good reason for this

Posted Aug 20, 2004 9:06 UTC (Fri) by jdthood (guest, #4157) [Link]

> I don't like the word parallel forks

I do. Parallel lines don't diverge.

There's a perfectly good reason for this

Posted Aug 19, 2004 7:14 UTC (Thu) by mathijs (subscriber, #4948) [Link]

fwiw, I'd say a branch denotes a fork which is maintained within the same version control system. It doesn't seem that unsensible to coin a new phrase for forks which behave a bit 'branchy' ;)

Parallel forks

Posted Aug 19, 2004 11:20 UTC (Thu) by zooko (subscriber, #2589) [Link]

Consider history: XEmacs has been copying source code from Emacs for what -- ten years or so?
(Emacs doesn't take source code back the other way because they want copyright for the FSF.)

I would be sort of surprised if parallel forks weren't the most common kind. If the two projects
are really going in different directions then I could see non-parallel forks, but does that actually
happen in practice?

I think a common result is that one prong of the fork dies or remerges. Remember how egcs
gave gcc a kick in the butt that popped it past the gcc 2.7.2.3 blockage into gcc 2.9x?