Open Source Software Killers


Jump to: navigation, search

Why is it that some Open Source projects thrive while others fail? This article explores some common reasons for this all too familiar phenomenon.

A project can die for any number of reasons. Perhaps the sole developer no longer has time to maintain it, or maybe a more comprehensive competitor makes it obsolete. It could even be that the threat of litigation shuts the otherwise thriving project down.

All of these are possibilities, having happened countless times before, but they are not the focus of this article. In this discussion, we'll address specifically those factors which are under the direct control of the developer.

The List

Here's the quick list. These are listed in order from most deadly to least.

  1. Functionality - Does it perform as advertised?
  2. Packaging - Can it be installed easily by the target audience?
  3. Documentation - How will users know how to use it?
  4. API - Is it easy for other developers to plug in or extend it?

If a project fails in one of these dimensions, it generally doesn't matter the state of those further down on the list. For example, if a project doesn't function as advertised - if it is missing promised features, crashes frequently or generally operates in a buggy manner - then it really doesn't matter how good the documentation is. Likewise, if a project has poor packaging, then the gracefulness of its API won't be appreciated.

Lets dive a little deeper into each of these:


The #1 killer of Open Source Software projects is faulty functionality, which includes:

  • Buggy Code - Do all the cogs spin in the right directions?
  • Missing Features - Was something advertised which isn't there?
  • Unreliability - Does it stay up under load?
  • Design Flaws - Is it usable and intuitive?

Developers tend to be aware of the importance of functionality, and appropriately address it first. It's often the primary goal of developers to make their projects work well before the first release.

It's well documented that it's impossible to fully satisfy each of the above in any given release - and users generally understand this. Specifically Missing Features. The needs of the consumer base will change over time, so not all features will be foreseen.


Packaging is easily the #2 killer of OSS. If a consumer of the product can't easily get it installed, configured and running, they'll abandon it.

Of course, the term "easily" depends greatly on the target audience and scope of functionality. Take GAIM for example. Their target audience is "users of chat" - consequently their installer is dead easy, with wizards to help you through the configuration process.

On the other hand, the Apache HTTP Server has a target audience of "network administrators" and has a huge feature set. Coincidentally it's installation and configuration process is much more involved.

A developer creating an Open Source project can't afford to ignore the importance of Packaging. Just because it "compiles for you" doesn't mean everyone will rush to compile it.


Assuming the product is functional and well packaged, the next killer of OSS is incomplete or incorrect documentation.

Take, for example, Maven. Maven has a very rich feature set, installs easily, and has a very pluggable architecture. In fact, it's built on Plexus, whose primary concern is dependency injection. However Maven continuously fails to overthrow Ant because of its abysmal documentation.

Note that Maven is not dead yet - there are some who are trying to revive it. Time will tell whether this is successful.

If your target audience can't figure out how to get your project to work, and you don't have any documentation to hold their hand through the process, they'll leave (even for a functionally inferior alternative).


Finally, the #4 killer of OSS is API. This is especially important when building a library or programming language, but also applies to entire systems.

MediaWiki is a great example of an application that has all four key features. It's very feature rich, installs easily, has some of the most extensive documentation around, and is easily pluggable (most of the time).

Typically projects that require interoperability have this designed in as a core piece of functionality, so missing API would really be a missing feature.

The Distracters

It's somewhat understandable that developers would focus on Functionality. After all, developing the software is the fun part. Here is a list of concerns commonly addressed by developers (not always in this order):

  1. Architecture - How clean is my code? Will others appreciate its elegance?
  2. Configurability - Can it be made to do everything?
  3. Polish - Does it look pretty?

Though these are sometimes important, addressing them shouldn't conflict with the previous list.

Take MediaWiki for example. It's architecture improves with each release, but there is still much work to be done. The code is often inelegant, and the use of Global Variables makes it difficult to predict the ramifications of code changes. However, despite this, MediaWiki remains the most popular Wiki software in the world.

In Closing

Developers of OSS, please take heed this warning: even though it's much more fun and rewarding in the short term to focus exclusively on functionality, or endlessly polish your code, this is not what will make your software popular. Make sure your code is functional, installable, and documented, or risk the very audience you wish to astound.