Every modern application stack leans on thousands of open source packages, most maintained by a handful of volunteers answering GitHub issues after their day job. When those maintainers burn out, the consequences ripple through every company shipping software on top of their work. Understanding who actually funds the open source tax, and who should, has become a defining governance question for the technology industry heading into 2026.
The invisible infrastructure beneath every deploy
Most engineering teams underestimate how deep the dependency graph goes. A single Node.js service might pull in 1,500 transitive dependencies. A Python data pipeline could rest on a single maintainer in their apartment in Berlin. The Linux Foundation’s 2024 census estimated that more than 60 percent of critical open source projects have either a single active maintainer or no organizational backing at all.
This concentration is not a hypothetical risk. The 2024 xz utils backdoor, the repeated maintainer exits around log4j maintenance, and the ongoing drama around core JavaScript libraries have all demonstrated how fragile the foundation can be. When a maintainer walks away, the blast radius stretches from hobbyist blogs to Fortune 500 transaction systems.
Despite this, the funding models supporting most of this code remain ad hoc, voluntary, and dramatically under-resourced compared to the economic value extracted.
Where the money actually comes from
The honest answer to who funds the open source tax is: barely anyone, and inconsistently. The funding landscape has fragmented into several overlapping streams, none of which alone covers the maintenance gap.
- GitHub Sponsors and Open Collective: Direct tipping from individuals and a handful of sympathetic companies. Convenient, but totals often stay in the low four figures per month even for widely used projects.
- Foundations (Linux, Apache, CNCF, Rust, OpenJS): Provide legal shelter, governance frameworks, and sometimes stipends. Coverage is uneven, and foundation grants are competitive.
- Venture-backed maintainers: A small number of maintainers have secured funding through companies like Tidelift, GitHub, or bespoke sponsors. Useful, but not scalable to thousands of projects.
- Corporate open source offices: Larger firms like Google, Microsoft, and Red Hat employ maintainers directly. Critics argue this creates a soft form of corporate capture.
- Grants and fellowships: Programs from the Sloan Foundation, NLnet, and Mozilla have funded specific initiatives, but they are time-limited and project-specific.
The uncomfortable truth is that corporate consumption far outpaces corporate contribution. Studies repeatedly show that less than 5 percent of organizations contributing to open source fund the projects they depend on directly.
Why maintainer burnout is a tax on the whole ecosystem
Burnout among open source maintainers functions like an uncollected tax. The cost does not disappear when the maintainer quits; it simply shifts downstream into security debt, abandoned CVEs, rushed rewrites, and emergency hiring. Companies pay it eventually, just less transparently.
The pattern is consistent. A maintainer spends years fielding issues, reviewing pull requests, triaging bug reports, and managing community disputes, often for zero compensation. The emotional load of being the single point of failure for code used by millions is not abstract. The 2024 Tidelift maintainer survey found that more than 70 percent of respondents had experienced symptoms of burnout, and nearly a third had considered abandoning their projects entirely.
When that happens, downstream users face:
- Increased exposure to unpatched vulnerabilities
- Reduced responsiveness to breaking changes and bug reports
- Forced migration to alternatives that may be less mature
- Higher engineering costs to absorb internal maintenance work
This is, functionally, a hidden surcharge on every team using open source at scale. The only question is whether companies acknowledge it and budget for it, or whether they continue to extract value without contributing to the systems that produce it.
The accountability gap between consumers and contributors
Most organizations cannot name the top five maintainers their stack depends on, let alone whether those maintainers are funded, supported, or sustainable. Procurement and legal teams negotiate enterprise SaaS contracts for proprietary software, while open source dependencies are quietly absorbed into the build pipeline with no equivalent due diligence.
This accountability gap is structural. Open source consumption is decentralized, anonymous, and frictionless. Contribution, by contrast, requires time, expertise, social capital, and often institutional permission. As a result, the cost of maintenance falls on a small minority of contributors while the benefits are enjoyed by a vast majority of consumers.
Emerging models for sustainable funding in 2026
Several approaches are gaining traction as the industry matures. None is a silver bullet, but together they sketch a more realistic path toward sustainability.
Maintainer stipends and direct payroll
The simplest, most effective intervention: pay maintainers. Programs like GitHub Sponsors, Thanks.dev, and Polar have made direct payments easier. Several foundations now offer recurring maintainer stipends rather than one-off grants, treating core maintenance work like a public utility.
Consortium-funded critical projects
A handful of sectors have begun formalizing shared funding pools. The OpenSSF’s Alpha-Omega project funds security audits and maintainer time for critical infrastructure. Healthcare, financial services, and telecom are piloting similar consortium models where the heaviest commercial users pool resources to underwrite key dependencies.
SBOM-linked contribution requirements
Procurement frameworks are beginning to require software bills of materials, and some forward-thinking regulators are exploring contribution requirements tied to SBOM disclosures. The idea is straightforward: if you rely on a project, you should contribute proportionally to its maintenance.
Corporate open source program offices expanding scope
Mature OSPOs are shifting from passive license compliance toward active maintainer sponsorship. Google, Microsoft, Amazon, and Shopify have all expanded programs that pay engineers to maintain upstream projects rather than just consume them. This trend is likely to accelerate as the EU Cyber Resilience Act and similar regulations push companies to demonstrate supply-chain stewardship.
What engineering leaders can do without waiting for policy
Policy moves slowly. Engineering teams do not have to. Several concrete practices can reduce reliance on the unpaid volunteer economy without a major budget cycle.
- Map your dependency risk. Identify the projects in your stack with single-maintainer risk or no organizational backing. Tools like GitHub’s dependency graph, deps.dev, and libraries.io make this tractable.
- Tier your sponsorship. Allocate a modest budget, even 0.1 percent of engineering payroll, to sponsoring maintainers of critical dependencies. Treat it as infrastructure spending.
- Contribute upstream time. Encourage engineers to spend a percentage of work time on upstream maintenance. Frame it as technical debt reduction, which is what it is.
- Adopt SBOM-driven governance. Make dependency review part of architecture decisions, with explicit risk acknowledgment for unmaintained projects.
- Replace silent consumption with active stewardship. Open issues, write documentation, review pull requests. Maintenance is more than code.
The cultural shift that makes any of it work
None of these interventions matter if engineering culture still treats open source as free. The deepest change required is internalizing that every dependency carries a maintenance obligation alongside its rights. When teams understand that they are not just users of someone else’s project but participants in a shared commons, the question of who funds that commons answers itself.
This is not charity. It is risk management. Every unmaintained dependency in a production stack is a latent incident, a future CVE, a rewrite waiting to happen. The companies that treat maintainer funding as a line item in their infrastructure budget will spend less over the long run than those who treat it as someone else’s problem.
The next phase of open source economics
The conversation about open source sustainability has matured considerably. The naive expectation that goodwill alone would sustain critical infrastructure is fading, replaced by more pragmatic conversations about public goods, regulatory frameworks, and proportional contribution. Expect 2026 to bring more concrete regulatory pressure, more sophisticated funding mechanisms, and more explicit expectations placed on corporate consumers of open source.
The maintainers keeping the lights on deserve better than a tip jar and a thank-you tweet. The companies profiting from their work deserve the bill that is coming due. The only remaining question is whether the industry will structure that payment intentionally or continue absorbing it as chaotic, unplanned downtime.
The open source tax has always been real. The only choice is whether to keep pretending it is invisible.
