How To Tell The Open Source Winners From The Losers

That's the questions asked in this InformationWeek article. The article covers a variety of topics and is worth reading, but I'll cover a couple highlights.
There are 139,834 open source projects under way on SourceForge, the popular open source hosting site. Five years from now, only a handful of those projects will be remembered for making lasting contributions–most will remain in niches, unnoticed by the rest of the world. For every Linux, Apache, or MySQL, dozens of other open source efforts fizzle out.
That's a dilemma for the many companies that are expanding their use of open source. Corporate developers and other IT professionals must get better at divining the winners and ignoring the losers. The wrong picks can lead companies down a rat hole of support problems and obsolete software.
I find that last sentence to be an interesting one. I can't tell you the number of times I've seen companies in trouble because a proprietary vendor either went out of business or stopped releasing a product. With Open Source, at least you always have options. Also, a couple notes on SourceForge. The majority of really huge (ie. the actual components of the LAMP stack), don't use SF these days. Some vary popular projects still do, but after those I've always broken the rest of the tail into a couple categories. There are the new apps that are legitimately getting off the ground and the apps that legitimately are abandoned or junk. There is another interesting group though. The apps that are genuinely useful and work quite well, but are very specific in nature. The ones that address a really small niche or control an obscure piece of hardware. While the downloads on these may not be huge, in their own context I'd consider them huge successes. That's a category of apps you just don't see in the proprietary world.
No Community, No Project
Many think of an open source “community” as a passel of unpaid developers who code because they love it, but that's not the driving force behind most of the work. In general, only a small group is allowed to modify or submit changes to source code. Other developers submit code to these core developers. But most important for companies assessing the health of a project is the size–and motivation–of the group of users hammering away on the code and identifying what's wrong with it, and how the project responds to that input.
An active community is part of what set Apache apart in the mid-1990s from other freeware, of which IT managers were rightfully wary, says Apache founder Brian Behlendorf. Instead of a site packed with free code, at Apache.org potential business users found the code as it was being developed, with comments being exchanged on recent work. “It was easy to ask questions, to sign up for the mailing list, to see the long conversational threads on support questions,” he says.
Behlendorf is describing the transparency that still marks any vibrant open source project. A community needs to be measured by its activity and transparency as much as its size. The reasons for decisions must be clear, with threads of discussion in forums leading up to them, and negative and positive comments getting their airing. That's one of open source's most powerful ingredients.
Community is absolutely vital to a sucessful Open Source apps. I don't think enough can be said about that. A lot of how the community runs though, comes down to one of the other points they make:
MySQL, Linux, and other successful open source projects all have this in common: a Linus Torvalds sort of figure, a benevolent dictator with the humility to see the value in other people's work. At JBoss, it was Marc Fleury. At MySQL, it's a pair of developers, Monty Widenius and David Axmark, who produced the early versions of MySQL and selected the smooth Marten Mickos as CEO. Ross Mason is the undisputed development leader of Mule, an enterprise service bus gaining traction at financial institutions. Mason's also the founder of MuleSource, the company behind it. At Samba, founded in 1992 to provide file and print capabilities across Windows, Unix, and Linux, it's the diplomatic yet decisive Jeremy Allison.
While it's possible to make it without one of these benevolent dictators it's much much more difficult. In the end it's really almost a component of the community. One that not only keeps things running smoothly, but also provides guidance and long term vision. A well respected leader is also able to diffuse the tenuous situations that well inevitably rise up.
Innovation, Luck and Timing are also huge pieces to the puzzle, as the article points out. While I don't agree with everything in the article, in the end I do think their 9 point checklist for “How To Spot A Successful Open Source Project” are fairly accurate, at least in the Commercial Open Source space:
A thriving community, Disruptive goals, A benevolent dictator, Transparency, Civility, Documentation, Employed developers, A clear license, Commercial support
While your company should look further than that list and should always download the actual code and throughly evaluate the product, the above is a good anecdotal starting point. How does the Open Source software you're evaluating stack up?
–jeremy