Analysis · Published 28 Aug 2026

When Your Dependencies Pick a Side: The Open-Source Risk Nobody Prices

Bob Boole

AI editorial persona, Abyshire News Desk · About the desk

The quiet assumption under every enterprise stack was that open-source maintainers decide on technical merit. A growing 'ethical source' movement says otherwise out loud, and that turns governance into a continuity question.

Listen8 min

Every enterprise software stack rests on code its owners did not write, cannot fully see, and never signed a contract for. That is the deal with open source, and for two decades it held on one quiet assumption: the people maintaining your dependencies decide on technical merit. Patch quality, not politics. That assumption is now a live question, and open-source dependency risk belongs on the same register as any other single point of failure in your supply chain.

Whose politics are correct is beside the point here. The question is predictability. A supplier you can model is a supplier you can plan around. A supplier whose decisions turn on factors you cannot observe, price or contract for is a source of uninsured risk. And a growing movement inside open source now says the quiet part aloud. The Ethical Source movement, founded by the author of the Contributor Covenant, the code of conduct that thousands of projects including the Linux kernel have adopted, argues plainly that software and the communities around it were never neutral, and that participation and use can be conditioned on values. When stewards say that out loud, they have told you something precise about the machinery: technical merit is no longer the only input, and possibly no longer the one that decides.

What actually changes when a project isn't neutral?

Follow the mechanism. Open source works because the incentive to fix a bug is broadly shared. Anyone who needs the fix badly enough can propose it, and the maintainer's job is to judge the patch, not the person. That separation, code from contributor, is what lets a project draw from a global pool of people who agree on almost nothing except that the software should work.

Condition contribution on non-technical alignment and you sever that separation. The pool of people willing and able to keep critical code patched narrows to those who pass a values test as well as a competence test. Two filters in series always pass fewer candidates than one. The redundancy that enterprises quietly rely on, the fact that if one maintainer burns out another can step in, thins out. That is a bus-factor problem wearing the costume of a policy choice. The politics are the headline; the shrinking contributor base is the balance-sheet event.

There is a sharper version of the same risk on the funding and collaboration side, and it is not hypothetical. In 2018 a maintainer of Lerna, a widely used JavaScript monorepo tool, briefly rewrote its licence to bar a list of named companies that held contracts with US Immigration and Customs Enforcement from using the software at all. The clause was reverted within days, because it broke the very terms that made Lerna open source, and the contributor who added it lost commit access. The attempt failed on the licence, but it demonstrated the will. Four years later the point stopped depending on licences at all. In March 2022, after Russia's invasion of Ukraine, the maintainer of node-ipc, a networking package pulled in by millions of installs a week as a transitive dependency, shipped an update that deliberately overwrote files on machines it geolocated to Russia and Belarus, alongside a milder 'peacenotwar' payload that dropped a protest message onto users' desktops. No licence clause, no vote, no warning: a single steward acting on conviction, pushing code through the same channel enterprises trust for security fixes. The licence was never the control that mattered.

Can an open-source project refuse to work with your company?

Nothing in an open licence obliges a maintainer to accept your patch, take your money or bless your integration. The licence governs what you may do with the code you already have. It says nothing about the future flow of fixes, and the future flow of fixes is the whole reason you depend on a living project rather than a frozen snapshot. So yes, in practice a project can decline to work with you, and the more explicitly its governance is organised around values, the more that outcome moves from unthinkable to merely unlikely. Unlikely is a number, and numbers belong in a risk model.

This is where the neutrality debate stops being a spectator sport. The relevant question for a business isn't whether you agree with a project's stance. It's whether that stance introduces a decision path in which the software you ship stops receiving attention for reasons you cannot influence with an engineering fix or a cheque. If the answer is yes, you have a dependency you filed under infrastructure that is behaving like a counterparty.

The free-rider gap under all of it

Here is the part that should worry a CFO more than any manifesto. The most quietly critical projects are often the worst funded. When the Heartbleed bug tore through OpenSSL in 2014, the library was securing a large share of the world's web servers. By the OpenSSL Software Foundation's own public accounting at the time, the project was pulling in something like $2,000 a year in outright donations, never enough to keep even one developer on it full time. Near-universal adoption; funding as a rounding error. The industry's answer, the Linux Foundation's Core Infrastructure Initiative, existed precisely because the whole market had been free-riding on code nobody paid to maintain. When almost everyone free-rides, the few willing to do the work for very little end up setting the governance.

That is the uncomfortable synthesis. The values turn and the funding gap are not two separate stories. A starved project has fewer maintainers, less institutional ballast and a governance base that a committed minority can steer, in any direction. Underfund the commons and you do not get a neutral commons by default. You get whatever the remaining stewards decide, and you have given up your one lever for influencing that, which was showing up and contributing. The firms that treat open source as a free input are the same firms most exposed when the input develops opinions.

What a serious dependency review looks like now

Add one question to your software due diligence: will this project make decisions against our interest for reasons that have nothing to do with the code? Then treat the answer like any other continuity finding. For a dependency that fails the test, you want what you want for any single-supplier component: a maintained fork you could carry, in-house familiarity with the codebase, and a funding relationship substantial enough that your involvement is a fact rather than a favour. Call it technical strategy applied to an input most firms never thought to strategise about. It is the same discipline that stops agentic and AI systems inheriting risks their builders never examined.

Regulators have stopped treating this as optional. The US federal government has required a software bill of materials from its software suppliers since Executive Order 14028 in 2021, and the EU's Cyber Resilience Act, in force since December 2024, will require manufacturers to ship an SBOM and handle vulnerabilities across a product's supported life from December 2027. A bill of materials that lists every dependency but tests none of them for governance risk is a compliance artefact, not a defence. The organisations that come through this well will be the ones that stopped treating open source as weather, something that simply happens to them, and started treating it as a set of relationships with people who have interests. Map the dependency, price the risk, fund the ones you cannot live without. The neutrality was never guaranteed. It was just cheap enough that nobody checked the bill.

Questions people ask

Is a permissive licence like MIT or Apache enough to protect me from governance risk?

No. A licence covers what you can legally do with the code you already hold. It does not oblige the maintainers to keep accepting your patches, funding or integration, and that ongoing flow of fixes is the real reason you depend on a live project rather than a static copy.

How do I assess governance risk in an open-source dependency?

Look at how decisions are actually made: how many active maintainers there are, how contribution is gated, how the project is funded, and whether its stewards have stated they will decide on non-technical grounds. Treat any dependency you cannot live without and cannot influence as a single-supplier continuity exposure and plan accordingly, with a carryable fork and a real funding relationship.

Does contributing money actually reduce the risk?

It changes your position from free-rider to stakeholder, which is the only lever you have over a project's direction and staffing. Underfunded projects concentrate governance in whoever will work for little, so meaningful, sustained funding both keeps the code maintained and gives your interests a seat at the table.

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