Member view - The trouble with open source

From its humble origins in the 'hacker' culture of US computer science laboratories in the 1970s, open source software (OSS) has grown to become arguably the most influential and talked about phenomenon to hit the computer industry since the invention of the microprocessor.

At the heart of OSS is a wonderful idealistic notion that appeals to our caring, sharing side. 

The OSS vision is of a world in which there are no greedy corporations run by megalomaniac billionaires intent on screwing users out of their hard-earned cash in return for bloated, unstable, insecure software which only operates properly with other products from the same manufacturer and has laughable customer support. 

Instead, there are communities of gentle, altruistic individuals working together voluntarily for the good of mankind.  Unsullied by the sordid world of commerce, the code that they produce is somehow purer and more ethical than proprietary software.

This utopian vision of technology is championed by high-profile pressure groups such as the Free Software Foundation and embraced by cyber-liberties groups such as the Electronic Frontier Foundation. However, OSS would not have become the powerful force that it is today without also having wider appeal. 

As well as beard-and-sandals types, OSS also appeals to a deep-seated fear within many hard-nosed IT managers in organisations whose reliance on a particular software product may be critical to their business. 

Such organisations tend to have major concerns over the risk of inadequate or diminishing support for the product, either through product obsolescence or if the vendor goes bust.

They become locked into an endless cycle of product upgrades, which can be almost impossible to break free from. 

With OSS solutions, users have the comfort of a large developer community that is unlikely to disappear anytime soon and there is always the option of supporting the software in-house as the source code is freely accessible. 

Despite the overt counterculture and anti-globalization agendas displayed by certain sections of the open source movement, many governments are now also turning towards OSS in their quest for an information society for every citizen.

Many of the proponents of OSS seem to have been captivated by the idea of a free lunch and may have failed to consider the longer-term effect of OSS on our fragile software ecosystem. 

Let us examine some of the issues surrounding OSS that aren't normally aired in public:

  • Intellectual Property:

    A major flaw at the heart of the open source movement is the misconception that most individuals actually have the legal right to contribute their intellectual efforts to OSS projects. 

    In most industrialized nations, intellectual property (IP) generated by an employee through the course of his or her employment legally belongs to the employer. In the UK, this is embodiedin the Patents Act 1977 and the Copyright, Designs & Patents Act 1988. 

    Of course, if you are employed as a janitor and happen to write software in your spare time, you could argue that the IP that you are generating is entirely unconnected with your normal duties as an employee and therefore belongs to you. However, when it comes to software professionals, there is no such argument. 

    Any software that they write, irrespective of whether it is during or outside normal working hours, legally belongs to their employer. 

    Self-employed and contract software engineers are not usually bound by employer's IP rights but are unlikely to be strongly motivated to write OSS code unless they can earn a living from doing so, and the unpaid volunteer nature of OSS development tends to rule out this possibility. 

    The open source movement has its roots in academia but the situation regarding ownership of IP in universities has changed considerably since those heady days of PDP-11 minicomputers and VT100 terminals. 

    Nowadays, academics employed by universities are unlikely to own their IP, bound by the same laws that govern employees in industry. Their students, however, are not usually employees and consequently are likely to have more freedom to engage in OSS projects but the students' lack of practical software development experience will be a considerable drawback. 

    So, it would appear that the only people who are actually free to participate in OSS projects are self-employed or unemployed software professionals, students and enthusiastic amateurs. Anyone else contributing to OSS projects may be unwittingly engaged in illegal activity by stealing their employer's IP. This does not square well with the altruistic image of OSS.

  • Conceptual Integrity:

    The process of creating software is more akin to an engineering discipline than an artistic endeavour, and this raises another point of concern with OSS. 

    Like any engineering design project, good software needs a designer (or software architect in the current industry jargon) with a clear design concept which must be adhered to rigorously otherwise the software becomes progressively messier as it is developed in a piecemeal manner. 

    Fred Brooks, the computing pioneer and author of the defining publication in the software engineering field, The Mythical Man-Month, calls this 'conceptual integrity'. 

    We only have to look at the history of the electronic computer to see that the greatest advances in technology have been made by brilliant, strong-willed individuals, usually supported by a small team of dedicated engineers - not community-based projects. 

    Examples abound, but include such legendary figures as Charles Babbage, Alan Turing and Seymour Cray. In contrast, the OSS development process is reminiscent of the old joke about a camel being a horse designed by a committee. 

    Of course, the much-lauded OSS process of peer review ('Given enough eyeballs, all bugs are shallow') is an unquestionably powerful method of improving code quality. But we seem to have forgotten that peer review is, or should be, part of the normal software engineering process anyway and good software needs a strong architectural vision which the community-based method of software development does not foster. 

    Fred Brooks and bitter experience both tell us that the emphasis should be on good design and tight specifications to minimize bugs, but in the OSS method of software development, the emphasis is firmly on fixing things once the design is implemented in code.

    This is a very inefficient way of ensuring code quality - just ask Microsoft!

  • Professionalism:

    There are uncomfortable similarities between the OSS development process and the situation that arose in the computer games industry in the early 1980s, where legions of 'bedroom programmers' produced video console games of such poor quality that, despite selling in tens of thousands, they nearly destroyed the industry. 

    The games industry learned a valuable lesson from this experience and is now arguably the most highly trained and disciplined software development community in the world. This professionalism in software development is cited as a major contributory factor to the explosive growth that the computer games industry has enjoyed over the last 10 years. 

    The open source movement, with its hacker ethic, doesn't promote professionalism.

  • Innovation:

    The absence of design leadership in the OSS development process and a motivation for OSS developers to create free versions of their favourite proprietary software may also explain why there would appear to be a distinct lack of imagination in OSS projects. 

    The open source community has so far tended to create facsimiles of proprietary packages rather than the next killer application. Linux is an excellent example. 

    Although it contains many powerful new tools and utilities, Linux is in essence a facsimile of Unix, a proprietary operating system first developed at Bell Telephone Laboratories in 1969. 

    Ironically, the legendary robustness of Linux actually owes more to the good design of Unix and its older relative, Multics, than it does the OSS development process.

A continued shift towards OSS solutions at the expense of proprietary ones is likely to result in many of the companies that develop proprietary software going out of business. 

This might not be such a bad thing, as I'm sure that many of us would secretly welcome the collapse of the virtual monopoly that currently exists in the desktop software market. 

However, the first companies affected are likely to be the small but highly innovative firms, which are the lifeblood of the software industry, not the giant corporations that we all love to hate. 

Academic research will continue to push the boundaries in terms of new algorithms and methods but without industry providing the market pull, these technologies are unlikely to end up on our desktops.

In theory, an OSS license doesn't actually prevent anyone from selling the software but in practice no one will buy it if the source code is freely available, unless the seller is also providing some kind of added value. 

Also, with OSS there is no exclusivity, as the seller cannot stop anyone else from selling the software too. The established business model for OSS is to give the software away for free but sell support, documentation or consultancy services, thereby providing the added value. 

Companies such as Red Hat make money out of Linux by selling a shrink-wrapped version complete with telephone support, glossy manual and installation software, all of which make it much easier to install and use. 

They are successful because the market for Linux is huge, but this business model isn't really viable for niche market software and a scaleable model has yet to be found. Therefore, despite the growing popularity of OSS, investors remain reluctant to put money into an OSS business venture.

However, OSS does have a legitimate place in academia. Releasing university-developed software under an OSS licence can stimulate new research collaborations, free up source code for teaching purposes and allow it to be included in research publications and books. An
OSS release may also protect the long-term future of critical research software by placing it in the public domain, thus increasing the number of users and developers. 

Forward-thinking universities, such as the University of Glasgow, are now recognising the desire of academics to use OSS as a method of disseminating the results of research and are currently looking at how best to facilitate this. 

One option under consideration is an extension of waiver of employer's IP rights, which is usually confined to copyright on books and research papers, to include software.

As software has become increasingly complex, the software industry has struggled to cope. Pressure has also grown to improve interoperability and maintain backward compatibility through many generations of the same product. 

The rise to prominence over the same period of start-ups whose naked ambition and eye-popping marketing budgets have perhaps outstripped their ability to deliver high quality code, seems to have fostered the public perception that the industry has lost some of the professionalism in software development that was established back in the days when the mainframe was king. 

This has led to widespread customer dissatisfaction with proprietary software and allowed the open source movement to flourish. OSS may be here to stay but, despite the hype, it is clearly not the panacea for all the software industry's ailments. 

Its perceived strengths don't bear close scrutiny but they do serve to highlight current weaknesses within the industry. Therefore, OSS should be welcomed by the software industry as a catalyst for change.

The UK government's recently introduced policy on the use of OSS recommends that OSS solutions be considered alongside proprietary ones for public sector IT purchases. 

Freedom of choice is always a good thing but, as the main selection criterion for public sector procurement is usually value for money, the implication is that OSS will be chosen over proprietary solutions unless there is a very convincing case for not doing so. 

The new policy also recommends the adoption of OSS as the default exploitation route for publicly funded R&D software outputs. While this is broadly in line with the direction that the academic community is taking, it doesn't help the software industry. 

What we really need from government is an investigation of the long-term effects of OSS on our indigenous software industry, assistance to combat the threat to the industry's livelihood that OSS might pose and the development of a strategy to build on the opportunities that OSS has created. 

Without prompt action, my fear is that a further move towards OSS could result in the nightmare scenario of OSS at one extreme and Microsoft at the other with nothing else in between. Where would our freedom of choice be then?

Stephen J Marshall CEng MBCS CITP

September 2005