Nobody Pays for Open Source Software — Can We Force Them To?

The Age-Old Problem of Open Source Funding

Open source software (FOSS) underpins much of the modern internet's infrastructure — from OS kernels to programming language runtimes, to countless libraries and frameworks that large companies use for free. Yet an uncomfortable reality persists: almost no one voluntarily pays for any of it. An article circulating in the developer community titled Nobody pays for FOSS, we can force them to cuts right to the heart of this problem — if voluntary donations don't work, is there some mechanism that could compel commercial beneficiaries to pay?

The piece earned 171 points and 165 comments on Hacker News, signaling that it struck a nerve among a large number of practitioners. This isn't a new problem, but it resurfaces periodically in new forms, reflecting a structural tension in the open source ecosystem between commercialization and long-term sustainability.

Why the Voluntary Payment Model Fails

The core characteristic of open source software is freedom of use — which also means there's no natural "gate" for collecting payment. A company worth hundreds of billions of dollars can embed a library maintained by an individual developer in their spare time into a core product at zero cost, and that maintainer often receives not even a word of thanks, let alone any financial compensation.

This "free-rider" phenomenon is a textbook public goods problem in economics. When something can be copied infinitely and cannot be made exclusive, rational individuals and companies tend to benefit without contributing. The result is burned-out maintainers, stalled projects, and — as the industry has learned the hard way — security incidents caused by critical infrastructure going unmaintained.

Donation platforms like GitHub Sponsors and Open Collective provide a channel, but the funds they actually raise are negligible compared to the economic value open source creates. The author's central argument is precisely this: since asking doesn't work, discussing forcing becomes an unavoidable option.

What "Forcing Payment" Actually Means

"Forcing" here isn't about dismantling the open source ethos — it's about exploring mechanisms that make large-scale commercial beneficiaries bear proportionate responsibility. This points to a few possible directions:

Via License Constraints

Some "source-available but commercially restricted" licenses that have emerged in recent years — such as SSPL and BSL — represent exactly this kind of attempt. They allow free use but impose restrictions or payment requirements on those who commercialize the software as a service. The controversy is whether these licenses still count as "true open source," and the community is sharply divided.

SSPL (Server Side Public License) was introduced by MongoDB in 2018. Its core clause requires that if you offer the protected software as a service, you must also open-source the entire service stack — including management, monitoring, automation, and surrounding infrastructure code. This is devastating for cloud providers: if AWS or GCP wanted to host a MongoDB-compatible service, they would have to open-source large portions of their proprietary cloud infrastructure, making commercial hosting essentially unprofitable. BSL (Business Source License), designed by MariaDB, allows free use within a defined time window (typically four years), but commercial use beyond a specified scale or scope requires a paid license; once the window expires, the code automatically converts to a traditional open source license like GPL. The fundamental controversy with both licenses is that the OSI has declined to certify them as "open source licenses," because they impose restrictions on specific commercial uses — violating the Open Source Definition's (OSD) principle that licenses must not discriminate against fields of endeavor. Supporters call them "source-available licenses"; critics argue they're a form of "open-washing" — exploiting the open source brand while effectively remaining closed.

Via Industry Norms or Legislation

A more radical proposal involves regulatory force. Since companies profit by relying on open source infrastructure, could some mechanism — akin to a "digital infrastructure tax" — require commercial entities above a certain scale to contribute funding to the critical open source projects they use? EU legislation like the Cyber Resilience Act (CRA) has begun to address corporate responsibility for open source components, though the motivation is security rather than funding.

The EU Cyber Resilience Act (CRA), formally passed in 2024, requires products with digital elements sold in the EU market to meet mandatory cybersecurity obligations, including vulnerability disclosure, security updates, and compliance documentation. The original draft sparked fierce backlash from the open source community, with the central concern being that if open source maintainers were classified as "commercial operators," they would face compliance costs they simply couldn't afford — ultimately pushing many to abandon or take down their projects. After intensive lobbying by the community, the final version granted exemptions to open source developers operating for non-commercial purposes. Yet this also exposed a paradox: the law attempted to tie "responsibility" to "degree of commercialization," but in reality, much critical infrastructure is maintained by non-commercial individual contributors — people who lack both the shelter of a commercial entity and the resources for compliance. The CRA's legislative process offers a valuable case study for future "digital infrastructure responsibility" debates.

Via Collective Bargaining

Another path is for maintainers to organize collectively, building negotiating leverage against large-scale users — transforming scattered, easily-ignored individual requests into collective demands that are hard to dismiss.

The Community's Divided Response

The discussion on Hacker News showed a clear split. Supporters argue that open source maintainers have been exploited for too long, and any mechanism that improves their income is worth exploring. Critics worry that "forcing" would undermine the very foundations of open source — once mandatory payment is introduced, open source is no longer open source, but slides toward some form of restricted commercial software.

A significant number of pragmatic voices pointed out that the real issue isn't whether forcing is possible, but how it would be enforced. Who defines which projects deserve payment? How are payment standards set? How do you harmonize laws across national borders? These implementation-level challenges are often thornier than the ideological debates.

Notably, some commenters suggested that rather than trying to charge all users, the focus should be on identifying and engaging the enterprises that actually have both the ability and willingness to pay — treating free users as the top of the funnel and enterprise support as the monetization exit. This is the path already validated by many successful open source companies, most famously the Red Hat model.

The Red Hat model is the most frequently cited success story in open source commercialization. The core logic: don't charge for the software itself — charge for enterprise-grade services, including long-term support (LTS), security patches, compliance certification, and professional consulting. Red Hat Enterprise Linux (RHEL) shares a large amount of code with free distributions like CentOS and Fedora, but RHEL targets enterprise customers with hard requirements around stability and legal accountability, at premium subscription prices. IBM's $34 billion acquisition of Red Hat in 2019 validated the commercial worth of this approach. That said, the Red Hat model has real limitations: it depends heavily on the software having sufficiently complex enterprise deployment scenarios. It works well for operating systems, databases, and middleware — categories with significant operational overhead. For single-purpose utility libraries or frameworks (like a small npm package such as left-pad), it's nearly impossible to replicate. This is why discussions about open source sustainability need to distinguish between "platform-level projects" and "component-level projects" — the commercialization paths available to each are fundamentally different.

There's No Silver Bullet for Sustainable Open Source

The value of this debate isn't in arriving at a definitive answer, but in forcing the community to confront a reality it has long avoided: a model of open source that relies purely on altruism and voluntary donations is fragile when faced with massive commercial beneficiaries.

"Forcing" may be a provocative framing, but what it points to is a more fundamental question — how do we maintain openness while building sustainable mechanisms that allow value creators to be rewarded? Whether the ultimate answer involves license innovation, legislative intervention, or business model reinvention, the open source ecosystem needs to find a new equilibrium between idealism and economic reality. No single discussion will solve this. But every debate like this one moves the industry forward.