Papers

It is known since the 1968 NASA conference that we are under a constant “software crisis”. The Standish group reported in 1998 that US companies spend € 269 billion in software projects, and of these 26% succeed. Adding the cost of failures and delays, in 1998 the estimate loss due to software development failures and delays amounted to € 95 billion. Scaling these numbers to worldwide markets, and adding governmental software projects, it is reasonable to say that worlwide more than € 550 billion are wasted due to software projects gone awry.

In one of the most widely known article in software engineering (“no silver bullet: essence and accidents of software engineering”), Frederick Brooks exposes some fundamental reasons behind the inherent difficulty of making software, especially large scale software systems. He also coined his law, the “no silver bullet law”:

There is no single development, in either technology or in management technique, that by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity.

Despite many trials, and many technologies (better languages, OOP, formal methods, automatic programming are some of the examples presented in the paper and its many follow-ups) the law has remained true until now. In the same article, however, Brooks marks some potential attacks on the inherent difficulty of making software:

• buy, don't build (that is, if possible don't code at all)
• requirement refining, rapid prototyping, incremental building
• great designers

It is quite easy to make a parallel with open source style development, that promotes the same ideas:

• reuse components and source code from other projects
• release early/release often (or allow anyone read access to CVS for making their own version)
• meritocracy (small group of respected core developers, and many smaller contributors)

It is undeniable that the open source community was capable of obtaining impressive results, competing in many fields with the commercial world and usually with advantages in term of perceived security, functionality and flexibility. It is therefore plausible to believe that a more widespread adoption of open source methodologies in software development may help in reduce the worldwide loss of resources due to failed and delayed projects, and eventually reduce that € 550 billion annual loss. It is clear that even a 1% improvement can have a huge impact globally.

What can the research community do to verify this ipothesis?

• Verify “on the field” on current IT projects if the adoption or use of open source has an influence on project success, project cost or does affect in any way the project course. The methodology may be similar to that used by research groups like the Standish Group, to provide for comparable results.
• Research what kind of hurdles may hinder the use of open source in IT projects, and if those can be overcomed through community activities, government support or other kind of action
• Cooperate with the software engineering community, to explore the parallels with previous research in code reuse, code inspection and software architectures