Every time an open source maintainer quits, the software industry pays a license fee—not in cash, but in risk, rework, and rushed migrations. The fee is invisible on any balance sheet, yet it compounds with each departure. The core problem is structural: open source licenses grant perpetual rights to use code but impose no obligation to sustain it. When a maintainer walks away, downstream consumers—from startups to Fortune 500 firms—absorb the cost. This article argues that the industry's free ride is ending, and that license reform, not charity, is the only durable fix.

The Unpaid Tax of Maintainer Burnout

Open source foundations run on goodwill. The Linux Foundation, the Apache Software Foundation, and the Eclipse Foundation rely on a mix of corporate sponsorship and volunteer labor. But the maintainers who actually triage issues, review pull requests, and ship releases are often unpaid individuals. According to a 2023 survey by the Tidelift company, roughly 50% of maintainers report feeling burned out. The proportion is higher among those maintaining security-critical libraries: OpenSSL, Log4j, and Curl each have fewer than a handful of active maintainers.

Each departure strands downstream users. When a maintainer stops responding, the project enters what the community calls "zombie" status. It compiles, it runs, but no one is fixing bugs or patching vulnerabilities. The US Cybersecurity and Infrastructure Security Agency (CISA) maintains a list of known exploited vulnerabilities; a disproportionate share targets libraries with a single maintainer. The cost of a zero-day exploit in an unmaintained project can run into millions of dollars for a large enterprise.

No contract enforces continued maintenance. The Apache 2.0 license, used by the majority of commercial open source projects, grants a perpetual, worldwide, royalty-free license to use the code. It says nothing about the maintainer's duty to keep working. The MIT license is even more permissive. When a maintainer quits, the community is free to fork the code—but forking requires active community, build infrastructure, and documentation. Many forks die within months.

License terms ignore sustainment costs entirely. The Open Source Initiative (OSI) approved licenses focus on copyright and distribution, not on the ongoing labor of maintenance. A license is a legal document, not a service contract. The industry has conflated "free as in speech" with "free as in labor."

How Corporate Users Extract Value Without Paying

Venture-funded startups consume free dependencies from day one. A typical SaaS company uses hundreds of npm packages, PyPI libraries, and Maven artifacts. Many of these are maintained by a single person in their spare time. The startup may raise millions in funding, yet its open source bill is zero. The asymmetry is stark: the maintainer bears the cost of development, the startup captures the upside.

Fortune 500 firms embed unmaintained libraries deep in their supply chains. A 2024 analysis by Sonatype found that 96% of Java projects depend on at least one library with a known vulnerability, and many of those libraries are no longer maintained. The cost of upgrading a critical dependency in a large enterprise can exceed $100,000 in engineering time. That cost is a hidden tax paid by the consumer, not the maintainer.

Few contribute code or funding back. GitHub's 2023 Octoverse report estimated that less than 1% of corporate users contribute any code upstream. The Pixel 8a ships with a DSP radio stack that depends on open source components; the maintainer of one of those components quit in 2022, and Google had to assign engineers to maintain their own fork. That is the hidden fee.

The Red Hat model—pay for support, not for the license—shows one path, but it only works for infrastructure that is already bundled. For the millions of libraries that never get a support contract, the model fails.

The license as liability shield, not revenue source. Companies use open source licenses to avoid warranty claims. The Apache 2.0 license includes a disclaimer of liability. If a bug causes a crash, the user has no recourse. The license protects the maintainer, but it also protects the corporate user from having to pay.

The License as a Subscription Trap

Some projects have attempted to turn the license into a de facto subscription. The GNU Affero General Public License (AGPL) requires that users who modify the code and run it as a network service must release their modifications. This is often used to force compliance—or to encourage a commercial license purchase. MongoDB, Elastic, and Confluent have all used AGPL or similar terms to create a walled garden.

Source-available licenses like the Business Source License (BSL) and Server Side Public License (SSPL) function as pseudo-subscriptions. HashiCorp moved its products to BSL in 2023, citing concerns that cloud providers were reselling its software without contributing. The move triggered forks: the OpenTofu project forked Terraform, and others followed. The community split, and users now pay via legal risk—they must either purchase a commercial license or accept the risk of non-compliance.

License change triggers forks, community splits, and uncertainty. When a project changes its license, downstream users must decide whether to migrate, pay, or fork. Each option has a cost. The maintainer's departure or license change is a form of taxation on the user's time and attention.

User pays via legal risk, not direct fee. The cost is opaque. A startup using BSL-licensed software may not even know it is non-compliant until a sales call from the vendor. The license becomes a trap: the user cannot easily leave, and the maintainer has no incentive to keep the project healthy.

When a Maintainer Quits, the License Stays Silent

Apache 2.0 and MIT grant perpetual rights. They do not require the maintainer to fix bugs, respond to issues, or even keep the repository online. If the maintainer walks away, the code is still usable—but only as a snapshot. No updates, no security patches, no community support.

No clause for continued development. Some licenses, like the Common Development and Distribution License (CDDL), include provisions for contributors to grant patent licenses, but none require ongoing maintenance. The legal framework treats software as a static artifact, not a living service.

Forking requires active community, often fails. The leftpad incident of 2016 demonstrated the fragility of the npm ecosystem. A single developer unpublished a small package, breaking thousands of projects. The package was restored, but the incident revealed that no license could force the maintainer to keep the package available. The community responded with packages that mirror dependencies, but the underlying fragility remains.

Single point of failure in critical projects. The Curl project, used by billions of devices, has one primary maintainer. The OpenSSL project had a core team of fewer than five people for years. When Heartbleed was discovered, the industry realized how thinly staffed these projects were. The maintainer of a package for six years wrote about learning contract law the hard way, discovering that no license protected his time.

Market Mechanisms That Could Fix the Gap

The Open Source Pledge, launched by a group of companies including Sentry and Algolia, asks organizations to pay at least $2,000 per developer per year to the open source projects they depend on. It is a voluntary commitment, not a license. As of 2025, fewer than 100 companies had signed, but the idea is gaining traction.

Tidelift offers a subscription for curated, guaranteed-updated packages. Companies pay a monthly fee, and Tidelift passes a portion to maintainers. The model works for popular libraries, but it does not cover the long tail of niche packages. The service mesh overhead that bills per sidecar is another example of metering usage, but it applies to infrastructure, not libraries.

GitHub Sponsors and Open Collective provide micro-funding. They allow individuals and companies to donate directly to maintainers. The amounts are often small—a few hundred dollars a month—but for a maintainer in a low-cost-of-living country, that can be significant. However, the majority of maintainers receive nothing.

The Sovereign Tech Fund, backed by the German government, pays maintainers directly to work on critical infrastructure. It is a promising model, but it is limited to a few projects and does not scale to the entire ecosystem.

License + contract bundles: pay for updates. A few projects, like Sidekiq and Faker, have dual licenses: a free version with an older license and a paid version with updates. This creates a clear incentive: if you want the latest version, you pay. It is a form of subscription, but it is transparent.

A Real License for Sustained Maintenance

Fair-code licenses with a time-limited free tier could align incentives. The Fair Code model, used by projects like GitLab, allows free use for small teams but requires payment above a certain revenue threshold. The time-limited tier could be extended to maintenance: free for the first year, then a subscription for updates.

Revenue-based royalty for commercial use. A license that charges a small percentage of revenue for commercial use—say 0.1%—would fund maintenance without burdening individual developers. The Open Core model does this for companies like GitLab and Mattermost, but it is not standardized.

Maintainer cooperative ownership model. A cooperative of maintainers could collectively license their code, with revenue distributed based on contribution. The Open Source Collective is a step in this direction, but it currently acts as a fiscal host, not a licensing body.

Blockchain-based escrow for continuity funds might sound far-fetched, but smart contracts could automate payments to maintainers based on usage metrics. A project could require users to stake tokens, which are released to maintainers if they meet update milestones. The complexity and gas costs make it impractical today, but the idea points toward automated funding.

Regulatory mandate for critical infrastructure. The EU's Cyber Resilience Act already imposes security requirements on software vendors. Extending that to require funding for maintained dependencies is a logical next step. Critics argue regulation is blunt, but the alternative is continued fragility.

What the Industry Must Accept

No more free lunch for multi-billion firms. The era of unpaid maintainers sustaining billion-dollar companies is ending. The maintainers are burning out, and the next generation is less willing to work for free. The industry must internalize the cost of maintenance.

Maintainers are not volunteers forever. Many maintainers are early-career developers who build a reputation and then move to paid roles. Others simply tire of the work. The assumption that someone will always step up is naive.

License reform is a business negotiation. The current licenses were designed for a world where software was a hobby. Today, open source is a critical part of the economy. Licenses should reflect that. The tension between freedom and sustainability is real, but it is not insoluble.

Self-interest aligns with collective funding. Companies that fund open source reduce their own risk. The SwiftUI library debacle showed how a single review decision can cascade into bans for multiple libraries. Funding maintainers is a hedge against such disruptions.

The alternative is a brittle digital commons. If nothing changes, the number of unmaintained projects will grow, security incidents will increase, and the cost of software development will rise. The industry will pay the fee one way or another—either now, through sustainable funding, or later, through incident response and migration.

Trade-offs and Counter-Arguments: Why License Reform Is Hard

Critics argue that imposing maintenance obligations on licenses would violate the very definition of open source. The Open Source Initiative's Ten Commandments require that licenses not restrict the use of software by any field of endeavor. A license that demands payment for updates could be seen as discriminatory against commercial users, potentially falling outside the OSI definition. This is a genuine tension: any attempt to encode sustainment into a license risks reclassifying the software as non-open-source, fragmenting the ecosystem.

Another objection is that maintainers themselves may not want the responsibility. Many open source developers contribute for passion, not profit. Binding them to a legal commitment to maintain could deter participation altogether. A maintainer who wants to walk away after a few years should be free to do so without legal penalty. The current license structure allows that freedom; a reform could create an unintended barrier to entry.

There is also the practical challenge of enforcement. How would a license police whether a maintainer is meeting update milestones? Would a user have standing to sue if a security patch is delayed? The legal costs would dwarf any potential recovery. Even with blockchain-based escrow, the overhead of measuring contribution and verifying compliance is non-trivial. These are real obstacles that any reform must address.

Some in the industry argue that the market is already correcting itself. The rise of cloud-based managed services—like AWS's managed OpenSearch or MongoDB Atlas—means that companies pay for uptime and features, not for the license itself. In this view, the hidden tax is just a transition cost to a world where open source is primarily consumed as a service. But this model only works for infrastructure that can be easily hosted; it does not help the maintainer of a niche Python library that no cloud provider bundles.

Finally, there is the risk that license reform could lead to a two-tier system: well-funded projects thrive with paid maintenance, while hobbyist projects wither. The digital commons would become a gated community. This outcome might be better than the current fragility, but it is not the egalitarian vision that early open source advocates championed. The industry must weigh these trade-offs carefully.

Real-World Case Studies: When the Model Worked and When It Didn't

The Core Infrastructure Initiative (CII), now part of the Linux Foundation, provides a counterexample. After Heartbleed, major tech companies funded the CII to audit and improve critical libraries like OpenSSL. The project hired full-time developers, and the number of vulnerabilities dropped significantly. The model worked because the funding was collective and the target was small. But the CII covers only a handful of projects; for every OpenSSL, there are thousands of smaller libraries that never get attention.

On the failure side, consider the case of the npm package 'event-stream'. In 2018, a maintainer handed over control to a malicious actor who injected cryptocurrency-stealing code into the package. The package had millions of downloads, but the maintainer was burned out and saw no way to sustain the project. The incident exposed that even popular packages can be abandoned or compromised when maintainers lack resources. The license was silent; the community was left to clean up the mess.

Another instructive example is the 'should.js' library for Node.js. The maintainer walked away in 2020 after years of unpaid work. The library was used by thousands of projects, but no one stepped up to fork it. Eventually, users migrated to alternatives, incurring migration costs. The hidden tax was paid in engineering hours, not dollars, but the cost was real.

On the success side, the 'Babel' project transitioned to a foundation model with dedicated staff funded by corporate sponsors. Babel's maintainers are now paid, and the project releases updates regularly. The key was that Babel was recognized as infrastructure by companies like Facebook (now Meta) and others. But Babel's centrality is rare; most projects do not have that kind of clout.

These examples illustrate that the market can work when the incentives align, but the alignment is accidental rather than structural. Until the license itself encodes a duty to maintain, the industry will continue to rely on goodwill and luck.