|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Monday, 16 October 2000||Author: D. Clyde Williamson|
|Published to: featured_articles/Featured Articles||Page: 1/1 - [Std View]|
The Right To Fork
Last week, the Samba codebase forked into two factions; Samba (the original) and Samba TNG (the new). Clyde Williamson has written a fantastic piece about the forking process, and I'm proud to present it as this week's Weekly Feature. Enjoy!
If you're somewhat new to the idea of Free Software, you may need a bit of explanation, so let's look at some of the Free Software 'Ground Rules.'
The reason for the existence of any program (Open or Closed) is that it fills, or attempts to fill, a need. In the closed source world, the need is determined by a research group in a corporation. They may interview a group of targeted users or they may know of a specific need and write software to fill it. Unfortunately, this means that by the time the company talks to the users, writes up the 'requirements document', sends the document to the developers, gets the code written, tested, debugged, tested, and finally boxed, the users needs have changed.
In the closed source world, if there is a subset of users with different needs, then they are either out-of-luck, or need to talk the software company into writing customized code.
Open Source is very different. Usually, software in this model is written by the group of users in need of the product. Since it is developed by the users it can change quickly as requirements change. In cases where there is a subset of users who need something slightly different, they can add code and features to the project, or in rare cases, 'fork' the project.
Adding functionality to an existing Open Source program is quite simple. Linux is a great example. Lots of new and specific functionality makes it into the kernel. In cases where Linus turns down the particular addition, developers can easily release a patch for the kernel, or even a fully patched kernel, that gives people the functionality they desire. This is an excellent example of how Free Software can allow developers to fill different needs, without forking the project.
Unfortunately, for different reasons, sometimes developers decide that the project is heading in a direction they don't wish to follow. This is usually, not an issue of differences in functionality, but a major difference in overall goals. When this happens, a project may fork.
Now, think for a moment about what that means. If a set of developers believe that most users need the project to move in a different direction, they can take the code and start a new project. This is a guaranteed freedom in Free Software. Anyone can take a copy of code and set different goals for that product. Unlike forking in the traditional software sense, where similar projects become incompatible, free software that becomes forked doesn't mean incompatibility. Indeed, another inalienable right of Free Software, is that the forked projects code is freely available for the original project (or any project) to use, include, or ensure compatibility with. So we have the best of both worlds, if some project members believe that they can do a better project, they're free to do so. At the same time, users are not tied down to one project or the other.
Forking rarely happens in the Open Source community. It's usually so much easier to simply create patches or plug-ins that make everyone happy. But, this is not always the case. One of the Flagship projects in the Free Software world has just announced a fork. Samba, a UNIX tool for the SMB protocol. Samba allows UNIX clients and servers to live on a Microsoft-centric network, sharing files and printers seamlessly. It has seen much success, even being able to turn a S/390 mainframe into a huge NT File/Print server.
The reason for the recent fork is based on a multitude of things. With the release of Windows 2000, Microsoft made some changes to the SMB protocol that broke compatibility with Samba, especially in the way clients authenticate to the Primary Domain Controller (PDC). Essentially, Windows 2000 clients could no longer authenticate to a Samba PDC. Samba TNG (the new fork) aims to fix this problem quickly. Hence, they forked.
Sadly, the main reason for the fork was not the issue of functionality. The PDC fix was already in Samba's future plans. This fork happened for another reason: Hubris. Developers couldn't get along, so they split.
Does this mean that Free Software is a bad idea for businesses to bank on? By no means. In fact, this should be an encouraging sign. One of three following scenarios will probably happen.
A. Samba and Samba TNG will continue developing separately, borrowing code from one another to improve their respective functionality.
B. Samba and Samba TNG will resolve their differences and re-merge, combining the code from both projects into one.
C. One of the projects will prove itself to be better maintained, and have more functionality. Users will fall in line behind that project, and the other will eventually die out. The project still standing, can take the code from its sibling and include it in the system.
None of these three options are bad for the consumer, or user. In fact, the end result will be a version of Samba with more functionality than it has today. If both projects survive, then users have the freedom to pick the one that best meets their needs.
Forking is used as a boogieman when criticizing Linux and other Open Source programs. This is because of Unix history. Unix was a proprietary, ASCII based, Operating System. The 'First Edition' of Unix was created by Bell Labs in 1969. Unix continued in this single vein until 1977, when it forked into PWB, MERT, CB Unix and iBSD. Forking and re-implementations continued until the family tree of modern UNIX systems looks like something from the royal archives in London. Sadly, most of the Unix systems are incompatible with one another. If something works one way on HP-UX it may not work that way on Unix or Solaris. If you compile a program on Solaris-x86, it probably won't run on other x86 Unix OSes. The forking of Unix has led down a confusing path of dead-ends.
There is a major difference in these traditional UNIX systems and Linux. Specifically, that difference is the guaranteed freedoms granted by the GNU General Public License (GPL). If a vendor were to 'fork' the Linux kernel, it would not mean incompatibility. They would be forced to release any and all changes they made to the kernel. These changes could be added into the original kernel, or changes could be made in the original kernel to ensure compatibility. A kernel fork would likely result in one of the three scenarios I listed earlier. In fact, recent discussion has shown potential areas where the kernel could fork, to focus on highly specific areas. If this happens, thanks to the freedoms of the GPL, we are guaranteed compatibility.
Sometimes, forking is a responsibility that all developers must consider, if it appears to be in the best interests of the project and its users. However, in the best interests of the project or not, code forking is the right of all Open Source developers. I may disagree with your motives behind the fork, but I will eternally defend your rights to do so.