Scaling Open Source communities

We truly live in miraculous times. Open Source is at the core of the largest organizations in the world. Open Source is changing lives in emerging countries. Open Source has changed the tide of governments around the world. And yet, Open Source can be really difficult. Open Source can be largely a thankless job. It is hard to find volunteers, it is hard to find organizations to donate time or money, it is hard to organize the community, it is hard to learn, it is hard to attract full-time contributors, and more. As the project lead for Drupal, one of the largest Open Source projects/communities in the world, I live these challenges every day. In this blog post, I will analyze the challenge with scaling Open Source communities and recommend a solution for how to build very large Open Source communities.

Open Source projects are public goods

In economic terms, for something to be a "public good", it needs to match two criteria:

  1. non-excludability - it is impossible to prevent anyone from consuming that good, and
  2. non-rivalry - consumption of this good by anyone does not reduce the benefits available to others.

Examples of public goods include street lighting, national defense, public parks, basic education, the road system, etc. By that definition, Open Source software is also a "public good": we can't stop anyone from using Open Source software, and one person benefiting from Open Source software does not reduce the benefits available to others.

The realization that Open Source is a public good is a helpful one because there has been a lot of research about how to maintain and scale public goods.

Public goods and the free-rider problem

The biggest problem with public goods is the "free rider problem". A free rider is someone who uses a public good but who does not pay anything (or pay enough) towards its cost or production. If the maintainers of a public good do not address the free-rider problem it can lead to the non-production or under-production of a public good. This is generally known as the "Tragedy of the Commons".

In Open Source, a free-rider is someone who uses an Open Source software project without contributing to it. If too few people or organizations contribute to the project, the project can become unhealthy, and ultimately could cease to exist.

The free-rider problem is typical for public goods and does not usually arise with private businesses. For example, community-maintained software like Drupal may have many free riders but proprietary competitors like Adobe or Sitecore have no problem excluding those who will not pay a license fee.

To properly understand the free-rider problem and public good provision, we need to understand both self-interest theory and the theory of collective action. I'll discuss both theories and apply them to Open Source.

Self-interest theory

Open Source contributors do amazing things. They contribute to fixing the hardest problems, they share their expertise, and more. Actions like these are often described as altruistic, in contrast to the pursuit of self-interest. In reality, generosity is often driven by some level of self-interest: we provide value to others when it benefits ourselves.

Many reasons exist why people contribute to Open Source projects; people contribute because they enjoy being part of a community of like-minded people, to hone their technical skills, to get recognition, to try and make a difference in the world, because they are paid to, or for different forms of "social capital". Often we contribute because by improving the world we are living in, we are making our world better too.

Modern economics suggest that both individuals and organizations tend to act in their own self-interest, bound by morals, ethics, the well-being of future generations and more. The theory of self-interest goes back to the writings of the old Greeks, is championed by early modern economists, and is still being adhered to by late-modern economists. It follows from the theory of self-interest that we'd see more individuals and organizations contribute if they received more benefits.

While contributing to Open Source clearly has benefits, it is not obvious if the benefits outweigh the cost. If we can increase the benefits, there is no doubt we can can attract more contributors.

Collective action theory

The theory of self-interest also applies to groups of individuals. In his seminal work on collective action and public goods, economist Mancur Olson shows that the incentive for group action diminishes as group size increases. Large groups are less able to act in their common interest than small ones because (1) the complexity increases and (2) the benefits diminish.

We see this first hand in Open Source projects. As an Open Source project grows, aspects of the development, maintenance and operation have to be transferred from volunteers to paid workers. Linux is a good example. Without Red Hat, IBM and Dell employing full-time Linux contributors, Linux might not have the strong market share it has today.

The concept of major public goods growing out of volunteer and community-based models is not new to the world. The first trade routes were ancient trackways, which citizens later developed on their own into roads suited for wheeled vehicles in order to improve commerce. Transportation was improved for all citizens, driven by the commercial interest of some. Today, we certainly appreciate that full-time government workers maintain the roads. Ditto for the national defense system, basic education, etc.

The theory of collective action also implies that as an Open Source project grows, we need to evolve how we incent contributors or we won't be able to attract either part-time volunteers or full-time paid contributors.

Selective benefits

Solutions for the free-rider problem and collective action problem exist, and this is where Open Source can learn from public goods theory and research. The most common solution for the free-rider problem is taxation; the government mandates all citizens to help pay for the production of the public good. Taxpayers help pay for our basic education system, the road system and national defense for example. Other solutions are privatization, civic duty or legislation. These solutions don't apply to Open Source.

I believe the most promising solution for Open Source is known as "privileged groups". Privileged groups are those who receive "selective benefits". Selective benefits are benefits that can motivate participation because they are available only to those who participate. The study of collective action shows that public goods are still produced when a privileged group benefits more from the public good than it costs them to produce it.

In fact, prominent "privileged groups" examples exist in the Open Source community; Automattic is a privileged group in the WordPress community as it is in a unique position to make many millions of dollars from WordPress.com. Mozilla Corporation, the for-profit subsidiary of the Mozilla Foundation, is a privileged group as it is in a unique position to get paid millions of dollars by Google. As a result, both Automattic and Mozilla Corporation are willing to make significant engineering investments in WordPress and Mozilla, respectively. Millions of people in the world benefit from that every day.

Drupal is different from Automattic and Mozilla in that no single organization benefits uniquely from contributing. For example, my company Acquia currently employs the most full-time contributors to Drupal but does not receive any exclusive benefits in terms of monetizing Drupal. While Acquia does accrue some value from hiring the Drupal contributors that it does, this is something any company can do.

Better incentives for Drupal contributors

It's my belief that we should embrace the concept of "privileged groups" and "selective benefits" in the Drupal community to help us grow and maintain the Drupal project. Furthermore, I believe we should provide "selective benefits" in a way that encourages fairness and equality, and doesn't primarily benefit any one particular organization.

From the theory of self-interest it follows that to get more paid core contributors we need to provide more and better benefits to organizations that are willing to let their employees contribute. Drupal agencies are looking for two things: customers and Drupal talent.

Many organizations would be eager to contribute more if, in return, they were able to attract more customers and/or Drupal talent. Hence, the "selective benefits" that we can provide them are things like:

  • Organizational profile pages on drupal.org with badges or statistics that prominently showcase their contributions,
  • Advertising on the drupal.org in exchange for fixing critical bugs in Drupal 8 (imagine we rewarded each company that helped fix a critical Drupal 8 bug 10,000 ad views on the front page of drupal.org),
  • Better visibility on Drupal.org's job board for those trying to hire Drupal developers,
  • The ability to sort the marketplace by contributions, rather than just alphabetically
  • ...

I'm particularly excited about providing ads in exchange for contributing. Contributing to Drupal now becomes a marketing expense; the more you contribute, the more customers you can gain from drupal.org. We can even direct resources; award more ad views in exchange for fixing UX problems early in the development cycle, but award critical bugs and beta blockers later in the development cycle. With some relatively small changes to drupal.org, hiring a full-time core developer becomes a lot more interesting.

By matching the benefits to the needs of Drupal agencies, we candirect more resources towards Drupal development. I also believe this system to be fair; all companies can choose to contribute to Drupal 8 and earn advertising credits, and all participants are rewarded equally. We can turn Drupal.org into a platform that encourages and directs participation from a large number of organizations.

Systems like this are subject to gaming but I believe these challenges can be overcome. Any benefit is better than almost no benefit. In general, it will be interesting to see if fairness and heterogeneity will facilitate or impede contribution compared to Open Source projects like WordPress and Mozilla, where some hold unique benefits. I believe that if all participants benefit equally from their contributions, they have an incentive to match each other's contributions and it will facilitate the agreement and establishment of a contribution norm that fosters both cooperation and coordination, while minimizing gaming of the system. In contrast, when participants benefit very differently, like with WordPress and Mozilla, this decreases the willingness to cooperate, which, in turn, could have detrimental effects on contributions. While not necessarily the easiest path, I believe that making the system fair and heterogeneous is the "Drupal way" and that it will serve us in the long term.

Conclusions

There are plenty of technical challenges ahead of us that we need to work on, fun ideas that we should experiment with, and more. With some relatively small changes, we could drastically change the benefits of contributing to Drupal. Better incentives mean more contributors, and more contributors mean that we can try more things and do things better and faster. It means we can scale Drupal development to new heights and with that, increase Open Source's impact on the world.

(I talked about this in my DrupalCon Amsterdam keynote. If you're hungry for more, I recommend that you check out my slides or video recording.)

Comments

Sumeet Pareek (not verified):

@Dries: The tweets that called out your Amsterdam keynote as one of the best so far, and suggested other open source projects listen to it too, now make even more sense. This is a very commendable vision of yours.

Overtime, it would be great to factor in not just code commits, but documentation edits, drupal.stackexchange points, volunteering at events, and many more things too. (Of course the 'cheating the system' challenges would need to be addressed along the way.)

I would also suggest that there be a leader board of sorts broken down by week/month/year etc like there is on the stackexchange network, such that new entrants to the community get to be up there along with the veterans.

Again, a very interesting vision. Kudos.

September 30, 2014
Eric (not verified):

While I understand agencies make up a large portion of developers in the Drupal community, I wonder what incentives could be extended to non-agency enterprises and organizations that employ Drupal contributors.

Ads on drupal.org would be significantly less beneficial to Twitter, UC Berkeley, or NASA, for instance, compared to an agency or development shop.

October 01, 2014
jhedstrom (not verified):

I think the benefit to organizations would be when it comes to hiring. Folks looking for a job would see that the organization in question participates directly in contributing to Drupal.

October 03, 2014
marcingy (not verified):

With the incentive scheme, where is the incentive for people working with business that have no clients or don't sell services?

October 01, 2014
Dries:

There are ways we can provide selective benefits to individual contributors or small end-users; I suggested some in the blog post actually. Examples include better profile pages (better recognition), better access to Drupal talent for those who are hiring, etc.

October 01, 2014
jhodgdon (not verified):

Expanding on macingy's comment (I was having similar thoughts)... There are many of us who contribute large amounts of time/effort to Drupal core and contrib development who are freelancers or for whom Drupal contributing is purely a personal volunteer effort, unrelated to a paying job. I do not think that people in this category would benefit much or at all from the "free Drupal.org advertising if you fix bugs" model, or similar offers for increased publicity on Drupal.org.

So, what I would like to suggest, in addition to the ideas above, is that we could integrate things like the Gittip Drupal Core Team (which provides funding for otherwise unsupported Core contributors) and Drupalfund (which funds Drupal projects) into our ecosystem of recognition. The idea would be to recognize companies who contribute financially to Drupal contributors or fund Drupal projects, alongside those who contribute their employees' time directly to the project.

I also think that any idea we adopt should be applicable to contrib module/theme/distribution development as well as Core -- Drupal Core is important, but very few sites get built without contributed add-ons either.

October 01, 2014
Adelle Frank (not verified):

I LOVE this vision, but also agree with Sumeet that other forms of work/contribution need to be recognized. And Eric is so right that advertising is a less useful incentive to non-profits.

I have one more question to add: How do we scale for the little people?

We solo or education-based people are often the largest portion of the CMS market, and need the biggest support to learn how to contribute. Because of our small resources, we also need support to become leaders in the community who can help others.

I applaud this wonderful vision and hope we can keep Drupal awesome for many years to come!

October 01, 2014
Kelly Albrecht (not verified):

I was a little disappointed to find that the answer to scaling open source communities was simply "embracing privileged groups and selective benefits."

While I do think providing better incentives is a good idea in general, the real issue that I'm seeing with scaling open source communities is having enough people in the industry to do all the work.

We already have monthly sprint days at my company to contribute to Drupal because of the current incentives. Enhancing incentives on drupal.org is not necessarily going to increase the number of people on my team who can contribute.

Worse than that, I'm seeing an increase in large organizations having a hard time supporting their Drupal infrastructure efficiently because they can't find enough help. They are second guessing their choice to move to Drupal. I'm hesitant to believe that enhancing incentives on drupal.org will do enough to turn the tide of this issue.

October 02, 2014
Joaquin Bravo … (not verified):

I agree with Kelly in that I think the education problem is much bigger than the recognition problem. In fact, I don't think we have a recognition problem at all in terms of getting more people to contribute. People already do contribute and get individual recognition which allows them to get better jobs or close deals. Getting more people to contribute involves training more people. Despite this, I think it would be useful to have this information available, and displaying that info on agencies would be very interesting. I'm not so sure about giving ads because I think this will only benefit big organizations. 2 ads for a small company against 2000 ads for a big one is not fair. I don't think 2 ads will get any small organization a new deal. And I'm afraid we would become a little more like wordpress and automattic.

I also don't see that we have a free rider problem. Software doesn't degrade because more people use it. Free software benefits when more people use it because you have more testers and more possible future contributors. So giving negative incentives to organizations not contributing would actually hurt this.

October 05, 2014

Updates from Dries straight to your mailbox