In many ways, open source has won. Most people know that open source provides better quality software, at a lower cost, without vendor lock-in. But despite open source being widely adopted and more than 30 years old, scaling and sustaining open source projects remain challenging.
Not a week goes by that I don’t get asked a question about open source sustainability. How do you get others to contribute? How do you get funding for open source work? But also, how do you protect against others monetizing your open source work without contributing back? And what do you think of MongoDB, Cockroach Labs, or Elastic changing their license away from open source?
This article (in five parts) talks about how we can make it easier to scale and sustain open source projects, open source companies, and open source ecosystems. I will show that:
- Small open source communities can rely on volunteers and self-governance, but as open source communities grow, their governance model most likely needs to be reformed so the project can be maintained more easily.
- There are three models for scaling and sustaining open source projects: self-governance, privatization, and centralization. All three models aim to reduce coordination failures, but require open source communities to embrace forms of monitoring, rewards, and sanctions. While this thinking is controversial, it is supported by decades of research in adjacent fields.
- Open source communities would benefit from experimenting with new governance models, coordination systems, license innovation, and incentive models.
Some personal background
Scaling and sustaining open source projects and open source businesses has been the focus of most of my professional career.
Drupal, the open source project I founded 18 years ago, is used by more than one million websites and reaches pretty much everyone on the internet.
With over 8,500 individuals and about 1,100 organizations contributing to Drupal annually, Drupal is one of the healthiest and contributor-rich open source communities in the world.
For the past 12 years, I’ve also helped build Acquia, an open source company that heavily depends on Drupal. With almost 1,000 employees, Acquia is the largest contributor to Drupal, yet responsible for less than 5% of all contributions.
This article is not about Drupal or Acquia; it’s about scaling open source projects more broadly.
I’m interested in how to make open source production more sustainable, more fair, more egalitarian, and more cooperative. I’m interested in doing so by redefining the relationship between end users, producers, and monetizers of open source software through a combination of technology, market principles, and behavioral science.
Why we must make it easier to scale and sustain open source
We need to make it easier to scale and sustain both open source projects and open source businesses, for these reasons:
- Making it easier to scale and sustain open source projects might be the only way to solve some of the world’s most important problems. For example, I believe open source to be the only way to build a pro-privacy, anti-monopoly, open web. This will require open source communities to be long-term sustainable—possibly for hundreds of years.
- Making it easier to grow and sustain open source businesses is the last hurdle that prevents open source from taking over the world. I’d like to see every technology company become an open source company. Today, open source companies are still extremely rare.
The alternative is that we are stuck in the world we live in today, where proprietary software dominates most facets of our lives.
Disclaimers
This article is focused on open source governance models, but there is more to growing and sustaining open source projects. Top of mind is the need for open source projects to become more diverse and inclusive of underrepresented groups.
Second, I understand that the idea of systematizing open source contributions won’t appeal to everyone. Some may argue that the suggestions I’m making go against the altruistic nature of open source. I agree. However, I’m also looking at open source sustainability challenges from the vantage point of running both an open source project (Drupal) and an open source business (Acquia). I’m not implying that every community needs to change their governance model, but simply offering suggestions for communities that operate with some level of commercial sponsorship, or communities that struggle with issues of long-term sustainability.
Defining open source makers and takers
Makers. Some companies are born out of open source, and as a result believe deeply and invest significantly in their respective communities. With their help, open source has revolutionized software for the benefit of many. Let’s call these types of companies Makers.
As the name implies, Makers help make open source projects; from investing in code to helping with marketing, growing the community of contributors, and much more. There are usually one or more Makers behind the success of large open source projects. For example, MongoDB helps make MongoDB, Red Hat helps make Linux, and Acquia (along with many other companies) helps make Drupal.
Our definition of a Maker assumes intentional and meaningful contributions and excludes those whose only contributions are unintentional or sporadic. For example, a public cloud company like Amazon can provide a lot of credibility to an open source project by offering it as a service. The resulting value of this contribution can be substantial. However, that doesn’t make Amazon a Maker in our definition.
I use the term Makers to refer to anyone who purposely and meaningfully invests in the maintenance of open source software, i.e. by making engineering investments, writing documentation, fixing bugs, organizing events, and more.
Takers. Now that open source adoption is widespread, lots of companies, from technology startups to technology giants, monetize open source projects without contributing back to those projects. Let’s call them Takers.
I understand and respect that some companies can give more than others, and that many might not be able to give back at all. Maybe one day, when they can, they’ll contribute. We limit the label of Takers to companies that have the means to give back, but choose not to.
Organizations can be both Takers and Makers at the same time. For example, Acquia, my company, is a Maker of Drupal, but a Taker of Varnish Cache. We use Varnish Cache extensively but we don’t contribute to its development.
In part 2 of this article, I will focus on how Takers hurt Makers in open source, as well as how the “prisoner’s dilemma” affects the behavior of Takers.
A version of this post appeared on Dries Buytaert’s personal blog, Dri.es.
