TechWorld

3 suggestions for stronger open source projects

How to balance makers and takers to scale and sustain open source projects, companies, and ecosystems (part 5)

In part 4 of this article, I covered how economic theories of collective action can be applied to open source from a conceptual perspective. In this final part, I’ll discuss how these theories can be made actionable for scaling and sustaining open source communities.

Suggestion 1: Don’t just appeal to organizations’ self-interest, but also to their fairness principles

If, like most economic theorists, you believe that organizations act in their own self-interest, we should appeal to that self-interest and better explain the benefits of contributing to open source.

Despite the fact that hundreds of articles have been written about the benefits of contributing to open source—highlighting speed of innovation, recruiting advantages, market credibility, and more—many organizations still miss these larger points.

It’s important to keep sharing open source success stories. One thing that we have not done enough is appeal to organizations’ fairness principles.

While a lot of economic theories correctly assume that most organizations are self-interested, I believe some organizations are also driven by fairness considerations.

Despite the term Takers having a negative connotation, it does not assume malice. For many organizations, it is not apparent if an open source project needs help with maintenance, or how one’s actions, or inactions, might negatively affect an open source project.

As mentioned, Acquia is a heavy user of Varnish Cache. But as Acquia’s chief technology officer, I don’t know if Varnish needs maintenance help, or how our lack of contribution negatively affects Makers in the Varnish community.

It can be difficult to understand the consequences of our own actions within open source. Open source communities should help others understand where contribution is needed, what the impact of not contributing is, and why certain behaviors are not fair. Some organizations will resist unfair outcomes and behave more cooperatively if they understand the impact of their behaviors and the fairness of certain outcomes.

Make no mistake, though: Most organizations won’t care about fairness principles and will only contribute when they have to. For example, most people would not voluntarily redistribute 25% to 50% of their income to those who need it. However, most of us agree to redistribute money by paying taxes, but only so long as all others have to do so as well and the government enforces it.

Suggestion 2: Encourage end users to offer selective benefits to Makers

We talked about open source projects giving selective benefits to Makers (e.g. Automattic, Mozilla, etc.), but end users can give selective benefits as well. For example, end users can mandate open source contributions from their partners. We have some successful examples of this in the Drupal community:

If more end users of open source took this stance, it could have a huge impact on open source sustainability. For governments, in particular, this seems like a logical thing to do. Why would a government not want to put every dollar of IT spending back in the public domain? For Drupal alone, the impact would be measured in tens of millions of dollars each year.

Suggestion 3: Experiment with new licenses

I believe we can create licenses that support the creation of open source projects with sustainable communities and sustainable businesses to support it.

For a directional example, look at what MariaDB did with their Business Source License (BSL). The BSL gives users complete access to the source code so users can modify, distribute, and enhance it. Only when you use more than x of the software do you have to pay for a license. Furthermore, the BSL guarantees that the software becomes open source over time; after y years, the license automatically converts from BSL to General Public License (GPL), for example.

A second example is the Community Compact, a license proposed by Adam Jacob. The Community Compact mixes together a modern understanding of social contracts, copyright licensing, software licensing, and distribution licensing to create a sustainable and harmonious open source project.

I’d love to see new licenses that encourage software free-riding (sharing and giving), but discourage customer free-riding (unfair competition). I’d also love to see these licenses support many Makers, with built-in inequity and fairness principles for smaller Makers or those not able to give back.

If, like me, you believe there could be future licenses that are more “open source” friendly, not less, it would be smart to implement a contributor license agreement for your open source project. A contributor license agreement allows open source projects to relicense if/when better licenses arrive. At some point, current open source licenses will be at a disadvantage compared to future open source licenses.

Balancing makers and takers

As open source communities grow, volunteer-driven, self-organized communities become harder to scale. Large open source projects should find ways to balance Makers and Takers or the open source project risks not innovating enough under the weight of Takers.

Fortunately, we don’t have to accept that future. However, this means that open source communities potentially have to get comfortable experimenting with how to monitor, reward, and penalize members in their communities, particularly if they rely on a commercial ecosystem for a large portion of their contributions. Today, that goes against the values of most open source communities, but I believe we need to keep an open mind about how we can grow and scale open source.

Making it easier to scale open source projects in a sustainable and fair way is one of the most important things we can work on. If we succeed, open source can truly take over the world—it will pave the path for every technology company to become an open source business, and also solve some of the world’s most important problems in an open, transparent, and cooperative way.

A version of this post appeared on Dries Buytaert’s personal blog, Dri.es.