Wednesday, January 3, 2007

How an Open Source Project Die

Belonging to the OSS community guarantees nothing. OSS is not a magic bullet ensuring the success of a project. The mortality of open source projects is pretty high; a number of projects never make it to the magic version 1.0. When you see a Web page that was not updated for a year or so it is usually a message indicating that something is wrong. There are several explanations for these extinctions:

* Burn out: The first and obvious reason is that the leader of a given project overworks and just burns out. Sometimes the task is just too difficult and the initial developer overestimated his forces and recourses. This leader is unable to create a more or less complete version that can generate support from the community.
* Inability to acquire a critical mass of users: Even if the project was successfully completed (generating a stable working version), other projects can grab resources and user support, in turn dooming a given effort. The resulting "critical mass loss" spells trouble. Without a critical mass of users any sizable software project becomes sterile.
* Loss of the leading developer: In some cases, the leading developer takes on a new job and has no time or interest to continue a given project. Personal distractions can effectively kill the project, too. Health-related incidents are also common.
* Forking: Ego-related infighting can lead to forking. Forking of the project can often cause the death of both initial and forked projects. The relationships between the leader and the followers are pretty subtle and require a very skilled and careful exercise of power. This power is better not used unless a given issue is very critical, because a conflict can alienate the community. Unwise use of power by a leader can alienate the user base and thus create preconditions for forking by any of the lieutenants. Forking diminishes available resources for the original and forked versions and thus can increase the influence of other negative factors that threaten the existence of the project. Often it can be contributed to the lack of the organizational abilities and diplomatic skills on the part of the leading developer. Most successful OSS project leaders are pretty skilled in avoiding infighting and ego-related splits.

I would also to suggest that success does not equate to a superiority of a given technical vision. As in science, shifts of dominant paradigms are difficult and painful. Small and less dramatic changes are more attractive than radical shifts, in software or science. Inertia in software development like inertia in the academy. It means that talented individuals need to overcome more than technical obstacles; they need to overcome the resistance of the community to accept their ideas.

As in an academic community, direct contacts with an influential community members and access to major centers of development are very important and can significantly reduce the barriers to the acceptance of a given idea. This phenomenon - "the tragedy of provincial talent" - was first investigated by Nobel Prize winner Pyotr Leonidovich Kapitsa. His analysis of the work of several Russian physicists, never popularized or accepted by the mainstream Western scientific community, is directly applicable to OSS software.

Kapitsa understood that the proximity to leading centers of research and to members working at these centers greatly contributes to the acceptance of a discovery. Once a discovery is integrated into the corpus of scientific knowledge, a paradigm shift can start.