Editor's Note: Stick a Fork in It?
The Linux kernel, Wine, and Samba
There's been a frenzy of gnashing teeth among the hardcore Linux users recently over the issue of code forking, especially as it relates to three rather high-profile Linux projects: embedded Linux, Wine, and Samba.
Code forking, for those who didn't read last Monday's LinuxPlanet editor's note, is what happens when someone takes source code (which, in the Open Source/Free Software ethos, is always available), makes changes to it, and then proclaims that their project is an equal to or improvement on the original. And let's face it: the Linux kernel, Wine, and Samba code have already been forked: the different strains of embedded Linux represent code forks, Corel has certainly forked its version of Wine, and most recently a potentially troubling fork was unveiled in the SAMBA field.
I'm of the opinion that while code forking in and of itself isn't necessarily a bad thing, it can lead to a lot of wasted effort (time that could be spent developing ends up being wasted through postings to nasty flame wars in discussion groups) and at worst cripple essential projects. I think we can all agree that embedded Linux is A Good Thing and doesn't represent a threat to the main Linux kernel: no one is going to grab a version of embedded Linux from MontaVista or TimeSys and expect to run it on their PC. While I'm not entirely sure anymore that embedded Linux represents the future of Linux, the forking of Linux in the embedded world certainly doesn't bother me.
Now, Wine and Samba are different. Last week I told you about the forking that went on between the Wine developers and Corel: the Wine developers incorporated Corel's additions into the main Wine tree, but Corel didn't incorporate the Wine developers' additions into the Corel Wine fork, leading to a situation where it could take months to merge the two. It is very possible that Microsoft will officially endorse the Corel fork for those wanting to port Windows apps to Linux, leading to a situation where the main tree becomes irrelevant. This is an important project: giving developers the tools to easily recompile their Windows applications for Linux puts Linux on a more even footing with the behemoth from Redmond, so this situation needs to be monitored closely.
And then we have the forking of Samba. I've always argued that Samba is the stealth fighter in the Linux arsenal. Because Samba allows Windows users to print and serve files from a Linux box, this makes Linux the perfect replacement for a Windows NT server on a network (Windows NT is known for being particularly inefficient when it comes to file and print services), and once Linux enters an office or enterprise, it tends to expand in usage over time. Samba is an essential tool for Linux viral marketing.
So when a group of Samba developers last week announced that they were embarking on the development of Samba-TNG , an ambitious project designed to bring new functionality to Samba, the initial response in the Linux community was horror at the possibility that Samba would be forked beyond recognition.
I think that this horror is truly misplaced. The Samba-TNG development team freely admits that it doesn't expect to ever release a freestanding version of Samba-TNG; instead, its work is designed to be incorporated back into the main Samba tree. Secondly, Jeremy Allison, a key member of the Samba team, went onto Linux Today to endorse the Samba-TNG project, saying that he didn't expect any issues to rise out of the Samba-TNG project.
So there you go. In the end, code forking in the Linux community isn't always a bad thing. I think the key to evaluate code forking is through looking at the players involved. In the case of embedded Linux, you have a group of embedded systems specialists who have bought into the Linux ethos and seems genuinely committed to working with the larger Linux community. In the case of Samba/Samba-TNG, you have a clear set of goals, and the principals involved have been active in Samba development and are genuinely committed to the best Samba possible. So in these two cases, the issue of code forking isn't so serious.
Now, in the case of Wine, I am not so sure. The presence of Microsoft in the equation always leads one to look at underlying expectations; what Microsoft wants isn't necessarily what the Linux community wants or needs, and the fact that Corel has aggressively moved ahead with its version of Wine and is now the "official" vendor of Linux technology to .NET leads me to wonder how committed Corel is to the Linux community. I certainly hope that the Microsoft/Corel tandem won't take Wine to places where it shouldn't be--or made so proprietary that it can never be merged into a single tree--but when Microsoft is involved, you just never know.