Potential Problems with open source.
Issues facing the community.
We have in the first part of this series [1] looked at some of elements that surround open source and software development. In the second part of the series [2] we looked at some of the reasons why open source projects and try to understand are so successful. In this concluding part, we will look at some of the problems that have arisen in this software development model.
We shall, as is now customary begin, with Linux. Apart from its many successes and triumphs as detailed elsewhere [3], Linux has thrown up a fare number of difficult issues. At first sight, Eric S. Raymond is right in believing that open source projects can actually violate Brooke's Law. However, as has been noted on the lkml (Linux Kernel Mailing List) [4] and elsewhere, as open source projects increase in size, the entry level at which ordinary users can actively begin contributing to the project keeps rising. Not so long ago, it would possible for someone to actively follow lkml. Now, in order to deal with the volume and magnitude of discussions on the lkml there are effective alternative mechanisms to follow lkml, namely Kernel-Traffic[5]. Newbies can rarely, if ever start post code or patches. And in several well documented cases [6], legitimate and useful patches have been either lost or ignored. Linus has himself begin work on some form of a Patch management system to handle the entire process[7].
The late arrival of the 2.4 Kernel has been attributed to many reasons. The old line of "it will be released when it's ready" no longer rings true. Even late into the code freeze imposed on the 2.4 kernel, drastic changes were being proposed. In addition, kernel developers were themselves releasing anonymous mails and blowing off steam regarding schedule slippage and other issues[8]. This does not augur well for Linux. To think that a motto of open source of "release early and release often" is being thrown aside is an ominous sign. Another sign was the frantic efforts to back port features [9] from the 2.4 series into the 2.2 series. If a production kernel is delayed that features are being back ported, then perhaps some more efforts are required to streamline production. Some efforts in this direction have already begun.
Mozilla is also another favourite whipping boy for critics of the open source regime. For ages on end, Mozilla remained a standard compliant, effective and incredibly heavy and buggy browser. The latest releases [10] are reasonably stable and actually beginning to show some promise and quality. And in the first real open source experiment, it took over a year for the Mozilla team to actually decide to throw away the existing code and create a new rendering engine called Gecko[11].
Hurd [12] is another classic example of an open source (or in this case, more correctly Free Software) project that has gone astray. As Linux has so comprehensively proven, a line of working code is worth a 100 lines of theoretical perfection. Hurd was designed, nay engineered with spartan beauty and elegance. It was a state of the art (at that time) operating system that ventured boldly where no OS had before. But it has failed. And so have other such projects that have sacrificed functionality and effectiveness at the altar of theoretical beauty and elegance. Open source allows the best ideas to be selected quickly - but in places where there are no right answers or best ideas, reconciling people and ideologies are not easy.
While it may be extremely simplistic to assume that open source software development directly translates into egoless programming, that is often not the case. Human beings will, in spite of themselves, remain human. Often maintainers of large portions of their code are either extremely protective of their code inasmuch as it is likely to harm the code itself. A well publicised spat [13] between the creator of a journalling file system Hans Resier (ReiserFS) [14] and the maintainer of the VFS subsystem Al Viro is an example in point. It would be futile to go into the technical details of the argument, but save to understand the following. In most real life arguments, both sides are usually right in their own way. The difficult task at hand is to accommodate, understand and accept different viewpoints as sources of information.
Licensing is a key issue that now threatens to bog down open source projects. A multiplicity of open source licenses exist. Each of the major vendors such as IBM [15], Sun[16], Apple[17] have their own licenses. Each of the philosophies have their own competing licenses whether they be BSD, GPL or otherwise. In the midst of all this confusion two sets of people are often left confused, isolated and all alone. One is the wannabe developer who wants to release his code and is completely at sea. Another is the average Joe Ramaswamy user who is completely confused by the need of the hundred different forms of essentially the same concept. For example until Trolltech [18] recently released the Qt toolkit under GPL, it was not treated on par with Gnome simply for ideological reasons. Whether a user would have preferred to use KDE over Gnome or not was not a matter under consideration.
Returning to the original thread of thought that prompted this series, what does the entire evaluation of the Open source model imply for OpenOffice? Some simple and easy predictions can be hazarded. Until a community forms around OpenOffice, progress will be rather slow. Converting a closed source to an open source project will take a large ramp up time, especially given the large code base of a project such as OpenOffice. As an average user, do not expect anything from the OpenOffice project for some time. It will need well over a year before anything useful begins to coalesce together. Expect to see controversies regarding Sun's influence and behaviour regarding OpenOffice. Expect to see controversies in the Gnome foundation [19] regarding OpenOffice.
Expect to see some more chaos theory at work. And in the end, much like a fractal, expect to see something so mysterious and so beautiful that a sense of awe is all you can feel. Little, little bits and bytes. Lines and lines of source. Hundreds of programmers. Man hours. Passion. Pleasure. Programming. The whole is much greater than the sum of parts. For you can also be part of this open source fractal landscape. That is the premise that shall drive this revolution.
[1] http://www.geocities.com/madhumkurup/write/selling1.html
[2] http://www.geocities.com/madhumkurup/write/selling2.html
[3] http://www.firstmonday.dk/issues/issue5_11/moon/index.html
[4] http://www.tux.org/lkml/
[5] http://kt.linuxcare.com/kernel-traffic/latest.epl
[6] http://slashdot.org/askslashdot/00/09/05/1739209.shtml
[7] http://kt.linuxcare.com/kernel-traffic/kt20000925_86.epl#11
[8] http://kt.linuxcare.com/kernel-traffic/kt20001030_91.epl#10
[9] http://www.suse.cz/development/usb-backport/
[10] http://www.mozilla.org/projects/seamonkey/release-notes/
[11] http://www.mozilla.org/newlayout/faq.html
[12] http://hurd.gnu.org/
[13] http://kt.linuxcare.com/kernel-traffic/kt20000327_60.epl
[14] http://www.namesys.com/
[15] http://oss.software.ibm.com/developerworks/opensource/license10.html?dwzone=opensource
[16] http://www.openoffice.org/license.html
[17] http://www.publicsource.apple.com//apsl/
[18] http://www.trolltech.com/company/announce/gpl.html
[19] http://foundation.gnome.org/