Scaling and Sustaining Open Source, Part 1: Defining Open-Source Makers and Takers
Despite open source being widely adopted, and more than 30 years old, scaling and sustaining open source projects remains challenging.
Join the DZone community and get the full member experience.Join For Free
To scale and sustain open-source ecosystems in a more efficient and fair manner, open-source projects need to embrace new governance, coordination, and incentive models.
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 remains challenging.
You may also like: Making Money From Open Source Software: The Dichotomy
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 series 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.
A Little Bit of 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 percent 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 It Must Be 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:
- 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. It requires 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.
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.
Lastly, this series is long and dense. I'm 700 words in, and I haven't started yet. Given that this is a complicated topic, there is an important role for more considered writing and deeper thinking. Let's get started.
Defining Open-Source Makers and Takers
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.
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.
The difference between Makers and Takers is not always 100 percent clear, but as a rule of thumb, Makers directly invest in growing both their business and the open-source project. Takers are solely focused on growing their business and let others take care of the open-source project they rely on.
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.
Takers Hurt Makers
To be financially successful, many Makers mix open-source contributions with commercial offerings. Their commercial offerings usually take the form of proprietary or closed source IP, which may include a combination of premium features and hosted services that offer performance, scalability, availability, productivity, and security assurances. This is known as the Open Core business model. Some Makers offer professional services, including maintenance and support assurances.
When Makers start to grow and demonstrate financial success, the open-source project that they are associated with begins to attract Takers. Takers will usually enter the ecosystem with a commercial offering comparable to the Makers', but without making a similar investment in open source contribution. Because Takers don't contribute back meaningfully to the open-source project that they take from, they can focus disproportionately on their own commercial growth.
Let's look at a theoretical example.
When a Maker has $1 million to invest in R&D, they might choose to invest $500k in open source and $500k in the proprietary IP behind their commercial offering. The Maker intentionally balances growing the open-source project they are connected to with making money. To be clear, the investment in open source is not charity; it helps make the open-source project competitive in the market, and the Maker stands to benefit from that.
When a Taker has $1 million to invest in R&D, nearly all of their resources go to the development of proprietary IP behind their commercial offerings. They might invest $950k in their commercial offerings that compete with the Maker's, and $50k towards open source contribution. Furthermore, the $50k is usually focused on self-promotion rather than being directed at improving the open-source project itself.
Effectively, the Taker has put itself at a competitive advantage compared to the Maker:
- The Taker takes advantage of the Maker's $500k investment in open source contribution while only investing $50k themselves. Important improvements happen "for free" without the Taker's involvement.
- The Taker can out-innovate the Maker in building proprietary offerings. When a Taker invests $950k in closed-source products compared to the Maker's $500k, the Taker can innovate 90 percent faster. The Taker can also use the delta to disrupt the Maker on price.
In other words, Takers reap the benefits of the Makers' open-source contribution while simultaneously having a more aggressive monetization strategy. The Taker is likely to disrupt the Maker. On an equal playing field, the only way the Maker can defend itself is by investing more in its proprietary offering and less in the open-source project. To survive, it has to behave like the Taker to the detriment of the larger open source community.
Takers harm open-source projects. An aggressive Taker can induce Makers to behave in a more selfish manner and reduce or stop their contributions to open source altogether. Takers can turn Makers into Takers.
That's all for this installment. Stay tuned for part two where we talk more about OS contributions and the Prisoner's Dilemma!
[DZone Guide] Open Source: Democratizing Development
Published at DZone with permission of Dries Buytaert, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.