Recently at the Open Source Summit in Tokyo, I was on the kernel panel where someone asked us, “Why hasn’t Linux forked?” The entire panel looked at each other, sorta laughed and we all said the same thing:
“What do you mean? It has forked several times, and it is still forking!”
A Little History
The term “fork” in software is similar to a fork in the road: one base and two branches with that common base. Back in the ’80s, Unix was a popular alternative to the mainframe. Unix has its roots back to research done by MIT, Bell Labs and General Electric. In the 70s and 80s, Unix was used by several universities and was sold off to different commercial startups (AIX, Solaris, HP-UX, Xenix and more). Eventually, Unix had several different proprietary flavors. All were able to do mostly the same operations, but each had their own flavor and were not totally compatible with the other.
Eventually the different flavors (forks) of Unix created its downfall.
Unix was cheaper than a mainframe, but was much more expensive than a common PC. When a customer needed to use Unix, they needed to decided which fork to use, and that also usually meant lock-in to a specific vendor. One might believe that customer lock-in is good for the vendor, but this can have adverse effects. When another fork of Unix has a new feature that would benefit the customer better, they could not easily switch to that version; they may also depend on some feature of the fork of Unix they are currently using.
The different forks of Unix were always trying to add more value than their competitors. This split the user base. It also allowed for a much less expensive operating system that ran on the common PC to start to eat away at their market share. As the PC became more powerful, it became less of a need to use the hardware that Unix ran on. Customers started to move toward the cheaper alternative.
I was first introduced to Linux in 1996. That was also when I was first introduced to an open source license. The Linux distribution I was reading had a clause saying, “Most software licenses prevent you from sharing the applications. Our license encourages you to share.” That was quite a culture shock to me, as I have never heard of such a thing.
Now, open source licenses have been around much longer than Linux, but it was Linux that brought it to the mainstream. Linux was not a clone of Unix, although many people believed that it was and they believed it would suffer the same fate of Unix. Linux was not a fork of Unix. It was written from scratch, but it tried to implement the same Application Programming Interface (API) as Unix. People would incorrectly call Linux another Unix, because it looked the same. But it had a completely different code base and license, one that not only allowed the sharing of the code, but made it a requirement if you ever forked Linux and distributed it.
I would say that Linux started to become noticed by the industry in 1998.
Related: The Road to Real Time Linux
Linux & Open Source Forks
I was asked by the company I worked for at the time to give a presentation to explain Linux and this open source license. Several people told me at the time that Linux will suffer the same fate as Unix, as it allows for forks. I told them that forks will only make Linux stronger. The reason was that the forks can freely merge when, in a proprietary environment, that is prohibited.
In a proprietary environment, when you have a fork, each fork will try to give its own value-add and be unique from the rest. If one fork creates something that the others can’t, it will have an advantage. Those that are not locked into the other forks can move. But then the customers that are locked in will be at a disadvantage.
In an open source environment, when you have a fork, and one of the forks produces a great feature that beats the features of the other forks, their customers can ask for that feature. Since the code is freely available and free to use, the other forks can simply merge that code into its own fork and improve. In fact, whenever any fork improves the code, the other forks can take advantage of it, and all forks become a better project. As stated above, forks will only make Linux stronger.
Every Distribution Has its Own Fork of Linux
Sometimes, it takes forking Linux to prove that a feature is worth merging. If you can add a feature to Linux and get it accepted in one of the forks, you can show its usefulness as people will start asking for it. The Android phone uses its own forked Linux kernel. Several of the Android features came into the Linux mainline exactly because of this. Android was able to show that it had millions of users of a specific feature. That’s pretty convincing to get a feature into the Linux kernel.
The Linux kernel isn’t the only open source project that has examples of improvements via forks. The GNU C Compiler (gcc) had an instance where the developers disagreed on the future of the project, and the developers created a true fork. The two projects remained separate for years.
One would think that something like that would cause the project to fail. Eventually, the two found a common ground and merged back into a single project—one that was better than either of the two separate projects.
I like to think that open source does not fork, but instead it “sporks.”
Spork! An Open Source Fork Utensil
If you know of the spork, it is a spoon and a fork combined as one, where it looks like a spoon with short prongs sticking out of the end. A true fork has prongs that stay separated all the way down to the base. This is true with proprietary software. When a fork occurs, it never merges back.
An open source fork, will only stay separated for a small duration, and then it merges back together that has more features (like a spork has the features of both a spoon and fork).
Forks are dangerous and can kill a proprietary project. But nothing has ever been killed by a spork.
Because you liked this blog:
