Ingredients of a Healthy Open Source Projects
A healthy open source project is a little like a chemical reaction and requires three key elements:
This sounds funny, but some open source projects forget that they need users. They're written by developers based on their notions of how software "should" be, instead of for users based on what they need. The result is that funny-looking "who came up with this?" kind of a look.
This might make writing the software easier or more enjoyable for the developer, but long term it is foolish. Users are the raw material of an open source project. In one way or the other, they ultimately support the developers, whether by hiring the developers as employees or service providers or providing a pool of potential contributors and developers down the road.
But if there are only users, then an open source project would develop at a glacially slow pace. Projects that are short of developers are full of forum or mailing list suggestions of how things should be done, could be done, but are never done. Developers are the catalysts of an open source project. They make it happen at a pace that users could notice.
Developers need two things: something interesting to do and a way to support themselves. If the project is something that "you can't pay me enough to do", chances are it won't be a thriving open source project. At the same time, as fun as anything is to do, we all have to pay our bills, so if there isn't enough revenue for the project to support its developers, it won't thrive. This is where users need to make a conscious decision about the free software they use. While it may be to their short-term economic benefit to minimize their costs of using their software, longer term it would simply starve out the developers and leave the project moribund, rather like chopping down all the trees on their land.
An interesting note here: Just like the catalysts in a chemical reaction, some developers are good, but more developers is not necessarily better. Not any developer will do, and adding more contributors could make a project worse if it is overall not well-coordinated, and there are no good design, documentation, and testing processes in place. Developers should also be in the right portions: some coders, some documenters, a group of dedicated QA testers, and a larger group of people who help out forums or mailing lists (and actually have the right answers.) In good open source projects, they actually have formal teams for each of these.
3. Competing Products
Good open source projects are like exothermic chemical reactions: they produce their own heat or energy and keep going or growing by their own momentum. They are not endothermic reactions that require external input (ie, money) to keep going.
However, there is also some basic environmental "temperature" that's required to keep a project going, and that's dependent on the competing products in the environment. How do available commercial alternatives compare to the open source project? If they offer far richer feature set or greater ease of use, then the open source project won't attract many users, which in turn means fewer developers down the road.
Open source projects are by nature survivors. As long as there's a few (my theory is three) regular contributors, they could limp along, but it'll be like living hand-to-mouth in an Arctic circle cave. It won't be a lot of fun, and very few people would know about you. Therefore, a healthy open source project really needs enough users and developers to generate enough momentum (energy) to stay competitive with alternatives, attract more users, and eventually more developers.