Demographic Research on the Open Source Development Community

It bugs me how blogging throws away one of the most important aspects of journalism: getting both sides of the story. So before running the following piece about open source, I decided to show it to the person whose work I’m writing about, Rishab Ghosh, who is program leader at the Maastricht Economic Research Institute on Innovation and Technology (MERIT) at the University of Maastricht in the Netherlands. I thought it’d be interesting to run his responses to what I wrote because he disagrees with some of it. It should start a useful dialog in your head about open source. Here goes:

It’s clear how CIOs should evaluate a traditional software company: You look at the company’s financials, talk to customer references, try to get a demo or pilot using your own data and business processes and find out how many developers the company has, among other things.

But if the software is open source, the picture changes dramatically. The company is now a community, the references are postings on a bulletin board and the developers may not even be employed. Their motives for building the next release don’t depend on the boss and the 401k—indeed, their bosses might fire them if they found out they were staying up all night working on something that had nothing to do with their day job. That’s why it pays to know who these open source developers are and what motivates them. As open source moves up the infrastructure stack into mission-critical chunks of the infrastructure, the motivations of this community should become more than cocktail conversation; It’s critical business research. You want to start tracking this community like you track SAP’s stock price, its acquisition strategies and its upgrade announcements.

One of the most thorough surveys ever done with the open source community was coordinated by the Free/Libre and Open Source Software (FLOSS) project at the Maastricht Economic Research Institute on Innovation and Technology (MERIT) at the University of Maastricht. Here are some important details from it:

Personal Stats: Developers are male (between 92 and 99 percent) and scary young (60 percent between the ages of 16 and 25), though most (roughly 60 percent) have some kind of steady love interest (and you thought all nerds were lonely…).

Ghosh: The paper you cite and, better, the flossproject final report and in particular the presentation show that most developers have “low activity” in projects. “High activity” developers do most of the work, and tend to be older (30+) with more responsibilities (e.g., married with small children) and an income closely related to their [open source] activities.

Motivations: Open source is directly tied to developers’ interest in lifelong learning—but that interest is stoked by the opportunity to let others see how much they’ve learned. They want experience, exposure, competition and ego stroking. The survey found that most developers (53.2 percent) get into it for social reasons, but deconstruct that category on the survey and you get responses like “learn and develop new skills” and “share knowledge and skills.” Sure, there is some peace-and-love stuff here, too, such as “participate in a new form of cooperation” or “be part of the open source scene.” But when you combine those findings with the 31 percent who said they got into it for clear career reasons like “improve my job opportunities” and “get a reputation in the community,” you have a community that, if not about money, is very definitely about learning, career and reputation. So they are like the rest of us after all. The author of the study, Rishab Aiyer Ghosh, sums it up nicely: The free software movement is a “voluntary training environment.” (Which helps explain why so much open source software sucks or is abandoned. These people are learning, and they make mistakes and often find that they weren’t necessarily cut out to be a project manager and leader of men like Linus Torvalds.)

Ghosh: A general comment about “they are like the rest of us, after all.” I wrote that “the Internet is not a new world where normal people are magically transformed [into] altruists. The Internet is certainly new, but it is a new medium of expression, not a new way of life.” [Open source] developers are not strange people, nor is open source a new phenomenon. I edited a book, CODE: Collaborative Ownership and the Digital Economy, which was published a few months ago with a star cast of contributors from the fields of law, economics, biotech/genetics, music and anthropology that shows a number of parallels with other forms of “collaborative ownership and production” at different times in our history, from academic science and the human genome project to Australian aboriginal art.

On the training aspect, see the paper on skills analyses results of parallel surveys of developers and HR managers to identify what skills are learned in [open source] communities, how they compare with formal education, and what employers think of them. Interestingly, even employers for whose business open source does not play an important role (and who are thus relatively ignorant about how the community works) think that several technical and teamwork skills are better learned through floss community participation than through formal education.

Project initiation: A relatively small percentage of developers said they got into open source to solve a problem that couldn’t be solved by proprietary software—the impetus behind some of the major pieces of the most famous open source projects, like Linux and Apache, for example, and the one most accepted by the media (me included).

Ghosh: I didn’t think this was a myth that needed busting. Web servers and operating systems existed before Linux and Apache, and the motivation was typically related to learning (in the case of Linus Torvalds) and building one’s own product (Apache). See my 1996interview with Linus on free software economics. Even the motivation for truly innovative software, in technological terms (e.g., Zope, Plone, Perl, of which proprietary equivalents don’t really exist) is not usually stated in product-requirement terms. But don’t confuse stated motivation with implicit benefits, which may well be implicit motivators. As my paper says, earning money is cited as a motive by only 12 percent but 50 percent earn money from their [open source] activities.

Organization: Here, too, the legend of open source takes a bit of a beating. Though there are many, many users of open source software, there are very few developers. Open source guru Eric Raymond’s famous pronouncement that “given enough eyeballs, all bugs are shallow” is only proven out if all those eyeballs care enough to report the bugs—few are actually fixing them (71.9 percent said they had been involved in between one and five open source projects, and 50 percent said they were only in contact with between one and five developers on a project). Users vastly outnumber developers, just as in proprietary software.

Ghosh: This is probably a misinterpretation of our data as well as of Eric’s argument, which was that users can contribute more actively (e.g., by reporting bugs) than with proprietary software. See what Linus says about the importance of user contributions in my 1996 First Monday interview with him. Our survey data looks only at self-classified “developers,” and seems to support the case that there is a “long tail” of contributions from people who would classify themselves as “users” but do far more than the passive users of proprietary software. In any case, a power law distribution of effort (few people doing most of the work) is expected in any self-organizing, self-reinforcing system. It is typical for most forms of output (from music sales to citations in scientific papers) but is not typical for work organized within firms (e.g., proprietary software) where peoples’ contributions are more uniform, regulated by employment contracts. The power of [open source] organization is not that there are vast numbers of people doing all the work (though there are indeed vast numbers); it is that while a relatively small number do most of the work (as with proprietary software), they can tap into a vast number of others who collectively fill in the gaps.