Given how dependent we’ve become upon open source software, one would think that we would have a bevy of options for supporting the developers who write the code, but we don’t. Oh, sure, if it’s a big project with big money involved, like Kubernetes, funding is not too hard to find.
But what about a popular JavaScript library (style guide, linter, and automatic code fixer) like Standard? Not so easy, leading one of the founders, Feross Aboukhadijeh, to experiment with an advertising model—and later end the experiment after lots (and lots) of negative feedback.
While concerns about the sustainability of open source are overblown, we should be extraordinarily concerned about enabling the financial independence of open source developers. Here are some ideas for improving the situation.
Think beyond sustainability
The first comes directly from Aboukhadijeh’s recap of his ad-supported funding experiment. As he wrote, “Sustainability is another way to say subsistence. This is why the common phrase ‘open source sustainability’ isn’t ideal.” In other words, developers aren’t interested in starvation wages that keep them alive, barely hanging on to add one more line of code. Instead, he went on, “Folks who work on open source have a right to thrive and to be fairly compensated for our labor.”
Of course, no one has a right to a six-figure salary, but for those developers contributing in excess of that value to enterprises of all shapes and sizes, it’s really not too much to expect that they can write the code we depend upon without having to endure subsistence wages. That’s not good for the open source developers, of course, but it’s also not good for the organizations who depend upon that code. If we want more innovation from open source developers, and we most emphatically do, we should pay for it.
The question is how?
Thinking beyond tip jars
That is, what is the right way to pay for the value open source developers provide? It’s easy to point fingers at corporations and say that they should pay, but it’s not so simple. With so many companies deriving value from open source software, how do we determine which of those companies should pay, and how much, not to mention how? It’s very much a tragedy of the commons, with limited to no mechanisms available to enable companies to pay their “fair share,” even if we could precisely determine just what that “fair share” is.
What about donations? As Aboukhadijeh has noted, “Lots of maintainers struggle to reach a barely livable wage via donations.” This isn’t surprising, given that donations roughly equal a “tip jar,” as Linux Foundation Chris Aniszczyk has derisively described the approach: “While a tip jar can raise some funds, it’s truly not sustainable long term, as outside of it not being an effective way to raise funds for project development, it puts maintainers unfortunately in a gig style economy without health and retirement benefits.”
Such donation systems, while laudable in their goals, are also a burden upon the very people they’re meant to help, as Microsoft developer advocate Christina Warren has elucidated: “[F]or payments, asking projects—esp. single person projects—to support multiple payment/contribution options is unfair. Because as [well]-intentioned as all these various funding platforms are, there’s a lot of extra legwork with regards to taxes and bank accounts and IDs and international stuff and minimum funding and red tape just to get started.”
The Linux Foundation’s Aniszczyk goes on to put the onus for paying developers on those companies that most benefit from their work: “[A] big part of innovation comes from developers working at organizations adopting open source software at scale and using it in interesting ways. It’s these organizations that should be tasked to sustain open source software versus individuals, especially since they depend on open source software to survive as a business.”
Aniszczyk isn’t talking about mega-corps throwing money at mega-tip jars. Rather, he’s talking about the big beneficiaries employing the developers who build the projects upon which they depend.
It’s a great idea, and one that has borne fruit in the Linux community and currently in the Kubernetes world. However it’s done, there’s an underlying principle that is critical to all of this: We need more experimentation.
Experiment more
The first requirement for ensuring open source sustainability is to allow and encourage experimentation. Concerned at his (and other open source developers’) inability to make a comfortable living writing popular open source software, Standard co-founder Aboukhadijeh decided to experiment with an ad-supported model. How would it work? In his words, “Whenever users install open source software, this package will display a message from a company that supports open source. The sponsorship pays directly for maintainer time.” It would look something like this:
Not exactly what most developers expect to see when they fire up the command line and, in fact, there are plenty of reasons to dislike the advertising, whether one is against ad-supported models or not. As developer Robert Hafner put it, “I don’t want to have to view advertisements in my CI logs, and I hate what this would mean if other packages started doing this. Some JS packages have dozens, hundreds, or even more dependencies—can you imagine what it would look like if every package did this?”
It’s a real concern that calls out a significant problem with the experiment. What it doesn’t do, however, is help to answer the fundamental question behind the experiment: How to fund developer time so that open source software is better maintained?
Today, there are no clear-cut ways to ensure that open source developers get paid. We have some inchoate business and funding models that serve open source companies and open source developers more or less well, and too often less. What we need is more people like Aboukhadijeh earnestly experimenting with ways to make things better, more companies like Tidelift introducing novel ways to fund developers, and more organizations recognizing their own self-interest in employing or otherwise paying the developers who build the software they rely on.
It sounds simple, but isn’t, which is why, ultimately, we need more experimentation, and less criticism, starting with me.