Open source has a working-for-free problem

It's a necessary part of open source that we do some work for free. But when it is an expectation—or at least a strong norm—to do everything for free, we have a problem.

Look around. We do have a problem, and it’s time we do something about it.

What developers can learn from designers about spec work

In the design world, there's a strong norm against spec work—see if this quote from nospec.com rings true about open source:

Why is spec work unethical?

The designers work for free and with an often falsely advertised, overinflated promise for future employment; or are given other insufficient forms of compensation. Usually these glorified prizes or “carrots” appear tantalising for designers who are just starting out, accompanied by statements such as “good for your portfolio” or “gain recognition and exposure.”

AIGA, the professional organization for design, also takes a position against spec work.

Unpaid work is one popular, sometimes-effective path to becoming a top-tier well-known developer. The lack of compensation isn't just bad for individual developers—it also creates social problems, by amplifying existing privilege. The issues with free work are well-described in this article on unpaid internships:

The broader effects of unpaid internships are (a) a tendency for employers to take advantage of young labor by offering the currency of experience in lieu of actual currency, and (b) a widening of the social inequality gap as lower-income students are implicitly barred from this so-called "educational" experience, which is their gateway to full-employment in the field of their choosing.

We can start to mitigate this impact with wonderful paid internship programs such as Outreachy, but there's a much larger structural problem, too.

Let's abandon the notion that open source is exclusively charity

In the software industry, we're normalizing spec work in a way that the design industry successfully rallied against.

The narrative around open source is that it's completely OK—even an expectation—that we're all doing this for fun and exposure; and that giant companies should get huge publicity credit for throwing peanuts-to-them donations at a small subset of open source projects.

There's nothing wrong with doing stuff for fun and exposure, or making donations, as an option. It becomes a problem when the free work is expected and the donations are seen as enough.

It actually seems to blow people's minds when open source maintainers ask for money for value provided. As Kyle Mitchell puts it, the message to open source maintainers appears to be "profit for us, sustainability for you."

A common pattern: one or a few unpaid maintainers, buried in pull requests and issues submitted by paid professionals using the software at work.

The fact is that open source isn't charity, most of the time. It's been a critical part of huge, profitable businesses for two decades. The vast majority of open source usage and work happens in a commercial context.

The charity framing truly goes off the rails when a company does actually pay for value… and nobody doing the work on the project actually gets that money, for their own personal use. Instead, the money goes into a nonprofit fund for scholarships or similar. Again, there's nothing wrong with the charity funding pool existing, but it isn't solving the same problems that actually compensating professionals for professional work can solve.

What would open source be like if we had a professional class of independent maintainers, constantly improving the code we all rely on?

Charity works best for "brand name" projects

A "Hello, World" single-page JavaScript application contains around a thousand packages… our preliminary research shows about a quarter of those have been completely ghosted for a year or more (no releases, no commits, PRs/issues ignored). On top of that quarter, many more are under-maintained, though not completely ghosted. And this isn't a JavaScript-only problem.

The well-known headline packages in this kind of app might be maintained by a big company, or have a sizable Patreon…but the other 990 packages aren't.

It is OK to confidently say no to free grunt work

In the past, exclusively pay-to-play open source projects haven't done very well; they end up forked or ignored, because requiring people to pay to participate at all makes it too hard to gain adoption and create a thriving community. There's a delicate balance to be found.

While keeping that balance in mind, there's a line where some work simply doesn't need to happen for free. For example, Mikeal Rogers suggests that we stop supporting old releases for free. Here are some other examples to consider:

• Support requests. Bug reports are one thing, but there's no reason maintainers need to hand-hold anyone for free. Create a forum or use StackOverflow for people to support each other; create and advertise paid support options; if you don't want to do it for free, don't!

• Extra releases. I commonly get a request like "can you make a special one-off release now on my timeline, because I want this one change;" I don't feel obligated to do that.

• Extreme stability. If I'm working for fun and only thinking about community-engaged users, I'm going to break things or clean up deprecated stuff a lot more often than if I'm thinking about commercial users.

• Legal checkboxes. There are license-metadata-annotation practices that are helpful for big companies trying to audit the code they use, but sort of a pain in the ass and nobody cares other than these big companies.

• Extra-thorough engineering. Extremely good test coverage, security audits and hardening, whatever isn't fun for you. There's no reason to go beyond what you enjoy.

• Prompt patch review and issue triage. This one is tricky, but experienced maintainers know that every pull request is a demand on their time. There's no reason you have to run a community development model open to all comers, just because that's the GitHub default; some projects are explicitly opting out of this, because the maintainer(s) want to focus on writing code themselves.

• Extra mile on security. There's a pretty good learning curve on an ideal security process; we should all be using two-factor authentication everywhere; we ought to sign our packages. We may feel guilty about these things, but as a whole open source maintainers haven't reliably done them.

Every maintainer and project will want to draw this line a little differently. This is an area of active exploration and negotiation: how can communities thrive, without doing everything for free—and in particular skipping enterprise-oriented or commercial-oriented boring grunt work, when those big commercial users aren't paying for value?

Right now many users expect, and demand, that all of this will be free. As an industry, perhaps we should push back harder on that expectation. It's OK to set some boundaries.

No projects actually do all the grunt work that their users might want, by the way. But the boundaries aren't often spelled out explicitly, which leads to frustration on all sides.

One solution: charge more!

Patrick McKenzie has a catch phrase "Charge More!", which he proposes as the solution to many problems. It can help a lot with burnout.

Developers often feel guilty about asking for money, for reasons like:

• they actually enjoy the work they're doing

• it doesn't take that much time to do any one thing

• what if someone yells at me?

Look, the businesses using your software don't consider these factors! They don't even use "cost plus" pricing—that is, they don't ask "how much does this software cost to make?" and charge that plus 10%. Instead they ask "how much is this software worth to the buyer," and they charge that. This is called value-based pricing.

Open source maintainers deserve to use value-based pricing. YOU deserve to use it. Your users are all charging their customers on value, not on cost. And many of them are also willing to pay for value, regardless of your costs.

Charging for value reduces entitlement

At Tidelift, we've had a few maintainers ask us whether companies paying for the Tidelift Subscription feel entitled to demand too much from maintainers. It's counterintuitive, but our experience is that the opposite is true; many people running a software business have commented that the less a customer pays, the more support-intensive they are. Free users are the most difficult, not the least.

For countless amusing examples of this if-I-pay-nothing-I'm-entitled-to-everything phenomenon, I recommend the ChoosingBeggars subreddit. Of course the open source maintainers among us have likely experienced some less-amusing examples.

Even if we do a lot of free work, it can be helpful to have a "list price," to set expectations. (Many maintainers could regularly and honestly say "the pull request review I just did for you would cost $5000 if I charged market rates for my time." Few of us behave as if this were true, even though it is.)

Don't forget, when you charge for value, you're giving people value

Lots of companies would love to have that extra mile of grunt work that we can't reliably get done for free. And while it's difficult to measure, imagine a couple hundred full-time, independent maintainers working on your thousand dependencies… anytime you're frustrated by missing docs, bugs, missing features, dependency hell, and the like, think about the value of paying the maintainers.

From the perspective of companies who can pay, it's often better for them if they have to pay. In general, companies are unable to make optional payments. They may also be unable to make a payment without a salesperson to walk the purchase through their own internal processes. Making it an optional “tip jar” kind of request is a disservice, because companies struggle to engage on those terms.

Of course, there are some practical barriers

If you change your project README to say "hey, I'm not doing grunt work categories A, B, and C for free," you'll probably find it's not so simple.

• You'll get howls of protest from the choosing beggars of the world

• Some of those protests will be from highly paid software developers, who are maybe even compensated to work on open source in some way, but who simultaneously believe that independent maintainers shouldn't be paid because open source should be charity

• Your project may be too small (one of a thousand dependencies) for companies to engage with and get through their purchasing department

• You'll have to set up a minimum viable business, dealing with sales, payments, accounting, and taxes

In many open source contexts, it's important to minimize friction. A developer using a project might have a PR or issue to submit, or another small request for a maintainer's time; they might be willing to pay $300 for that, in theory, but in practice there's no good way to get a one-time $300 check out of their employer. Spending money is a whole process with high overhead at most big companies. It won't make sense to go through this process over and over for every micro-interaction with an open source project.

This means that if someone files an issue or asks for something on chat, and you say "I can't do that for free," as a maintainer you've more or less told them to pound sand; there's nothing they can do. On my projects, I find this makes me reluctant to take a firm stance.

This is a worthwhile problem for the open source world to unpack

So to recap, some issues with unpaid work:

• Social equity—right now, open source makes tech's diversity problem worse; we are part of the problem

• Lack of maintenance, with numerous projects we all rely on ghosted and under-maintained

• Entitlement: when we don't put a value on our time, people assume its value is low

• Maintainers are passionate about working on the projects they know best, and just need the income to give them the time to do it!

Questions I'd love to see us all wrestle with more:

• Which categories of work need to be unpaid for open source communities to thrive?

• Which other categories of work need to be paid, for open source projects to have independent maintainers with reliable incomes?

• How can projects make expectations clear to users and give companies a route to pay for value received?

• How can the most popular, headline projects help address this for the rest of the dependency graph?

The potential benefit, restated: a more diverse, more appreciated, professional class of independent maintainers, constantly improving the code we all rely on.

Of course this relates to what we do at Tidelift—the company came out of discussions about this problem, among others. Our broad mission is to make open source work better, for everyone. In our day-to-day right now we're specifically striving to give subscribers a way to pay maintainers of their application dependencies for additional value, through the Tidelift Subscription.

But we hope to see many more efforts and discussions in this area. We believe there are unexplored avenues. Social media back-and-forth about new licenses and open source business models tends to focus on headline projects and VC-funded companies, rather than smaller independent projects and libraries. But in between a virtual tip jar and $100 million in funding, there's a vast solution space to explore. We want to be part of figuring this out, along with all of you.