Paying maintainers: the HOWTO

As part of the xz discussion, some asserted that “paying maintainers doesn’t work—we tried to give people money and they wouldn’t take it.” Suffice to say, at Tidelift, we think that’s wrong, and we have been proving it for years. Unfortunately, it is a surprisingly complicated topic—we spent nearly a year talking to maintainers about what they needed before we wrote our first check, and paying maintainers is core to our mission.

It is no surprise that lots of well-intentioned people have failed to figure out how to effectively pay maintainers. In the name of lifting all boats, I thought it was finally time to write down what we’ve learned about paying maintainers in the past seven years of doing it at scale at Tidelift.

Background: we do, in fact, pay maintainers

Yes, hi, we’re Tidelift. On behalf of our customers, we pay hundreds of maintainers millions of dollars. If you’d like to read some specific stories about what maintainers have done with the money, start here. If you’d like to read more about the value customers get from paying maintainers through Tidelift, start here. 

HOWTO

So how can you pay maintainers to improve their projects? Here are some of the key lessons we’ve learned from paying maintainers at scale.

(1) The kinds of projects to pay

There are a lot of open source projects out there, and you probably have limited money to pay them. How do you figure out where your investment will have the most impact?

Small projects, not big ones

“Pay small projects, not big ones” is not a universal rule (and we do have some successful examples of paying bigger projects where they can use the income), but it has become central to our approach. There are a few reasons why, including:

• Smaller projects are almost always ignored: Big projects often have clear avenues for funding, and just as importantly are often extremely visible. The funding mechanisms aren’t perfect (many of them violate one or more of our other rules!), and they aren’t enough, but they exist. The range of non-trivial funding avenues for smaller projects is, well, smaller. This makes the need more acute and the impact of even a few dollars goes a lot further in terms of telling those maintainers that they are literally valued, and nudging them away from the brink of abandonment.
• It’s just simpler: In multi-maintainer projects, we require high transparency about income between the paid maintainer(s) and other co-maintainers. They need to work out amongst themselves who gets paid, how much, and who does not. In practice, it has rarely been a showstopper, but payment issues do get more complicated the larger the project. This ultimately has proved a bit of a ceiling on project size—which is fine!

Objectively widely-used projects, not subjectively well-known ones

I have lost track of the number of times CTOs have told me “but I donate to $BIGPROJECT.” This is often because a senior member of the engineering team, or perhaps even the CTO themselves was once a contributor to that project, but it’s always because the CTO simply knows the name of the project. That isn’t a bad thing, but it presents a kind of myopia. 

If you’re a CTO, your stack depends on thousands of projects—for Tidelift’s average customer, it’s over 5,000. In no other industry would it make sense to only pay 0.1% of your suppliers for their products; you would correctly assume that 99.9% of your suppliers are teetering on the edge of bankruptcy.

If you’re paying only well-known projects that are so well-known that your CTO can name them, those projects are also well-known to others. That means they have options for receiving income. It’s the ones that you don’t know about that need the attention the most—the xzs, and log4js, and leftpads of the world.

Instead of giving to the famous projects, you need to give money to the projects that are widely used. If you’re a huge company, you have some ideas from your own dependency trees, but for most people looking to give money, it is best to pool data with other groups or companies to objectively identify what is most widely used in those dependency trees. (Bonus points if you can use data on proprietary products, rather than just in open source library repositories, since the proprietary application-level dependency data will better reflect real-world usage). 

(2) Who to pay

Pay the maintainers, not strangers

First things first: it’s important to pay, as much as possible, the actual maintainers, not people who say they’ll help out. This helps on a lot of levels, among them:

• Creates less maintenance overhead, not more: If you pay someone who isn’t the maintainer to do work, congratulations, you’ve just made the maintainer’s life harder. They have to review patches, and maintain new features if the paid person walks away.
• Avoids personality clashes: Suffice to say, many of the people involved in open source have strong personalities. Lots of folks who have paid for “extra” work on open source have horror stories that boil down to “I paid a contractor to help out, but then it turned out that person clashed with the original maintainer and it was all a waste of time and money.”

If the maintainer can’t take money, listen carefully to understand why

If maintainers can’t take money, that is a very important signal. Among other things, you might learn the following things—each with different solutions:

• The maintainer won’t take money for ideological reasons: We get told all the time that “those free software people just won’t take money” but in our experience, when you’re earnestly trying to pay them it is actually very rare that they aren’t interested in getting paid. In fact, in our 2023 state of the open source maintainer report, we found that 77% of unpaid maintainers would rather get paid. In practice we’ve found that most successful FOSS maintainers are also pragmatic. They’re happy to take money to undertake additional, specific work—if they trust that your values are aligned with theirs.
• The project is currently maintained by full-time professionals whose day job is to maintain the project and can’t take extra income: If this is the case, congratulations, your money is probably better spent elsewhere! Mark it off the list and use your data to find the next most-depended-on project.
• The project is not maintained at all: If this is the case, you should be telling users how to move off it, or using a network of “adjacent” maintainers (in the same technical stack) to bring it back into maintenance mode with trusted, appropriately-skilled folks.
• The maintainer says the money isn’t enough to be bothered with: This is a pretty common problem. The ways to solve this can be diverse, but include offering more money, finding an already-existing junior co-maintainer who would like to become more involved, or complementing it with other job-like benefits, like vacation or health care. (Sadly we can’t do that last part, yet, but we’ve heard loud and clear that it would help many maintainers.)

(3) What to pay them

This is perhaps the section that is most counter-intuitive for a lot of people, especially those who like their software to be as cheap as possible. The bottom line is that the more you treat paying the maintainers for maintenance like a professional, commercial transaction, the better it is for everyone, and the cheaper it may be for you in the long run. 

Pay, don’t donate

If you treat your payments to maintainers as a donation, maintainers may be more reluctant to accept it for a few key reasons:

• It might go away at any time: We have a lot of respect for the OSPOs out there, so it is sad to observe that a lot of charity for open was a bit of a zero-interest rate phenomenon. With the industry-wide belt-tightening over the last year, open source donations (and in some cases, the entire organizations that manage them) were one of the first things to get cut exactly because it was often viewed as charity internally. Maintainers aren’t ignorant; they know this! So if you tell them you’re giving them a “gift” or a “donation,” they may be more skeptical about accepting your money.
• Your expectations are ill-bounded and potentially far-reaching: Contracts can specify “this is what we want from you in return for payment.” Gifts come with fewer formal strings attached, but often with ever-increasing informal strings. Again, maintainers are smart—they know about this sort of scope-creep, and are (correctly) skeptical of it.
• They might feel constrained on how they can spend it: if you pay maintainers for specific services performed, they know they can use that money however they want—perhaps to improve the project, perhaps to have a nice night out on the town, perhaps on mental health care. If you donate, there are often strings attached on how it can be spent—either formal ones (especially if the business is expecting specific tax implications) or informal ones (“we expected you to spend that on The Things We Approve of”). Again, this will make them more reluctant to take the money.

Paying maintainers, in contrast, is something they are all used to — and can more readily accept.

Steady incomes before one-offs

Trying to do one-time “airdrops” of money is one of the most common mistakes that would-be FOSS “sponsors” make. Most maintainers have full-time day jobs as well-paid professionals. We have found that they aren’t particularly interested in taking one-time payments to deliver specific new features or work, unless they already have steady, flexible income that gives them the time to take on new work.

In addition, one-time airdrops, no matter how critical the work is, don’t address one of the core problems of maintenance—the need for important packages to be maintained on an ongoing, long-term basis. Ongoing payments align the form of payment with a critical problem to be solved.

(4) Pay them to do what, exactly?

So if we’re paying, not donating, what do we recommend paying for? 

Pay for ongoing maintenance and gradual improvements

First things first: complementary to “don’t donate,” we’ve learned it is best to pay maintainers for the value they are delivering. The list of requirements can be pretty lightweight (our list of tasks is brief and impact-focused), but maintainers want to clearly understand what they’re delivering and to whom. This helps them feel confident that they can commit the time required to do the work before they accept payment.

Pay to adhere to specific best practices and to provide valuable information about those practices

A lot of the ongoing maintenance work needed to keep projects secure and well maintained is, bluntly, not always as much fun as writing new code. But it is important to enterprise consumers that software they use follows these practices, and documents compliance. Because this work is valuable to enterprises, but time-consuming for maintainers, it makes sense that we should pay them to do it. 

To do that, at Tidelift we’ve aligned our maintainer tasks with industry standard best practices like those found in the NIST Secure Software Development Framework (SSDF) and OpenSSF scorecards, including things like enabling two-factor authentication, creating a discoverable security policy, and providing fixed releases to address vulnerabilities. Maintainers not only complete this work as part of getting paid by Tidelift, but they agree to document these practices and continue to uphold their projects to these standards over time, which is extremely valuable to enterprise users who can use these commitments to make long-term decisions about relying on those packages.

We know this works! Last year, we ran a pilot with maintainers where we paid them to complete a specific set of tasks related to improving their OpenSSF scorecards scores. We gave them a concrete list of tasks to complete, and the paid maintainers improved their scores by 57%. Those maintainers who joined the pilot ended up with an average scorecard score of 7.2 out of 10, compared to 3.3 out of 10 for packages that were not part of the pilot. 

Don’t pay to add features or fix bugs

Paying for “feature improvements” and bug fixes have deep fundamental challenges, which is why these efforts have been attempted repeatedly in open source (starting in the late 1990s!) but rarely succeed. What are some of the key issues with paying maintainers to add features or fix bugs? 

• Features pay once but cost forever: Tobie Langel had a slide in a presentation this year that pointed out that if a maintainer is struggling to maintain N features in their project, paying them (or someone else) to spend a few months implementing a new feature means they get money for a few months—and then have to support N+1 features for the rest of time. Not unreasonably, most maintainers won’t see that as a win.
• Who does the work? Related to the previous point, if you pay anyone other than the maintainer to add a new feature, or do a bug fix, that payment creates work for the maintainer—both immediately and into the long-term future.
• Verification is hard: if you pay for a new feature, unless it is scoped very clearly to a simple, objective third-party standard (like “raise your OpenSSF Scorecard score”), you will spend nearly as much time and money validating whether the feature was done “correctly” as you did implementing the feature in the first place. (One co-founder of an early OSS bounty platform told me they eventually found that their costs for feature bounties were 40% implementation, 60% validation and upstreaming.)

Don’t pay for control

We explicitly tell maintainers that our customers don’t want to control their projects. Conveniently, this is true! One of the virtues of trying to pay “middle of the stack” projects is that the main interest of our customers is that the projects continue to stay healthy, giving them a fighting chance of meeting enterprise requirements in the long term. “Big” projects require strategic control. If that’s what you want, forming a 501(c)6 is a much better model—but has too much overhead for most small projects.

(5) You have to want to do it.

Ultimately, as with many things, HOWTO pay maintainers comes down to wanting to do it. If you enter the field with a preconception that maintainers don’t want to get paid, or that most maintainers shouldn’t be paid, or that maintainers only merit payment when they agree with your corporate priorities, then it should be no surprise that you find it hard going.

If on the other hand you find that maintainers generate literally trillions of dollars of value, and you think it’s important to society—and to the very for-profit software industry!—that this be something that works in the long run, we promise—you too can pay the maintainers.

Dispelling a few myths

Don’t people do this work for the love of open source?

In our experience, open source maintainers often start projects for non-monetary reasons, like the classic “scratching an itch,” or because their bosses tell them to. 

But after starting projects for various reasons, they often maintain projects out of a sense of obligation—at least until the burden becomes too much and they burn out or quit. To put it another way: no maintainers started their project because of the love of ensuring it complies with your company’s definition of enterprise secure software development practices for no pay for the rest of their lives. 

If your company needs the level of secure practices (2fa, fixing vulnerabilities) that you require of the code written by your in-house development team, you are leaving the realm of “software downloaded for free from the Internet” and entering the realm of “economic transaction offering value for income in return.” 

Doesn’t money end friendships, destroy motivation, and generally kill puppies?

Not really. I love charity and do a lot of it, but the day when open source was primarily an ideological, charitable effort is past—and critically, maintainers know that. Maintainers do still have many noble motives, like pride and craft. But they also know it’s part of the very lucrative software economy—and if you pretend it’s somehow untainted by money, they know you’re either naive or trying to exploit them.

Final thoughts

We’ve learned a lot about how to pay maintainers successfully over the past few years. Our specific approach involves paying maintainers to implement industry-leading secure software development practices, validate the practices they follow, and contractually commit to continuing these practices into the future so that organizations can confidently make long-term investments in the packages they use.

We’d be happy to tell you more about it, and have stories we can share with you of the benefits customers have received from paying maintainers through Tidelift. 

We’re also not the only ones successfully giving money directly to open source maintainers, and other examples you might want to explore include the Digital Infrastructure Insights Fund, the Open Technology Fund, and others.   

But if you take away only one thing from this HOWTO, please make it that “paying maintainers does work, you just have to do it right.” At Tidelift, we continue to learn, we hope you will too (and will share your experiences for others’ benefit). 

Because it’s simply too risky to not pay maintainers for the incredible value they create.