Perils to Open Source

Most software ventures, like most scientific enterprises, fail. As Bob Young points out, making successful open-source software is not so very different from making successful proprietary software. In both cases real success is rare, and the best innovators are those who learn from mistakes.

The rampant creativity that leads to innovation in both science and software comes at a cost. Maintaining control of an active Open Source project can be difficult. This fear of losing control prevents some individuals and many companies from active participation. Specifically, one concern when embarking or joining an open-source software project is that a large competitor or group of people will come in and create what is called a fork in the code base. Much like a fork in the road, a code base can at times diverge into two separate, incompatible, roads and never the twain shall meet. This is not an idle problem; look, for instance, at the multiple forks that the BSD-based operating systems have taken, leading to NetBSD, OpenBSD, FreeBSD, and many others. What is to keep this from happening to Linux?

One thing that keeps this happening is the open methods used in the development of the Linux kernel. Linus Torvalds, Alan Cox, and the rest run a tight ship and are the central authority for adding and accessing the kernel. The Linux kernel project has been called a benign dictatorship, with Linus as its dictator, and so far this model has produced a nicely written tight kernel without too much extraneous cruft in it.

What's ironic is that while Linux has experienced little actual forking, there exist large patches that convert the Linux kernel into a hard real-time kernel, suitable for tight critical device control, and additionally there exist versions of Linux that can run under dramatically weird architectures. These patches could be considered forks, as they are based on a set kernel and grow from there out, but because they occupy special niche application areas for Linux, they do not have a fracturing effect on the Linux community as a whole.

Think, by way of analogy, of a scientific theory applied on special cases. Most of the world gets along just fine using Newton's laws of motion for mechanical calculations. Only under special circumstances of large masses or high velocities must we make recourse to Einstein's theory of relativity. Einstein's theory could grow and extend without undermining the application of the older Newtonian theoretical base.

But competing software ventures often conflict just as competing scientific theories often conflict. Look at the history of Lucid. Lucid was a company formed to exploit and develop a streamlined version of the popular programmer's editor Emacs and sell it to the development community as a replacement for the original Emacs, written by Richard Stallman. Lucid's alternative was called Lucid Emacs and then Xemacs. When the Lucid team went to pitch the Xemacs solution to various companies, they found that they could not draw enough of a distinction in the results produced by Xemacs versus Emacs. Combined with the lackluster state of the computer market at the time, Lucid was short-lived.

Interestingly, Lucid did GPL its Xemacs code before it went out of business. Even this failed enterprise is a testament to the longevity of open-source software. As long as people find a use for the software, they will maintain it to work with new systems and architectures. Even now, Xemacs enjoys terrific popularity, and you can spark an interesting debate among Emacs hackers by asking them which Emacs they prefer. Xemacs, with very few people working on the program, is still a vital advancing product, changing, keeping up, and adapting to the new times and architectures.