The Open Source Community 101: Assessing Open Source

If you are involved any any Open Source project, you might have seen this article in the last couple weeks: How To Tell The Open Source Winners From The Losers fromI Information Week. It serves and an interesting reminder that although many people are motivated by ideology, etc, there are still some requirements for a successful project.

Let's get some things out of the way up front… Yes, there are tens of thousands of Open Source projects – according to the article about 140k on SourceForge alone – and they just happen to be the biggest, not all of them. And here's the thing, just like blogs, just like movies, just like everything else, there are superstars which rise to the top and dominate their niche (Linux, Apache, PHP, Firefox, Eclipse), there are lots of great ones that don't really get much appreciation (Freemind, Filezilla, dotProject), and then there are tens of thousands of pieces of… less-than-useful software (names withheld to not ridicule). So while Firefox may not represent the whole community, neither do the little projects that die.

Back to the article, it lays out nine main aspects that fit together to have a successful project:

  • A benevolent dictator
  • Disruptive goals
  • A clear license
  • A thriving community
  • Civility
  • Documentation
  • Transparency
  • Commercial support
  • Employed developers

I've listed them in this order on purpose… as I think it's interesting to note that when looked at in this order, it becomes a natural progression from a one-man-show to something bigger and better. Each thing builds upon the pieces already in place while simultaneously strengthening those previous pieces.

Almost every Open Source project starts as a single person with a handful starting as a small group. This group is looking to do something bigger and better and (often) never done before. Once they get a release or two under their belts, others begin to share the excitement. They've used the project, found some value there, made some suggestions, comments, fixes – some of them even useful – and want to keep things rolling. Now here's where it gets risky and many projects don't make it past this stage…

You need to figure out how to keep both those motivated people and the total newbies around without a) offending then and b) offending the rest of the community. Both have the tendancy to be extremely annoying but for different reasons… the first group is going to want to push the project a) faster or b) in different directions than are generally agreed upon. Some of their suggestions might even be better, but once they've alienated key community members, it's hard for them to be heard. The second group is going to ask the same questions that have already been asked 20 times… and answered 20 times… this morning. So your community needs to figure out how to keep both of these groups around and meet their needs without ticking off everyone else. Yeah, that's all.

Luckily, at this point the core of the documentation starts to happen. The well-established users start to put things together and gather all the relevant information together in a managable location, like a wiki. The nice thing about a wiki is that anyone can update it and if you can convince the newbies to look here, you're that much better off and will preserve the sanity of your more active users.

The final two steps are the most difficult and at the same time the most important… you can;t convince a company to offer commercial support for a project unless that project has huge penetration. Unfortunately, there are many places that a project can't be considered until you have commercial support. Therefore, it takes a few companies or individuals to take a risk on projects to push them towards that point. Many of them will completely fail at it – look at all the Linux companies from the 90's that simply don't exist – but they could begin to generate enough revenue to hire a few core people fulltime.

Unfortunately, we don't know what the next steps are. At present, it appears that as a project progresses through the stages, it attracts different types of leaders and the original core (and sometimes the second generation) drifts away to start their next thing. This isn't necessarily a bad thing, it just demonstrates that – just like a new company – as the community around it grows and the opportunities change, the project has a different feel, goals, etc as time goes on.