In January 2022, Marak Squires — the maintainer of colors.js and faker.js — deliberately sabotaged his own packages. He pushed updates that broke applications depending on them, inserting infinite loops and gibberish output. His stated reason: he was tired of Fortune 500 companies profiting from his unpaid labor.
The incident was widely condemned. It was also widely misunderstood. The conversation focused on whether a maintainer has the "right" to sabotage their own package. The real question — why critical infrastructure is maintained by people who can't pay rent from their contributions — was largely avoided.
Open source software underpins virtually all modern software. Linux, OpenSSL, curl, zlib, SQLite — these aren't niche projects. They're the foundations that banks, hospitals, militaries, and trillion-dollar companies build on. And many of them are maintained by individuals or tiny teams with minimal or no funding.
The security implications of this funding gap are direct and measurable.
The Funding Gap Is a Security Gap
Underfunded open source projects suffer from predictable security failures:
Delayed Vulnerability Response
When a CVE is reported against a project maintained by a single volunteer, the response time depends on that person's availability. If they're on vacation, sick, or simply burned out, the patch waits. Meanwhile, the vulnerability is public and being exploited.
The OpenSSL Heartbleed vulnerability (CVE-2014-0160) was arguably the most significant security event in open source history. At the time, OpenSSL — used by two-thirds of all web servers — had one full-time maintainer and an annual budget of approximately $2,000. The project securing the internet's encryption couldn't fund a single full-time developer.
Insufficient Code Review
Security-critical code changes require careful review. In well-funded projects, multiple experienced reviewers examine changes before they're merged. In underfunded projects, the maintainer reviews their own code (or doesn't review at all) and merges it.
The xz Utils backdoor discovered in 2024 (though the attack began years earlier) exploited exactly this pattern. The attacker contributed to an underfunded project, gained maintainer trust over years of helpful contributions, and eventually introduced a sophisticated backdoor. With more reviewers and resources, the unusual changes might have been caught earlier.
No Security Audit Budget
Professional security audits cost $50,000 to $500,000 depending on project size and audit depth. Most open source projects will never have that budget. They rely on the community and programs like the OpenSSF's audit initiatives, but coverage is limited.
A 2022 census of critical open source projects identified hundreds of widely-used libraries that had never received a professional security audit. These are the same libraries embedded in enterprise software, government systems, and critical infrastructure.
Maintainer Burnout Enables Social Engineering
Overworked maintainers are more susceptible to social engineering. When someone shows up offering to help with the overwhelming workload — fixing bugs, triaging issues, improving documentation — the burned-out maintainer is inclined to grant permissions. The attacker patiently builds trust over months before exploiting that access.
This attack pattern has been documented repeatedly. The event-stream compromise, the ua-parser-js hijacking, and the xz Utils backdoor all involved attackers who offered help to overwhelmed maintainers.
Current Funding Models
Several funding models exist, each with significant limitations:
Corporate Sponsorship
Companies like Google, Microsoft, and Meta sponsor open source through programs like Google's Open Source Security Team and Microsoft's FOSS Fund. These programs provide meaningful funding to selected projects but cover a fraction of the ecosystem.
The challenge: corporate sponsorship tends to focus on projects the sponsoring company directly uses. Libraries that are critical to the ecosystem but not directly used by sponsors receive less attention.
Foundation Support
The Linux Foundation, Apache Software Foundation, and OpenSSF provide organizational and financial support to projects under their umbrella. The OpenSSF specifically focuses on security for critical open source.
The Alpha-Omega Project (a joint initiative of the OpenSSF, Google, and Microsoft) targets the most critical open source projects for security improvements. It's a step in the right direction, but the scale of the problem dwarfs the available funding.
GitHub Sponsors and Open Collective
Platforms like GitHub Sponsors and Open Collective enable individual and corporate donations to maintainers. These platforms have lowered the friction of contributing financially, but the median funding level for most maintainers is negligible — often less than a few hundred dollars per month.
A 2022 analysis found that most GitHub-Sponsored developers received less than $1,000 per year. For projects that companies depend on for millions in revenue, this is insulting rather than insufficient.
Tidelift and Commercial Licensing
Tidelift offers a model where companies pay for commercial maintenance guarantees on open source packages. Maintainers who participate receive income in exchange for commitments around security response, maintenance, and licensing clarity.
Dual licensing (open source for community use, paid license for commercial use) works for some projects but is difficult to enforce and creates ecosystem friction.
Government Funding
The EU's Next Generation Internet initiative has funded open source security work. The German Sovereign Tech Fund has provided grants to critical open source projects. The US government has focused more on regulation (EO 14028, CISA guidance) than direct funding, though DARPA and NSF fund some open source security research.
Government funding has the advantage of not being tied to corporate interests, but it's often slow to allocate and comes with bureaucratic overhead that doesn't suit the pace of open source development.
What Actually Needs Funding
Security funding for open source should target specific activities, not just general maintenance:
Security Audits
Every widely-used library should receive a professional security audit at least once. Critical libraries (used in over 10,000 projects or handling security-sensitive operations) should be audited regularly.
The OpenSSF's Alpha-Omega project and organizations like OSTIF are working on this, but the backlog is enormous. Funding more audits is one of the highest-return security investments the industry can make.
Maintainer Compensation
Paying maintainers isn't charity — it's infrastructure investment. A maintained project with a funded maintainer responds to vulnerabilities faster, reviews changes more carefully, and is less susceptible to social engineering takeover.
The compensation doesn't need to be Silicon Valley salaries. For many maintainers worldwide, even a modest stipend ($2,000-5,000/month) would make open source maintenance sustainable as a primary activity.
Security Tooling Integration
Many open source projects don't use basic security tools — fuzzing, SAST, dependency scanning — because setting them up takes time the maintainer doesn't have. Funding dedicated effort to integrate security tooling into critical projects closes this gap.
Google's OSS-Fuzz has been enormously effective, finding thousands of vulnerabilities in open source projects through continuous fuzzing. Expanding similar programs to cover more projects and more tool categories (not just fuzzing) would have outsized impact.
Succession Planning and Bus Factor
Projects with a bus factor of one — where a single person's departure would effectively kill the project — are systemic risks. Funding programs that help projects recruit, train, and retain additional maintainers reduce this risk.
The concept sounds simple. The execution is hard. Trust in open source is earned through years of contributions, and you can't hire trust. But you can fund mentorship programs, contributor onboarding, and documentation that reduces the barrier to entry for new maintainers.
The Industry's Responsibility
Companies that build commercial products on open source have an economic interest in the security and sustainability of their dependencies. Some are acting on this. Most are not.
A 2022 survey found that 70% of companies using open source contributed nothing back — no code, no funding, no bug reports. These companies treat open source as free raw material while expecting enterprise-grade security and maintenance.
The argument for contribution isn't altruistic. It's economic:
- The average cost of a data breach in 2022 was $4.35 million (IBM)
- A security audit of a critical dependency costs $50,000-200,000
- Sponsoring a maintainer costs $24,000-60,000/year
- The cost of remediating a supply chain attack is orders of magnitude higher than prevention
Companies that refuse to fund the open source they depend on are making a bet that someone else will handle the security. Sometimes that bet pays off. When it doesn't — Log4Shell, Heartbleed, xz Utils — the costs are catastrophic.
What Organizations Can Do Now
-
Inventory your open source dependencies. You can't fund what you can't see. Generate SBOMs, identify critical path dependencies, and assess the maintenance health of each.
-
Fund your critical dependencies directly. Identify the five most critical open source projects in your stack and sponsor them. Even small amounts matter — they signal that the work is valued.
-
Contribute engineering time. If you can't contribute money, contribute code reviews, security improvements, bug fixes, and documentation to the projects you depend on.
-
Adopt projects at risk. When a critical dependency shows signs of maintainer burnout or abandonment, invest in its continued maintenance rather than hoping someone else will.
-
Support ecosystem-level initiatives. Contribute to the OpenSSF, participate in Alpha-Omega, fund security audit programs. These initiatives benefit the entire ecosystem, including your dependencies.
How Safeguard.sh Helps
Safeguard provides the visibility that makes strategic open source investment possible. The platform's SBOM generation and dependency analysis identify which open source components are most critical to your organization — the ones where a maintainer walking away or a security incident would directly impact your products. Safeguard's health metrics for open source dependencies surface projects with low maintainer activity, no security audit history, and high bus-factor risk, letting you prioritize where your funding and contribution efforts will have the greatest impact. By connecting dependency risk to business impact, Safeguard helps security and engineering leaders make the case for open source investment to executive stakeholders who control the budget.