Section 1.7. How Does Open Source Die?
1.7. How Does Open Source Die?In some respects, most open source projects never really die. Even if the original developers abandon the project, the source code usually remains available so that it's possible for someone interested in the code to pick it up at a later date and bring it back to life. This lowered risk of losing access to an application, in fact, is one of the advantages that comes from using open source. If a proprietary company builds a product and then goes out of business, the source code might be gone forever; with open source, there's always an opportunity for a user to pick up development himself (or fund some other party to continue development). That being said, many open source projects do "die" in the sense that they become dormant or are abandoned by their developers. Many open source projects die, because a community never forms around the need. In the early days, such deaths were invisible. But now, thanks to the rise of public web sites such as SourceForge (http://sourceforge.net/index.php), where open source projects can be started and shared, many stillborn projects are there for all to see. For example, not much has been happening with the Skydiver's Online Logbook project (http://skydivelogbook.sourceforge.net/). The second way that open source projects die is that they never reach completion. The inspired developer creates some software that partially meets the original need, and then for one of many potential reasons he loses interest in the project. The inspired developer gets married, has a baby, gets a new job, has a big project at work, gets bored, starts learning guitar, whatever. For some reason, he is no longer compelled to work on the project, so there it sits, in a half-completed state. Sometimes, at some point another developer picks up where the inspired developer left off, but usually the project just languishes and the source code collects digital dust. One common reason that open source projects die is that the community behind the project has a schism and some of the developers copy the source code to a new repository and start doing things their own way. This is known as forking the project. This story is told over and over in the open source world. The PHP Nuke project is a typical example. With this project, developers of PHP Nuke forked into two camps. One camp wanted to make some radical changes to fix the things they didn't like, and the other camp wanted to take a more incremental approach. The radical-change camp took a copy of the source code and started an open source project called Post Nuke. This was developed for a while and then another schism formed and a set of developers took the source code and started a project called Xaraya. All three projects are in the same area of Web Publishing and Content Management, and we cover Xaraya in detail in Appendix E. To an outsider the differences might not seem too significant, but to those involved they can be important. Sometimes the community that creates a new project is the one that keeps the momentum going, while other times the community from the original project takes this responsibility. Sometimes both communities continue their involvement. But frequently, such community problems kill off all progress in all branches of a project. Forking is actually rare in open source circles, perhaps because of the associated trauma and risk (for more details, visit http://www.infoworld.com/article/03/10/24/42OPstrategic_1.html). Frequently the project leader, or core group, is the one who sets the tone that either causes or prevents such problems. The dependence on the community for any meaningful progress leads us to the final principle of open source:
But remember, there is no authority declaring the life, death, or health of an open source project. If a project dies, its web site can live on. It just might be hard to tell what is happening with it. Figure 1-1 summarizes the steps in the open source life cycle that we have described in this chapter so far. |
