The effects of commercialization on open-source communities

Recent research suggests that much of the core development work on open-source projects is done by paid developers. Is this a bad thing?

The answer is in the data. I just finished reading Evangelia Berdou's Ph.D. thesis "Managing the Bazaar: Commercialization and peripheral participation in mature, community-led Free/Open source software projects," and highly recommend it to anyone seeking to understand how open-source communities operate, especially in light of the increasing encroachment of commercial interests into open-source development communities. Berdou looks at paid vs. unpaid developer contributions to GNOME (GNU Network Object Model Environment) and KDE (K Desktop Environment) and reaches some interesting, if unsurprising, results.

Berdou starts with four primary hypotheses, only two of which end up making the grade:

1. Paid developers are more likely to contribute to critical parts of the code base.
2. Paid developers are more likely to maintain critical parts of the code base.
3. Volunteer contributors are more likely to participate in aspects of the project that are geared towards the end-user.
4. Programmers and peripheral contributors are not likely to participate equally in major community events. (134)

Only Nos. 2 and 4 end up surviving her analysis, though her data (and my experience) suggests that No. 1 is also true.

Using GNOME as an example, roughly half of the developers are "paid" (meaning, remunerated by an organization specifically to develop the GNOME software):

(Credit: Evangelia Berdou)

However, when Berdou analyzes what these different groups actually do on the GNOME project, it becomes clear that while all developers are created equal, some are more equal than others:

(Credit: Evangelia Berdou)

There are those who are paid to work on GNOME who do the lion's share of core development work. Then there are others who are paid to work on free and open-source software, which end up almost wholly focusing on secondary development activities. (See page 139.) And then there are the true volunteers who end up doing the peripheral work.

In a way, as I've written before, this translates into "transparent but not permeable" development. If you're part of the commercial/paid developer crowd, you work on the meatiest parts of the code. If you're "just a volunteer," you're stranded on the boundaries.

Or are you? As Berdou points out, this segmentation may have much to do with practical exigencies, and nothing to do with any designated division of labor:

Substantial and continuous contributions in infrastructural modules, such as desktop and platform libraries, require a high degree of knowledge and technical competence. The ability to work full-time on a project allows paid developers to develop their technical skills and their understanding of the code base to a greater extent than volunteers who usually contribute in their free time. (167)

This makes sense. It doesn't answer the question that Microsoft raised long ago, however: as open source matures, will this translate into selling out to commercial interests?

Berdou notes that "communities have become more responsive to accommodating commercial needs" (171), but is this a good thing?

I think so. Open-source communities have learned over time to integrate commercial interests into their development ranks without capitulating to those commercial interests. There are strong safeguards in place within successful open-source communities (Apache, Linux, etc.) to prevent any one company from hijacking the community. For those corporate-sponsored projects that exercise too much control over the development community for their project, they tend to see less outside community involvement at any level of development within the project.

The system tends to self-regulate. Commercial interest in open-source projects is a Very Good Thing.