How Can Governments Pay Open Source Maintainers?

When I worked for the UK Government I was once asked if we could find a way to pay for all the Open Source Software we were using. It is a surprisingly hard problem and I want to talk about some of the issues we faced.

The UK Government publishes a lot of Open Source code - nearly everything developed in-house by the state is available under an OSI Approved licence. The UK is generally pretty relaxed about people, companies, and states re-using its code. There's no desire and little capability to monetise what has been developed with public money so it becomes public code.

What about the Open Source that UK Government uses?

The state uses big projects like WordPress, as well as moderately popular NPM packages, and small Python libraries and everything in between. But can it pay the maintainers of that software?

Fixing The Plumbing

Open Source is facing a crisis. The code that the world relies on is often developed by underpaid engineers on the brink of burn-out. While I don't think anyone wants Open Source to have a paywall, it seems obvious that large organisation should pay their way and not rely solely on volunteer labour.

Here are some of the problems I faced when trying to get the UK Government to pay for OSS and how you as a maintainer can help make it easier for large organisations to pay you.

Firstly, lots of OSS doesn't have a well defined owner; so who gets the money?

I'm not saying that every little library you create needs to be published by a registered company, nor am I suggesting that you should remove your anonymity. But Governments and other organisations need to know who they are funding and where the money is going. The danger of accidentally funnelling money to a sanctioned state or person is just too big a risk for most organisations.

If you want to receive funding - make it really clear who you are.

What Can You Offer?

Even when there is an owner, there often isn't an easy mechanism for paying people. Donation sites like GitHub Sponsors, Ko-Fi, and Patreon are great for individuals who want to throw a small amount of money to creators but they can be problematic for larger organisations. Many OSS projects get around this by offering support contracts. It makes it much easier for an organisation to justify their spend because they're no longer donating to something which can be obtained for free; they're paying for a service.

This doesn't have to be a contract offering a 24/7 response and guaranteed SLA. It can be as simple as offering best-effort email support.

The important thing is to offer an easy way for a larger organisation to buy your services. Many organisations have corporate credit cards for lower-cost discretionary spending which doesn't require a full business-case. How easily could a manager buy a £500 support contact from your site?

Maintainers don't only have to offer support contracts. Many choose to offer training packages which are a good way to raise money and get more people using your product. Some project maintainers will speak at your conference for a suitable fee.

Again, the aim here is for maintainers to offer a plausible reason for a payment to be made.

Playing Well With Others

Open Source has a brilliant culture of allowing multiple (often anonymous) contributors. That's fine when there's no money involved, but how does a moderately sized project decide who receives what share of the funding? Services like OpenCollective can make it easier to show where the money is going but it is better to discuss in advance with all contributors what they expect as a share.

If people think they're being taken advantage of, or that a project maintainer is unjustly enriching themselves, it can cause arguments. Be very clear to contributors what the funding is for and whether they're entitled to any of it.

Finally, we faced the issue that some OSS projects didn't want to take money from the "big bad state". They were worried that if people saw "Sponsored by the Government" they would assume that there were backdoors for spies, or that the developer might give in to pressure to add unwanted features. This (usually) isn't the case but it is easy to see why having a single large organisation as the main donor could give the impression of impropriety.

The best defence against this is to have lot of paying sponsors! Having the state as one of many partners makes it clear that a project isn't beholden to any one customer.

It isn't impossible to get Governments to spend on Open Source. But state spending is heavily scrutinised and, bluntly, they aren't set up to pay ad hoc amounts to non-suppliers, who aren't charging money. While large projects often have the resources to apply for Government grants and contracts, smaller projects rarely have the time or expertise. It is critical that maintainers remove the barriers which make it too hard for organisations to pay them.

In Summary

• Make it easy for Governments and other large organisations to pay you.

• Be as obvious as possible that you are able to accept payments from them.

• Don't be afraid to put a large price on your talents.

• Offer multiple paid-for options like speaker fees, support, and feature development funding.

• Talk with your contributors to let them know how any funding will be shared.

\ \