Imagine this: you’re working for a large, complex organisation – say, the UK Government – and someone asks a seemingly straightforward question. “We use so much Open Source software. Can we pay for it?” On the surface, it sounds like a noble, even obvious, idea. After all, the state relies on everything from behemoths like WordPress to tiny, indispensable Python libraries. But when you dive into the practicalities, you quickly discover that it’s a surprisingly hard problem to solve.
My own experience within the UK Government highlighted just how thorny this issue can be. We were committed to publishing our own in-house developed code under OSI-approved licenses, embracing the spirit of public code funded by public money. There was no desire, nor really the capability, to monetise what we put out. But turning that ethos around – paying for the Open Source we consumed – proved to be a completely different beast.
The global digital infrastructure is, in many ways, built upon the silent, often uncompensated, efforts of Open Source maintainers. These are the unsung heroes whose dedication keeps the cogs turning for everything from individual websites to vast corporate systems and, yes, national governments. Yet, many of these crucial developers are underpaid, teetering on the brink of burnout. While no one advocates for turning Open Source into a paywalled service, it’s clear that large organisations, especially those benefiting immensely, should contribute their fair share, rather than solely relying on volunteer labour.
The Invisible Owners: Who Gets the Check?
One of the first, and most fundamental, hurdles we encountered was simply identifying who, exactly, to pay. Many Open Source projects, especially smaller libraries or modules, don’t have a clearly defined legal entity or even a single, readily identifiable owner. They might be the passion project of an individual developer, or a collaborative effort with multiple contributors, some of whom prefer anonymity.
Now, I’m certainly not suggesting that every small utility you create needs to be published by a registered company, or that you should strip away your anonymity if you value it. However, for governments and other heavily regulated organisations, knowing who you’re funding is paramount. The risk of inadvertently funneling public money to a sanctioned individual or entity is simply too great to ignore. Financial transparency and accountability are non-negotiable.
If you’re an Open Source maintainer and you genuinely wish to receive financial support from larger organisations, making your identity clear is a critical first step. This doesn’t mean revealing your home address, but providing a legitimate business name, a registered foundation, or even just a verifiable personal identity that an organisation can officially interact with. This simple act removes a significant barrier for those who want to support your work.
Beyond the Tip Jar: Offering Value, Not Just Accepting Donations
Even when a project has a clear owner, there often isn’t an easy or appropriate mechanism for payment. Donation sites like GitHub Sponsors, Ko-fi, or Patreon are fantastic for individual patrons who want to throw a few dollars to creators. But for a large government department or a multinational corporation, these platforms can be problematic. The internal procurement systems of such entities aren’t designed for discretionary “donations” to what can technically be obtained for free.
This is where Open Source projects can, and should, pivot. Instead of merely asking for donations, many successful projects offer services. This shift is crucial because it transforms a “donation” into a “purchase,” which is something large organisations are perfectly set up to do. They’re no longer just giving money away; they’re paying for a tangible service, which makes the spend far easier to justify internally.
Making it Easier to Pay
What kind of services, you ask? It doesn’t have to be a round-the-clock, platinum-tier support contract with guaranteed SLAs, though that’s certainly an option for larger projects. It can be as straightforward as offering “best-effort” email support for a fixed annual fee. Or perhaps a bespoke training package for their developers to get up to speed on your library. Some project maintainers also offer their expertise as speakers at conferences or internal workshops, charging a suitable professional fee.
The key here is offering a plausible reason for a payment to be made, and then making the payment process itself incredibly easy. Many organisations empower their managers with corporate credit cards for lower-cost, discretionary spending that doesn’t require a full, arduous business case approval. Could a manager easily navigate your site and purchase a £500 support contract within minutes? If not, you’re inadvertently putting up walls. Clear pricing, a simple checkout process, and a professional invoice go a long way.
Sharing the Bounty and Earning Trust
Open Source thrives on a brilliant culture of collaboration, often involving multiple, sometimes anonymous, contributors. This distributed model works beautifully when money isn’t explicitly involved. But when funding comes into play, a moderately sized project needs a clear, pre-defined mechanism for deciding who receives what share of the funding. Without this, disagreements can quickly arise, leading to resentment and even project forks.
Services like OpenCollective can help by providing a transparent financial ledger for projects, showing where money comes from and where it goes. However, even with such tools, it’s imperative to have candid discussions with all significant contributors in advance about what they expect as a share of any potential funding. If contributors perceive that a project maintainer is unjustly enriching themselves, it can corrode trust and fragment the community. Be transparent about what funding is for, and whether contributors are entitled to a slice of it.
Finally, there’s the perception issue. Some Open Source projects, perhaps surprisingly, have expressed reluctance to accept money from the “big bad state.” They worry that a “Sponsored by the Government” tag might lead users to suspect backdoors for spies, or that the developers might be pressured to add unwanted features. While such fears are usually unfounded, it’s easy to see how having a single, large organisation as the primary donor could create an impression of impropriety or undue influence.
The most effective defence against this perception is to cultivate a diverse funding base. When the government is just one of many paying sponsors – alongside various companies, foundations, and individuals – it clearly signals that the project isn’t beholden to any single customer. This broad support reinforces the project’s independence and open nature, making it a more attractive and trustworthy partner for all.
Paving the Way Forward
It’s certainly not impossible to get governments, or any large organisation, to spend money on Open Source. But state spending is subject to intense scrutiny, and frankly, their systems aren’t designed to make ad hoc payments to non-suppliers who aren’t charging for a service. While massive Open Source projects might have the resources to apply for government grants and navigate complex procurement processes, smaller, equally vital projects rarely have that luxury of time or expertise.
The onus, therefore, falls partly on maintainers to remove the practical barriers that make it too difficult for these organisations to pay them. Be as obvious as possible that you are able to accept payments. Don’t be afraid to put a fair price on your talent and the value you provide. Offer multiple, clear, paid-for options – be it support, training, speaking fees, or even feature development funding. And crucially, maintain transparency and clear communication with your contributors about how any funding will be shared. By doing so, we can bridge the gap between crucial Open Source contributions and the sustainable funding they desperately need.
