Papers

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
bf@ul.ie
http://www.csis.ul.ie/staff/bf/

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 project
  
  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 to maintain.
  
  
• 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 Perspective

• 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 models
  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 maintained
  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 contributions.

Feller, J. and Fitzgerald, B. (2002) Understanding Open Source Software Development, Addison-Wesley; UK Feller