Ok, so maybe this isn’t quite true throughout the life span of an open source project. In the beginning, a blob of code that provides a unix-like kernel on an x86 architecture or glues together cartographic map rendering from a couple of other libraries itself can be pretty valuable. At some point, however, the thing that is most valuable about an open source project isn’t the software… it’s the community around the software. A quick browse of sourceforge or freshmeat will give you all kinds of examples of failed software projects. From a technical standpoint, they may fantastic and maybe even widely used, but if you are measuring success by the size and vitality of the community around it, from a sociological and network-effect standpoint, they’ve failed. Why didn’t they take off?
There could be many reasons. Maybe the initial developer of the software isn’t friendly to newbies and the project can’t grow users very fast. Maybe the software is too specific and not widely applicable. Maybe the code is written in such a way that it is not extensible or just plain miserable to work with. Maybe ego of the initial developer(s) gets in the way of allowing others to feel that they have as much stake in the code. This list could go on for a long time.
lusers and users
Users of open source software projects are what provide most of the value to a project. Users’ growth in technical skills and abilities is not static. A successful project fosters this growth. Familiarity with something takes a long time. A project that does not make a user feel that the investment to become familiar with the software is worthwhile will grow very slowly.
Users in a software project go through various larval stages on their way to contributing source code. A percentage of current users become power users, and start writing documentation or helping out on the maillist. Some of them start contributing bug fixes, and eventually graduate to writing code.
Lowly users still provide plenty of value to the project. How they deploy the tools, the money they save, and the kudos they get all contribute egoboo to the project. They bring more people to your project by making folks more aware of what it is capable of. Instead of hype, they contribute credibility by attaching their name to your project’s name in a wider world that is much larger than the frequently myopic problem domain that your open source software project lives in.
How to kill your open source project
1. Change your name
Identity is one of the most important things in an open source software project. The name need not describe what the software does, but it better not change because it disrupts the awareness of a project. Take care when initially naming your project so that it has a distinctive one.
For example, I know what NetBeans is, even though I’m not a Java developer. I have gained this awareness through being connected to the software development community through sites like Slashdot and reading software developer’s weblogs. If NetBeans were to change their name to MungBeans, that cycle would start all over again and it may take a couple of years before I know what MungBeans is about.
2. “Rewrite” your codebase
A rewrite is essentially a fork of your own software. It disrupts the familiarity and time investment stuff I was talking about above. You had better have a damn good reason to completely rewrite your code. Doing so gives your users and development community an opportunity to look elsewhere or even create a fork of the original software so as to continue the momentum that they had personally invested.
3. Fork your maillist
A separate users and developers list for a software project is a good thing. One is typically high-traffic while the other often only contains software development issues pertinent to the project. But once the signal-to-noise ratio of the user list gets to low or even just the traffic gets high, there is often a temptation to fork the list. Don’t. Doing so creates confusion in the community, disrupts people’s awareness of happenings, and short-circuits the ability of people to gain tacit familiarity with problems and issues they might encounter.
A corollary to this is to bury your maillist archives behind a firewall. It increases the frequency of FAQs because it disrupts people’s ability to find out information for themselves. It also slows down the user growth of a project by eliminating the serendipitous finding of your project by people looking for topical information. Your maillist should be visible to the search engine that counts…for right now, this is Google.
4. Crassly attempt to monetize your community
So you’ve created all of this value right? Let’s cash in on it! Not so fast buddy. Extracting money out of your open source software project is a tricky thing. End up getting your users to resent you and you’ll have nothing to extract.
5. Mixing business and pleasure
Many open source developers do so for the pure enjoyment of it. Scratching their itch and all that. Some are in various stages of turning that hobby into a business, either by getting commercial entities to support improvements into their codebase or by selling services based on the tools they’ve developed. If business interests start overtly pushing much of the direction and motivation for a project, your casual users will likely leave for something else. This could happen for a number of reasons, but the foremost one is that individuals doing something for fun and for free can resent their efforts putting coin in some business’s pocket.
So what does all this mean? Remember that the community around your open source project provides most of the value. The software is what brought people in, but the people make the project. Don’t screw it up by thinking you can control them or by thinking that what you say is the final word. You get what you give.