I work on the Go team at Google, but this is my personal opinion as someone who built a career on Open Source both at and outside big companies.

In a previous essay, Professional maintainers: a wake-up call, I argued that we need Open Source maintainers to professionalize into a role that's legible to the companies that are invested in their projects. For that to work, we also need companies to understand and pay professional maintainers.

While the previous piece addressed maintainers, this one is aimed at the companies that depend on Open Source projects and wish to get a solid contractual relationship with this critical part of their supply chain, improving its sustainability.

I believe that to successfully fund an Open Source project, a company needs to:

• Pay the maintainers. Not people external to the project.
• Pay them real money. In the order of what they could make as senior engineers.
• Pay for maintenance. Not features, grants, or support.
• Keep paying them. Assess performance at contract renewal time.

Pay the maintainers

This might seem obvious, but if you already have employees and contractors you trust, the temptation to pay them to work on the project might be strong.

However, new contributors increase the maintainer's workload without improving their motivation or sustainability. I often read advice along the lines of "if you want to help a project send PRs" and I never understood it. Reviewing and iterating or pushing back on PRs is work! Often more than writing the code itself.

I know that some companies have policies against paying contractors to do what employees could do, but what you're paying the maintainer for is being the maintainer of that specific project. That's not something you can pay anyone else to be.

This also helps with not being perceived as taking over the project, which Open Source communities are quick to reject.

Pay them real money

Designing, building, managing, and growing an Open Source project demostrates all the skills required of a Senior Software Engineer. That means maintainers can access $150k–300k++/year compensation packages.^[1]

Many maintainers are not in Open Source for the money, and that's fine, but often life happens and as circumstances change they might not be able to afford to turn down a proper salary anymore.

If your goal is ensuring the ongoing maintenance of the project, you should target figures between 25% and 100% of a SWE compensation package, depending on how likely the project is to get multiple sources of funding. $1,000/month without benefits is a nice way to show appreciation, but won't achieve any other goals.

Pay for maintenance

This is the most important part, and getting this wrong sunk more than one attempt at funding the Open Source ecosystem.

Maintainers are worried that taking your money will take control away from them. They, and their communities, don't want you to impose control over technical decisions. You don't want that either! You want to pay them to keep doing what they are doing, or to dedicate more resources to it. After all, you're already using their project because they did a good job so far prioritizing and executing.

Maintainers are already busy people, so you also don't want them to spend half their time writing grant proposals detailing what they plan to do so you will fund them. Instead, fund them so that they can dedicate resources to the project, and trust them to direct those resources like you'd trust a senior engineer to execute on a broadly scoped project.

Finally, the health of the project depends on issue triage, bug fixes, refactors, and design work more than on new features. In fact, new features increase the maintenance burden. Paying for new features makes for easy to define deliverables, but sets up the wrong long-term incentives.

Other things you should pay for

That doesn't mean the contract should come with no strings attached. Half the point of paying maintainers is getting solid guarantees back. (The other half is making the ecosystem sustainable.)

Over time, you can require a set of processes and practices that bring the development of the projects you depend on up to the standard of the software you develop in house:

• security practices, like two-factor authentication and mandatory code review;
• reliable timelines for reviewing and merging or rejecting contributions;
• quality standards, including vetted and minimized dependency trees;
• careful handling of security reports and actionable vulnerability metadata;
• processes useful to downstream users, such as SLSA or release signing.

Moreover, you can ask for recognition in the project's documentation or as part of the project's updates. A "What's new in Foo 3.0" post that makes it to the Hacker News front page with the text "This work was funded by Acme Co." is an excellent recruiting lead generator.

Finally, once you have the contractual relationship, it's easy to extend it to add scoped work like specific extensions, support, or training. If you're suddenly faced with an emergency, having the contract and payment rails ready will make it easy to engage the maintainer for some extra help.

Keep paying them

For Open Source maintenance to be a sustainable profession, it needs to be a reliable source of income. You're not expected to provide the same long term commitment of a full-time employer, but structuring the payment as a one-off bonus is not going to be as effective as a renewable contract.

A way to get both marketing exposure and the information to decide on contract renewal is to request an end-of-year article detailing the work that was performed thanks to the funding.

This might feel uncomfortable if you're used to contracts with precise deliverables defined in advance, but it is similar to how performance is evaluated for senior full-time employees: after the fact, as a way to decide whether to continue the engagement.

It's time to make Open Source maintainer a sustainable profession at the foundation of the software supply chain.

If you're a company that tried or wants to try to fund Open Source projects, reach out at hi at filippo.io. I'm interested in hearing your experience, and maybe in helping make this kind of transactions an everyday reality.

If you want to follow along, you might want to follow me on Twitter.