Open Source Software: More Placebo than Panacea?
Prof Brian Fitzgerald, Frederick A Krehbiel II Chair in Innovation in
Global Business and Technology,
College of Informatics & Electronics, University of Limerick, Ireland
This document briefly introduces a number of potential vulnerabilities
that may arise in the open source software (OSS) process from the software,
business/economic, and social perspectives.
Potential Vulnerabilities in OSS from a Software Perspective
- Not enough good programmers
Just like the doomed Chief Programmer Team of the 1970s, there just
are not enough high quality programmers around to fuel the explosion
of interest in OSS. A lot of OSS projects start from a lone developer
“scratching a personal itch.” However, to lead an OSS project
really successfully, the leader needs to be a ‘code god’
who inspires others and whose ability and authority is beyond discussion.
- Too much mediocre code
The corollary is obvious. While the early OSS pioneers may represent
‘best-of-breed’ programmers, the programming ability of
the later volunteer programmers could pose a problem. It is well-known
that some programmers are net-negative producing (NNP). That is, the
project actually suffers from their output. Unfortunately, due to the
popularity of OSS, a lot of these NNP programmers may tend to get involved,
and not be easily identifies due to the anonymity of the development
process. If contributions from these NNP programmers gets included in
OSS releases, the consequences could be disastrous.
- No interest in mundane tasks of software development
Many software tasks are of the mundane variety, documentation, testing,
internationalisation/localisation, field support etc. Although tedious
and mundane, they are vital. The exciting development tasks may be cherry-picked
by OSS developers. The hope is that non-technical OSS contributors/users
will undertake some of the documentation and testing tasks, but this
cannot be guaranteed. Exacerbating this is the well-established fact
that the contributions and requests from non-technical contributors
and users are routinely ignored.
- Modularity issues leading to maintenance problems
Modularity is necessary in OSS for a number of reasons. Firstly, it
allows work to be partitioned among the global pool of developers. Also,
as projects progress, the learning curve of the rationale behind requirements,
design decisions, etc. becomes extremely steep. Thus if new contributors
are to have any chance, they need to be able to reduce their learning
focus below the overall project level. Modularity helps achieve that;
thus, it is a sine qua non for OSS. The Mozilla project provides an
example whereby the monolithic nature of the source code ensured that
only Netscape coders were really in a position to contribute to the
However, the excessive modularity unfortunately could lead to one of
the most insidious problems in software engineering, common coupling
between modules. If this occurs, OSS code will become increasingly difficult
- Reliability of OSS products not up to expectations
A number of studies have suggested that OSS products are not as reliable
as once thought. This could damage public credibility a great deal and
cause a general loss of confidence in OSS products.
Potential Vulnerabilities in OSS from a Business/Economic
- No transfer to vertical software domains
OSS projects tend to be in horizontal domains—infrastructure software
and the like, where business requirements and design issues are part
of the established wisdom. This facilitates a global developer base,
as anyone with an ability to programme can contribute, including non-professional
developers such as students. However, in vertical domains, where most
business software exists, the real problems are effective requirements
analysis and design, and these are not well catered for in OSS.
- No strategic nous
The variety of individual motivations behind collaborating in OSS projects—anti-Microsoft,
ideological support for free software, general hacker interest in coding,
blurred the bottom line that allows most organisations to define a strategic
focus for their products. Thus, OSS projects have been tempted to compete
with Microsoft in the worst possible way – desktop applications
(whereas Microsoft have analysed and abstracted some of the best principles
of OSS into their .NET strategy.
- IPO envy
The tales of fabulous wealth which have allegedly accrued to some OSS
pioneers may attract the gold-diggers to California again. In such a
climate, trust is likely to break down, as volunteers cannot be sure
that some of their peers will not sell out.
- Breakdown of trust in murky hybrid OSS business
Again as a corollary, in a collaborative community, trust is vital.
Given the widely varying models for OSS, volunteers may resent companies
exploiting their intellectual effort as cheap R&D and taking the
useful results back into their proprietary offerings.
Potential Vulnerabilities in OSS from a Social Perspective
- OSS becomes part of the establishment
The brightest and most creative young (unfortunately ageist) minds are
naturally attracted to OSS because of its anti-establishment image.
When it becomes popular and mainstream, these bright young anarchists
will no longer be interested. Also, as the skill level of the contributors
diminished, there will be no badge of pride in being part of the community.
- Burn out of OSS project leaders
The leading pioneers may just burn out. They joined for the passion,
challenge, freedom, and fun, and suddenly, it may not be any of those
things anymore. To some extent, the initial basic software problem may
be solved, and all that may be left are the mundane tasks, and these
will not be of sufficient interest to motivate continued involvement.
- Balance between self-deprecation/modesty and
supreme ability on the part of the OSS pioneer developers cannot be
OSS pioneer developers need to be modest to ensure that others will
contribute. If others think their contribution is unnecessary or would
not be welcome, they would not be motivated to help, thus, the project
would never get initiated. However, OSS at heart obeys a reputation-based
economy, and the initial pioneer attracts the greatest reputation, so
egoism is also very much evident. Allied to this, the pioneer developer
has to be universally acknowledged as a ‘code god’ so that
he (and it is probably usually ‘he’) can unilaterally choose
between competing contributions.
- ‘Alpha-male’ territorial squabbles
Again, as a corollary, OSS may remain a male-dominated nerdy preserve.
Territorial battles over module leadership could become the norm, with
the ‘alpha male’ resorting to ruthless behaviour to maintain
leadership of the module, and thus unfairly rejecting too many worthwhile
Feller, J. and Fitzgerald, B. (2002) Understanding Open Source Software
Development, Addison-Wesley; UK Feller