Sixty per cent of open source maintainers work unpaid. Their code runs in 97 per cent of commercial applications. And 44 per cent of them have quit or considered quitting, not because the work is not important, but because nobody is paying them for it.
That gap, between what the digital economy depends on and what it actually resources, is a business continuity exposure hiding in every dependency manifest, and it is one you cannot afford to ignore. It has crossed three thresholds that moved it from a developer-community problem into something boards and general counsel can no longer delegate to engineering: the xz-utils near-miss, the insurance underwriting pivot, and the EU Cyber Resilience Act.
Each of those thresholds absorbed the previous one into something larger and harder to dismiss, reshaping the broader open source security landscape that now demands institutional-scale responses.
Why are unpaid open source maintainers considered a systemic security risk?
Unpaid open source maintainers are a systemic security risk because 60 per cent work without compensation while their code runs in 97 per cent of commercial applications. Burnout is causing maintainers to quit, leaving critical dependencies unpatched and creating single points of failure with no structural funding mechanism to close the gap.
The numbers get worse the longer you examine them. Sixty per cent of maintainers work unpaid, unchanged from the year before. Forty-four per cent cite burnout as the reason for leaving. And 61 per cent of unpaid maintainers maintain their projects alone: no co-maintainers, no support team, one person responsible for code running in millions of production environments.
Meanwhile your codebase keeps growing. Sonatype observed an 18 per cent decline in actively maintained open source projects even as AI adoption drives open source vulnerabilities to 581 per codebase. The workforce is shrinking while the surface area it needs to cover is expanding.
The gap between criticality and resourcing reflects a structural design flaw in how open source labour is valued, one that no amount of ad-hoc funding alone can close. Paid maintainers are 55 per cent more likely to implement critical security practices, resolve vulnerabilities 45 per cent faster, and have 50 per cent fewer vulnerabilities overall. The security dividend of paying maintainers is measurable. Yet only 4,200 companies out of roughly 300 million using open source participate in GitHub Sponsors.
The OpenSSF has described the situation as critical digital infrastructure operating under a “dangerously fragile premise”, maintained in ways that rely on goodwill rather than mechanisms that align responsibility with usage. That fragility is not hypothetical. Kubernetes retired Ingress NGINX in November 2025 because maintainers working nights and weekends could not sustain it. The External Secrets Operator froze all updates in the same month: four maintainers burned out, leaving one active contributor, despite having corporate sponsorships. As the remaining maintainers put it, “money doesn’t write code, review pull requests, or manage releases”.
The Linux Foundation’s January 2026 post-Linus continuity plan signals that even the most-established projects now face governance fragility. And the maintainer community itself is greying: maintainers aged 46 to 65 have doubled as a share since 2021, while those under 26 have collapsed from 25 per cent to 10 per cent.
Some governments are responding. Germany’s Sovereign Tech Fund provides fellowships of €64,000 to €82,000 per year for maintainers, community managers, and technical writers. It is public-sector recognition that market mechanisms alone have failed to resource open source infrastructure.
For your team, the practical question is where to direct limited security investment. EPSS-driven prioritisation offers a defensible answer. Unlike CVSS, which measures theoretical severity, the Exploit Prediction Scoring System scores dependencies by the probability they will actually be exploited in the next 30 days. When you cannot invest in every dependency, EPSS gives you a methodology for focusing resources where exploitation is most likely. IBM’s Project Lightwell, a $5 billion enterprise clearinghouse for open source security, represents the institutional-scale response to this structural gap.
Enterprise clearinghouse model vs. community-upstream funding: which approach better serves maintainers?
Lightwell centralises security engineering at enterprise scale: 20,000-plus engineers, AI-powered vulnerability triage and remediation, and assurance delivered to consuming organisations as a commercial service. Tidelift pays maintainers directly for adopting and documenting security practices, linking compensation to enterprise adoption. Both models address the crisis, but through different theories of change, and neither yet achieves the coverage the problem demands.
IBM’s Project Lightwell commits $5 billion and more than 20,000 engineers to an AI-powered clearinghouse. Enterprises report vulnerabilities, IBM and Red Hat engineers use AI to validate and develop patches, fixes are backported to exact dependency versions already tested and deployed, and patches flow both to enterprises and upstream to the community. Lightwell does not pay upstream developers. It provides IBM and Red Hat engineers with AI tools to work on business-critical open source projects and make them as secure as possible. The model is centralised, enterprise-funded, and engineered for scale.
Tidelift takes the opposite approach. Maintainers receive income proportional to the number of enterprise subscribers using their projects, creating a market mechanism that links security behaviour to compensation. The theory is that paying maintainers directly for security practices changes the incentives that created the crisis. But Tidelift depends on voluntary corporate participation, and adoption remains small.
Between these two poles sits the OpenSSF’s Alpha-Omega programme. In 2025 it invested $5.8 million across 14 critical projects, completed over 60 security audits, and fixed 52 vulnerabilities. It is targeted but cannot cover the long tail of dependencies. The OpenSSF’s $12.5 million coalition, announced in March 2026 with funding from Anthropic, Google, Microsoft, AWS, and others, signals institutional recognition without yet achieving critical mass.
The trade-offs are clear. Lightwell delivers enterprise-grade assurance at scale but centralises control. Tidelift directs money to maintainers but depends on adoption rates that remain disappointing. Alpha-Omega targets the most critical projects but leaves thousands of dependencies untouched. The Open Source Pledge, pioneered by Sentry at a minimum of $2,000 per year per developer, complements Tidelift’s approach by establishing a floor for corporate contributions. But like the models it sits alongside, it remains voluntary.
None of these models alone resolves the tension between scale and directness — the competing visions for securing open source rest on fundamentally different assumptions about where leverage lies. And the problem has already escaped the domain where funding models alone can address it.
Why is the software supply chain now considered a board-level resilience problem?
The xz-utils backdoor demonstrated that a single burned-out maintainer can become the attack vector for a widespread compromise. Boards now treat supply chain security as a resilience question, involving recovery time, breach probability, and regulatory liability, rather than a technical scanning exercise. Insurance underwriting changes and regulatory frameworks have made dependency governance a fiduciary obligation.
The xz-utils backdoor was a failure mode the open source community had warned about for years, following the predictable pattern of a burned-out maintainer becoming the target of a patient social-engineering campaign. In June 2022, the original xz maintainer confessed to burnout: “I haven’t lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues”. Malicious actors then spent approximately two years building trust as a co-maintainer, using fake accounts to pressure the maintainer about bugs before offering “help”. They gained commit access and embedded an encrypted backdoor into the widely used XZ compression library. It was discovered only because a Microsoft engineer noticed a 500-millisecond SSH login latency spike, days before the backdoor would have been merged into major Linux distributions.
That single incident changed boardroom conversations. The question shifted from “should we scan our dependencies?” to “how resilient is your business to a compromise originating in code maintained by one burned-out volunteer?” The conversation now centres on business continuity: recovery timelines, breach probability, regulatory liability.
The financial stakes are material. Munich Re forecasts software supply chain attacks will cost businesses $138 billion by 2031, up from $60 billion in 2025. Marsh reports that 70 per cent of organisations experienced at least one material third-party cyber incident in the past year, and managing third-party and supply chain cyber risks is now “an integral part of overall cyber resilience strategies”.
Insurance underwriting is tightening in response. Insurers are shifting from trust-based questionnaires toward systems that demand telemetry and documentation of what environments look like. They may start writing exclusions for companies that do not declare their use of specific risky vendors or components with proven exposure to supply chain threats. Three forces are converging: catastrophic near-misses like xz-utils, regulatory pressure from frameworks like the EU Cyber Resilience Act and CMMC 2.0, and insurance requirements. Together they make supply chain resilience a fiduciary question that boards can no longer delegate. And among these regulatory pressures, none has reshaped the landscape as comprehensively as the EU Cyber Resilience Act.
What role did the EU Cyber Resilience Act play in reshaping open source security expectations?
The EU Cyber Resilience Act imposes security obligations on products with digital elements sold in the EU, capturing software that consumes open source dependencies. It reclassifies open source stewardship from voluntary best practice to regulatory obligation, demanding ongoing evidence of security practices throughout the product lifecycle rather than one-time attestations. This makes dependency governance a compliance function, not a charitable activity.
The CRA entered into force on 11 December 2024 and becomes mandatory from 11 December 2027. It requires products with digital elements sold in the EU market to meet cybersecurity obligations throughout their lifecycle, from design to end-of-life. Penalties reach €15 million or 2.5 per cent of global annual revenue for non-compliance. The Act demands SBOMs, vulnerability handling processes, secure-by-design engineering practices, and post-market surveillance.
The regulatory shift reclassifies open source stewardship. Enterprises consuming open source are meeting regulatory obligations with potential liability for non-compliance, not engaging in charitable best practice. The CRA creates what the industry has termed a regulatory system of evidence: continuous documentation of dependency governance, vulnerability management, and remediation timelines. Technical documentation must be retained for 10 years.
This creates an unresolved tension. Volunteer-maintained open source projects are generally exempt from direct CRA obligations. But once open source is integrated into a commercial product, your organisation inherits duties for vulnerability handling, updates, and documentation. When a volunteer-maintained project goes unpatched because the maintainer has quit, the compliance burden and legal risk fall on you, not the maintainer. The obligation exists, but the resourcing model to meet it does not.
The EU is not alone in tightening supply chain requirements. Executive Order 14028 in the US creates parallel pressure, mandating SBOMs for software sold to federal agencies. CMMC 2.0 extends supply chain security requirements into the defence industrial base. But SBOMs, while necessary, are static artefacts. They do not satisfy the CRA’s demand for ongoing evidence of security practices. That is why the emerging discipline of agentic governance, continuous, automated evidence generation across your software supply chain, is becoming an operational necessity rather than a theoretical ideal.
The open source maintainer crisis became a boardroom emergency through three converging forces: a backdoor that came within days of global deployment and exposed the fragility of volunteer-maintained infrastructure, insurers beginning to price that risk into policies, and regulators passing laws that make dependency governance a legal obligation.
The maintainer burnout, the fragmented funding responses, the xz-utils shock, and the CRA mandate are thresholds the same crisis crossed in sequence, each one revealing the problem to be larger than the last assumed. The question has moved from whether open source maintainers should be paid to whether your organisation can demonstrate, with continuous, auditable evidence, that every dependency in your supply chain is secure, and that the people maintaining those dependencies are not about to walk away. For the strategic overview connecting these threads, see IBM’s Project Lightwell and the Future of Enterprise Open Source Security.
Next: how AI is competing with armies of engineers to secure open source.
Frequently Asked Questions
Is AI making the open source maintainer crisis better or worse?
AI is making it worse on both sides. AI-powered tools are discovering vulnerabilities faster than ever, flooding maintainers with more security reports they do not have time to triage. At the same time, maintainer burnout is accelerating. AI is widening the gap between what gets found and what gets fixed, without anyone funding the people who do the fixing.
What happens if a critical open source dependency is abandoned?
An abandoned critical dependency becomes an unpatched attack surface in every system that depends on it. If no fork emerges and no organisation steps in, consuming organisations face a hard choice: continue running unpatched code and accept the risk, or rip out and replace the component at significant cost. Kubernetes Ingress NGINX was retired in November 2025 precisely because maintainers could not sustain the workload.
How do I identify which dependencies are maintained by unpaid volunteers?
You can assess maintainer sustainability through several signals: the project’s funding model on platforms like Open Collective or GitHub Sponsors, the number of active committers and their commit frequency, whether the project participates in programmes like Tidelift or Alpha-Omega, and the responsiveness to security disclosures. SBOMs with provenance data can surface some of this information, but manual assessment of maintainer health is still often required for critical dependencies.
Are there alternatives to running critical infrastructure on volunteer-maintained open source?
For most organisations, no. Ninety-seven per cent of commercial codebases already contain open source components, and replacing them with proprietary alternatives is often impractical in cost, time, and compatibility. The realistic path is not to replace open source but to invest in its sustainability, either through direct maintainer funding via Tidelift, through institutional programmes like Lightwell, or through consortium efforts like the OpenSSF’s $12.5 million coalition.
Didn’t we already solve this after the Log4j incident?
No. Log4j in December 2021 triggered a flurry of scanning and SBOM adoption, but it did not address the structural problem: the people maintaining critical dependencies are still largely unpaid and burning out. SBOMs tell you what you depend on but do not keep that software maintained. The xz-utils backdoor in 2024 demonstrated that the fundamental vulnerability, a burned-out maintainer with sole commit access, had not been addressed at all.
How do I explain this to my board so they take it seriously?
Frame it as a business resilience question, not a technical one. Critical infrastructure maintained by volunteers who are quitting is a predictable failure mode. One compromised dependency, as xz-utils nearly demonstrated, could bring systems down without warning. Insurers are beginning to ask about dependency governance, and regulators now require evidence of supply chain security. This is a fiduciary question about business resilience.
Does the EU Cyber Resilience Act punish open source maintainers?
No, at least not intentionally. The CRA’s obligations fall on the organisations that sell products with digital elements in the EU market, not on volunteer maintainers. However, the Act creates a practical tension: consuming enterprises must demonstrate ongoing security evidence for dependencies they use. When a volunteer-maintained project goes unpatched, the compliance burden and legal risk fall on the consuming organisation, not the maintainer.
What is the difference between EPSS and CVSS for prioritising dependency risk?
CVSS scores measure a vulnerability’s theoretical severity. EPSS scores measure the probability that a vulnerability will actually be exploited in the wild. For enterprise resource allocation, EPSS is often more useful: it tells you where to direct limited security investment toward the vulnerabilities attackers are most likely to target, rather than spreading effort across every high-severity CVE regardless of realistic threat.
Is the open source maintainer crisis just hype created by security vendors?
No. The data comes from independent sources including the Tidelift survey, which found 60 per cent of maintainers work unpaid and 44 per cent have quit or considered quitting due to burnout. The OpenSSF, a cross-industry foundation, has described the situation as “morally repugnant shortsightedness.” Real projects like Kubernetes Ingress NGINX are being retired because maintainers cannot sustain the workload. These are observed facts, not marketing claims.
How much should my company contribute to open source to be safe?
There is no fixed figure that buys safety, but there are concrete starting points. The Open Source Pledge, pioneered by Sentry, establishes a minimum of $2,000 per year per developer. Beyond financial contributions, companies should inventory their critical dependencies, assess which have the weakest maintainer health, and direct resources there through Tidelift subscriptions, Alpha-Omega contributions, or direct sponsorship.
