While clearing out my reading stack a few weeks ago, I was flipping through IEEE Computer and came across this article: Assessing the Health of Open Source Communities and as a member of the Open Source community for 5+ years now, I found it fascinating. First a quick summary and then I'll get to the guts.

The first big aspect discussed is the shape of the community. The authors point towards an onion model being the most common and normally the most effective. This consists of a Founder, Release Coordinate, and Core Developers. In most cases this is a small group of people that have been working together for a while, are familiar with each other, and generally set the direction, pace, and tone of the project. Next, we have the Codevelopers. These are individuals who can't commit directly to the codebase but are making and submitting fixes for review. As time progresses, they can move into the Core Developer group but don't always. Next, we have the Active Users who know how to use the system, provide comment, feedback, and often basic user support. Finally, we have the Passive Users who are simply there and don't do much.

Alright, so what's the importance of all of this?

Quite simple: If you're going to start using, supporting, or getting involved in any way with an Open Source project - as either yourself or for a company - you have to keep an eye on these factors.

Every Open Source project has to have all four of these layers. Stop and take a look at Sourceforge... or "where Open Source projects go to die".

There are tens of thousands of projects with 1-2 developers, a single release, and single-digit downloads each month. Unless you have a serious driving passion, the energy to push it forward, and the ability to attract additional people, these are probably not projects for you. It's not that any of them are necessarily bad projects, just that you're on your own.

Alternatively, there is a second measure barely scratched on by this article... project activity.

How active are their forums?
How active are their mailinglists?
How many downloads do they have?
How often are releases?

While the layers of the project can tell you about the size of the community, these questions get to the actual activity and traffic of the community. This is the lifeblood and what drives the project. But even here you have to be careful. A thousand posts asking how to install the software shows quite a bit of interest between passive users, but it shows nothing about the core of the project. This is why releases are so important. If there's one release each year, the project might be incredibly stable and therefore no need for releases or it might be in its death throes. Only you can figure out which.

So what happens if you choose the wrong community and now you're using an unsupported project without hope of a new release? Well, there are two things to do and I'll talk about them in detail next week...