Free versus paid support in open source

As I watched Arsenal beat Ajax this afternoon, I kept an eye on an interesting piece of research from The Journal of Systems and Software written by Sowe et al. and entitled Understanding knowledge sharing activities in free/open source software projects: An empirical study [PDF]. The research revealed something that I suspected but had not yet seen data to prove: developer communities are great for developers, and not so great for anyone outside them.

What does this mean if you're an enterprise hoping to hitch a free ride on an open-source project? Well, it means that you're better off paying a little money for professional support. Free support is good up to a point, but if that point ends when your job begins, you may be in a world of hurt without it.

Here are a few of the more salient points from the study (and from the other papers it cited):

• Studies utilizing developer mailing lists show that only a handful of core and active developers discuss code development (Barahona et al., 2004; Mockus et al., 2002) , with very little discussion on some of these lists (e.g., the Apache web server list). You're either in the know, or you're not, apparently.


• Lakhani and Hippel (2003)...found that ~2% of the knowledge providers were responsible for about 50% of the answers to questions posted on the help system and 50% of the questions were provided by 24% of the knowledge providers. [In other words, you get a lot of mileage out of just a few people - in terms of resolving questions and in posing questions - and most others are along for the ride. On Apache, especially, only a few people actively answer questions on the list.]


• Krogh et al. (2003) found that 36.7% of new participants [to the developer, not user list] got no response to their questions. [Apparently, the best source of support will not be a pure community.]

This becomes particularly interesting when you look at the difference between developer mailing lists and those dedicated to users of a given project:

• [Studying the Debian mailing lists, Sowe et al. found that] [i]n the Developer list participants contributed more replies (mean = 34.52) than posts (7.95). The reverse was the case in the User list. Participants posted more than they replied to questions asked in the list. One explanation for this could be, as Mockus et al. (2002) discovered in the developer mailing list of the Apache project, postings in the developer lists may contain sufficient information to allow others to comment on them...[whereas the user questions are not considered interesting or informative enough to warrant a response].

In other words, if you already know your way around the code of Debian or Apache, you're more likely to get a response. This makes sense, because developers don't want to waste time on "dumb" questions. The problem, however, is that many newbie questions are going to be "dumb" to the developer, yet not the less important to the would-be user.

This dearth of response is all the more distressing considering the researchers discovery that experienced members of the community, not newbies, answer the most questions. One might guess that the core community members/developers would not take the time or effort to contribute to mailing lists, but the inverse is true. The new users, however, apparently can't speak the right language for such developers and so are locked out of effective use of the community.

As I mentioned above, this means that there is plenty of room for commercial open-source support models. Support for those who aren't the uber-geeks, which is 99.9999999999999999% of the world's population. Experienced Linux developers may not need Linux support, but there are no experienced SugarCRM, MuleSource, JasperSoft, etc. developers outside the core communities. Or, rather, not enough to mean that these companies would run out of support customer candidates anytime soon.

Indeed, in talking with commercial open-source vendors who charge for support, it seems clear that for the first few years of a project's existence, support is a highly viable business model. It's only after the project and community matures that other value offerings (e.g., support/knowledge portals like JBoss Operational Network, etc.) become critical to maintain and grow download-to-purchase conversions.

Net net: If you're an enterprise interested in open source, budget the money for support. By the time you don't need it anymore, that community (or the company behind it) will be offering additional value that you will probably need, so you'll continue to pay. It's a very small price to pay for access to understanding.