Forking: it could even happen to you

Code forking has been a popular topic of discussion in the Open Source community recently, ever since a renegade team of Samba developers announced it was packing up its tools and forging a new programming path. Code forking happens when an Open Source development team splits up, with each group taking the code and making changes independently of the others. This is exactly what happened with the Samba project earlier in October. In case you didn’t know, Samba is an Open Source application that enables Linux and Windows NT systems to co-exist on the same network. According to Samba.org, some of the Samba development team was working on a code branch that would provide complete NT functionality.

They went out on a limb and were “using a architecture that differs considerably from the one that has been established in Samba over the last 10 years of development,” according to an open letter published on the Samba Web site and written by Andrew Tridgell, the originator of the core project.

So the team leaders “encouraged” the renegades to take their side job on the road. They did. The new project is called Samba-TNG, which stands for “The Next Generation.”

Tridgell says he is “delighted” that the split happened, and he looks forward to the innovations that the new team will be able to come up with, now that they are free of the constraints of the more established conservatism of the original Samba team.

Just the word causes panic

So, the code fork is no big deal, and things are good in Samba land. But just the mention of code fork in some circles of the Linux community is like pushing the big red panic button. Some of that fear comes from observing the splits that happened with Unix when companies made their own proprietary changes to the OS that weren’t compatible with the core code.

But under the GPL, no one can make proprietary changes to the Linux kernel. Even so, splintering of the kernel is possible, and probably wouldn’t bode well for the desired widespread commercial acceptance of the Open Source OS. And the ultimate fear is that non-compatible versions of Linux would spring up, voiding much of the inherent flexibility of the OS.

But the Linux community should consider its own history before it freaks out over the eventuality of a major code fork. Linux advocates say that the very nature of the GPL encourages the reuniting of forked projects once the branched code is finished.

Bruce Perens, president of Linux Capital Group and chairman of Progeny Linux Systems, says, “When a GPL project forks, each of the forks can take the best code from the other forks, that’s one of the features of the GPL license. Thus, GPL projects tend to re-merge after a fork. Take, for example, the split between GNU LIBC and the Linux LIBC — it went on for years while Linux stabilized, and then the forks re-merged into one project.”

But doesn’t Linux’s lack of a central authority as compared to say, BSD, encourage multiple splintering that could dilute the OS’s power in the software market? Not if you ask Perens.

“Actually, a stronger central authority might be one of the reasons that BSD forks. Linus doesn’t give developers much reason to need to walk off and start their own projects just so that they can get something done.”

So according to Perens, the structure of the BSD license is more likely to cause developer team splits because code has to be reviewed by a core group or director that sets the direction and the goals of each BSD project, whether it be BSDi, FreeBSD, NetBSD, or OpenBSD. This can cause bottlenecking, leading to developer frustration and unfriendly code forks that don’t tend to reunite.

Little forking in BSD land

Not so, says Pat Lynch, senior systems and network engineer for the Open Source Development Network (which owns NewsForge). “Since Net, Free, and Open BSDs were
started, there has been little to no forking. Where there is a need, it is filled, and the community has more of a say in what goes into a kernel. The core team communicates with us, and in some cases we’ve known these people for years.

“Recently, FreeBSD elected a core team membership from amongst the developer community. If anything, it is less centralized, and not dependent upon one person [like Linux is dependent upon Linus Torvalds, the creator of the Linux OS]. Linus Torvalds is not a god and can make mistakes … Bruce is blinded by the zealotry that Linux evangelists generally have these days.”

But does Torvalds even claim to be the god of Linux? “Linus actually has no say over what Linux distributions do at all,” says Perens. Which could be a detriment when it comes to the perceived risk of code forking, since anyone can do whatever he wants to with the code, as long as it complies with the GPL.

But Perens says, “If other developers did not like what Linus does, they would not stick with him.”

Hold on, guys

Richard Rauch, Open Source advocate and student at the University of Kansas, takes a more neutral approach. Although BSD accuses Linux of many forks, and Linux does the same to BSD, according to Rauch, they’re both right.

“BSD has forked the kernel several times, with each fork
persevering—but has only forked the overall OS about as many times as
the kernel. Linux effectively has one kernel, but to make a complete OS
it needs a distribution, and distributions are a kind of ‘whole OS
fork’, and so the Linux operating systems can be seen as heavily,
persistently forked.”

And Rauch is all for forking. “Personally, I think that [it] is a good thing.” And he points out that Perens and Lynch both seem to feel that diversity is good. “Perens speaks
of the forks sharing the best features; Lynch speaks of cross
pollenation. And, kernels benefit from diversity as much as anything
else.

“The question then, isn’t to fork or not to fork; it is how much and what.”

Author’s note: I am available to respond to questions, comments, and criticisms. Please post your thoughts in our discussion forum –TG.