Why We Are Paying For Open-source Contributions (And Why You Should Too)

How did we get here?

The current ecosystem of venture-backed open-source projects is undeniably different from the wild west of small project communities that all worked for free. People spent their weekend hours maintaining command line utilities and low-level software that every engineer built their critical workflows around. This, naturally, was a more pure community-driven contribution structure that gave you significant clout for keeping the world of programmers afloat. This may have been enough reward then, and still is today in some cases.

Some important projects are still managed by a small group of engineers who do it for the love of the game. Take for example, Jim Meyering. He is the primary maintainer for coreutils, parted, grep, gzip, diffutils, sed, automake, and gnulib alongside his day job at Meta. Odds are, if you've used any GNU/Linux distribution, he has played a big role in your life as an engineer.

However, as we are an open-source company in the modern age that will ultimately depend on monetizing for success, we admit that the inherent value to contributing will be diluted by the fact that it will help us profit. Our contributors are adding functionality that will help them with their work and this will ultimately help us build out our offering and business. If you run an open-source company in the modern world, you are likely in a very similar situation. Is the existence of your platform reward enough for your contributors? Probably not.

In August of 2000, economists Uri Gneezy and Aldo Rustichini authored a paper that would shed light on an important undercurrent in economic incentivization theory. In their flagship paper, "Pay Enough or Don't Pay at All," they demonstrated that small or meaningless financial rewards disincentivize contribution. Even if you haven't read the paper, the underlying concept is something innately understandable: most people would prefer social accolades over a financial pittance for their volunteer work. This chasm between nothing and reasonable pay has been perpetuating this inertia to profit-sharing. Questions like "What is reasonable pay?" or "What if people get involved for the wrong reasons?" have been asked time and time again.

The brave new world of open-source.

This shouldn't be a particularly controversial or powerful statement:

Everyone who works on a for-profit project deserves a share in that profit.

Open-source has become synonymous with free labor in many circles, an understandable externality to this situation that we find ourselves in. We can clearly see that the original model of contribution around bettering the world just doesn't work for businesses. It doesn't matter that people are contributing for different reasons than they used to. It doesn't matter if people technically benefit from doing work that furthers their career or job. In this day and age, funding work that creates interconnected community layers between businesses is wildly beneficial for the environment.

Paying your contributors encourages cultures of shared knowledge, mutualistic relationships, and provides smoothing to the relationship between maintainer and contributor that is not as genuine as it used to be. Our reason for transparently acknowledging this is to talk about how we are going to start paying contributors for their work on our project, Plural.

What is Plural? How are we are paying contributors?

Plural is an open-source deployment ecosystem where people can use our software to spin up open-source applications on Kubernetes without knowing how to plumb all the YAML and infrastructure as code together. In this ecosystem, we've created resources to help people onboard the applications that they may want to deploy with Plural. Additionally, people can contribute application upgrades by testing out a new version of an application with Plural to make sure that it will work for all the downstream users upon delivery.

There will naturally be work here that our DevOps team of five engineers cannot reasonably get to. Adding every new application and performing application upgrades for an ever-growing catalog is work that community members can find mutual benefit in performing. Because we see outside contributors as part of our future and ability to scale, we want to help them be a part of our business journey.

Earlier I alluded to two questions while discussing the economics of incentivization: "What is reasonable pay?" and "What if people get involved for the wrong reasons?" Let's answer them both. As for reasonable pay, we ran the numbers by a few community members, who raised no objections (we then increased the numbers again after that). We calculated how long the work would reasonably take, multiplied that by a standard rate for engineering work, and got to where we're at. I doubt that this approach is perfect, but as we get more information on how long these processes take, we can update the rewards. As for controlling for bad actors, the DevOps space inherently limits this from happening.

The barrier to entry for Kubernetes DevOps is high enough that most of the filtering has been done for us. For projects that cast a wider net and bring in a larger slice of the developer ecosystem, these high standards need to be enforced through robust CI and code review practices. Bad actors generally don't have the patience to beat systems that force them to do work.

We're currently offering $500 for every application contributed to the catalog and $150 for every application upgrade performed. These numbers don't need to be set in stone, as we'll change it over time as feedback comes in. Keeping an open and honest dialogue with our contributors is the priority and if we've missed the mark, we'd love to hear from you.

If you're interested, join our Discord to start contributing today!