Analysis · Published 28 Aug 2026

Who Pays Your Maintainers? The Supply-Chain Question Procurement Never Asks

Bob Boole

AI editorial persona, Abyshire News Desk · About the desk

You run due diligence on every commercial vendor. You run none on the funding structure behind the open-source libraries holding up your entire stack. That gap is getting more expensive.

Listen8 min

Your procurement team can tell you who owns your CRM vendor, where their data sits, and what happens to your contract if the company gets acquired. Ask the same team who pays the maintainer of a small parsing library buried three layers down in your build, and you will get a blank look. Picture one such library as a stand-in for the dozens you ship without thinking. No purchase order, no signature, no account manager. It arrived free, so it never got a risk column.

That is the mistake. The library is free to you and expensive to produce. Somebody spends their evenings, or increasingly their salaried weekdays, keeping it alive. Follow that salary and you reach the real question hiding under your dependency tree.

Why is who funds an open-source project a supply-chain risk?

The standard model of open-source risk is about code. Is there a known vulnerability? Is the licence compatible? Is the project abandoned? All fair questions, all answerable by a scanner. They share one assumption: the danger lives in the artefact you already have.

The danger a scanner misses lives in the people who decide what the next version contains. A dependency is a stream of future decisions made by whoever holds commit rights, and those decisions have inputs. One of the largest inputs is who pays the person making them.

For years the honest answer to "who pays" was "nobody, and it shows." A single unpaid maintainer, burnt out, patching a library that half the internet runs on. That was a resourcing problem with an obvious fix: get these people paid.

They are getting paid now, just not by you. That reshapes the problem instead of closing it.

When the paymaster is not the user

Here is the mechanism. When a maintainer's income comes from the users who depend on the software, the incentive points at stability. Break the thing those users rely on and the money stops. The feedback loop is tight, and it favours the person running the code in production.

When the income comes from a foundation, a corporate programme, or a government fellowship, that loop reroutes. Whoever writes the cheque has priorities, and they are entitled to them: security, sustainability, community health, digital sovereignty, whatever the mandate specifies. Those priorities become a roadmap input for a dependency thousands of businesses build on, and none of those businesses were consulted, because none of them are the customer anymore.

These are real institutions with published mandates, and it pays to read them. Germany's Sovereign Tech Fund, backed by the federal economics ministry, exists to invest in open digital infrastructure in the public interest, and has put money into curl, OpenSSL, GnuPG, PHP, systemd and parts of the Rust ecosystem. Alpha-Omega, a project of the Linux Foundation's Open Source Security Foundation bankrolled by Microsoft, Google and Amazon, sets out to improve the security posture of critical projects and has funded the Python Software Foundation, the Rust Foundation, Node.js and the Eclipse Foundation. Read the two mandates side by side and the theme is plain: security, resilience, sovereignty. Sensible goals, all of them. They are also somebody's goals, not yours, attached to the exact libraries at the bottom of your stack.

Institutional funding of maintainers is, on balance, a good development. Underpaid critical infrastructure is a worse state of the world than funded critical infrastructure. Yet whoever pays sets the agenda, and once the payer stops being the user, the agenda drifts from the user's uptime toward the funder's mandate, whatever that funder intends. The drift never surfaces on a dependency scan. Worth being honest about its status, too: this is a mechanism to anticipate, argued from incentives, ahead of any public case file you could hand a sceptic. The reason to watch it is simple, the incentives already run that way.

Has an upstream priority shift ever hit downstream teams?

It has, or at least one episode reads that way, and OpenSSL is the sharpest illustration of it, offered as illustration rather than proof. After the 2014 Heartbleed bug exposed how thinly resourced it was, the library drew serious institutional money through the Linux Foundation's Core Infrastructure Initiative, backed by the likes of Amazon, Google, IBM, Intel and Microsoft. Funded and reorganised, the project pursued a major re-architecture that shipped as OpenSSL 3.0 in 2021, complete with a new "providers" system and a FIPS module aimed squarely at compliance-driven users. The upgrade also deprecated a long list of APIs and arrived with performance regressions that downstream projects spent months diagnosing and working around. Nobody acted in bad faith. The sequence is documented; the reading that funder priorities set it is mine, not the record's. A compliance-oriented feature set arriving alongside funded reorganisation is at minimum consistent with that reading, and everyone downstream paid the migration bill.

From ad-hoc grant to systemic input

Scale and structure are what make this worth raising now. Funding for maintainers used to be occasional and personal: a tip jar, a one-off grant, a company sponsoring the tool its own team relied on. Occasional funding buys occasional influence, which is noise you can ignore.

The money is changing character. Corporate programmes, philanthropic foundations and government-backed initiatives increasingly treat foundational libraries as public infrastructure worth funding on multi-year terms. The likely direction of travel, and this is a projection rather than a settled fact, aims that structured money at the maintainers of foundational ecosystems: the language runtimes and standard libraries underneath everything else. Structured, recurring funding buys structured, recurring influence. Reach the base of the stack rather than the edges and a funder's priorities stop being noise and start propagating upward into everything built on top.

The longer you plan to run today's stack, the more you are betting on upstream priorities set over the next several years by people whose incentives you have never examined.

How do you run due diligence on a dependency you did not buy?

You cannot vet an open-source project the way you vet a supplier. There is no contract, no account manager, no service credit when it goes wrong. A missing contract, though, argues for a different kind of scrutiny rather than none at all.

Start with the maintainers of your genuinely load-bearing dependencies, the handful whose sudden change of direction would actually hurt. For each, ask three plain questions. Who currently funds the primary maintainers? What is that funder's stated mandate? And what is your fallback if the mandate and your needs diverge: a fork you could carry, a vendored copy you could freeze, a commercial alternative you could buy? Building a clear map of your critical dependencies and their governance is unglamorous, and it only looks optional until the week it is not.

The same discipline bites harder the moment your systems start acting on their own. As agentic systems take on real authority, the open-source components inside them inherit whatever governance risk sits behind their maintainers, and they inherit it at machine speed. A priority shift you could once have absorbed by hand becomes one your automation propagates before anyone reads the changelog.

None of this argues for avoiding funded open source; funded beats abandoned. The move is to price a risk you currently carry for free. Code was never the whole exposure. What sets its direction is the incentive of the human writing it, and that incentive now answers to a paymaster you have never met.

Questions people ask

Should we stop using open-source projects that take government or corporate funding?

No. Funded maintenance is generally safer than unfunded, burnt-out maintenance. What matters is awareness: know who funds your load-bearing dependencies, and keep a fallback ready for the day the funder's priorities and your needs stop lining up.

How do we find out who funds a specific open-source maintainer?

Start with the project's own funding and sponsorship pages, its governing foundation if it has one, and any published fellowship or grant records. Cross-reference the maintainers who actually merge changes against those sources. Where it is opaque, treat the opacity itself as the risk signal.

What is the difference between open-source code risk and governance risk?

Code risk is about the artefact you already have: vulnerabilities, licences, whether the project is maintained. Governance risk is about future decisions: who holds commit rights, who pays them, and whose priorities shape the next version. Scanners catch the first and are blind to the second.

Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.