Funding the Commons: How Open Infrastructure Projects Are Learning to Survive Without Selling Out

Somewhere in the United States right now, a developer is merging pull requests at midnight. They are responding to bug reports filed by organizations whose annual revenues exceed their own salary by several orders of magnitude. They are doing this, in many cases, for free — or close enough to it that the distinction barely matters.

This is not an anomaly. It is the structural condition of open infrastructure, and it has been quietly draining talent from the commons for decades.

The financial sustainability crisis facing open-source projects is not a new problem, but it has grown more urgent as the stakes have risen. Libraries, platforms, and protocols that once served small developer communities now underpin hospitals, universities, federal research systems, and Fortune 500 companies. The dependency graph has expanded far beyond what most maintainers anticipated when they first published their code. The compensation structures, however, have not kept pace.

The Burnout Equation

Maintainer burnout is frequently discussed in technical circles as though it were a personal failing — a matter of individual resilience or time management. That framing misdiagnoses the problem. What maintainers typically describe is not exhaustion from doing work they love. It is exhaustion from doing invisible administrative labor: triaging issues, mediating community conflicts, writing documentation, and managing the expectations of users who treat open-source tools as commercial products with implied service-level agreements.

The psychological toll compounds when maintainers recognize that their project has become critical infrastructure for paying customers elsewhere in the stack — and that those customers have no formal obligation to contribute anything in return. The asymmetry is not incidental. It is, in many cases, a deliberate feature of how large technology organizations consume open-source value.

Several maintainers who have spoken publicly about stepping back from prominent projects have cited not a lack of passion for the technical work, but a loss of faith that the broader ecosystem would ever treat sustainability as a shared responsibility. That loss of faith is a signal worth taking seriously.

What Hasn't Worked

The first generation of responses to this crisis was largely inadequate. Donation buttons, while symbolically meaningful, rarely generate enough revenue to justify the overhead of processing them. Volunteer contribution drives produce sporadic engagement but seldom translate into consistent, high-quality maintenance work. Requests for corporate sponsors frequently go unanswered, or receive one-time gifts that disappear when organizational priorities shift.

Open-core models — releasing a free community edition while charging for enterprise features — have worked well for some companies, but they carry a significant tension for projects whose identity is rooted in genuine openness. When the feature set that actually matters to serious users sits behind a paywall, the community edition risks becoming a marketing vehicle rather than a mission-driven product. That perception, once it takes hold, is difficult to reverse.

Perhaps most instructively, projects that have depended on a single corporate patron have discovered the fragility of that arrangement. When the patron's priorities shift, when a company is acquired, or when internal budget pressures arrive, the project loses its financial foundation with little warning and no fallback.

Emerging Models Worth Watching

The more promising approaches share a common characteristic: they distribute financial responsibility across a broader base of stakeholders rather than concentrating it in a single relationship.

Foundation models, when structured thoughtfully, offer one path forward. Organizations like the Apache Software Foundation and the Linux Foundation have demonstrated that neutral governance bodies can aggregate funding from multiple corporate contributors without ceding control to any single donor. The challenge is that foundation overhead can be substantial, and smaller projects may find the administrative requirements disproportionate to their scale. Newer, leaner foundation structures are attempting to address this, offering fiscal sponsorship arrangements that provide legal and financial infrastructure without demanding full organizational transformation.

Tiered service models represent another viable approach — one that preserves the openness of the core project while generating revenue from the operational layer. A platform that is free to use and self-host can still charge for managed hosting, priority support, or compliance documentation. This model works best when the tiering is honest: when the free tier is genuinely useful, and when paying customers are funding the commons rather than simply unlocking features that were artificially withheld.

Grant funding from foundations, government agencies, and research institutions has also grown more available in recent years, particularly for infrastructure projects that serve public interest use cases. The National Science Foundation, several private technology foundations, and an increasing number of university research programs have recognized that sustaining open infrastructure is a legitimate research and public interest concern. These grants rarely cover full operational costs, but they can provide crucial runway during early development or transition periods.

The Social Contract Underneath the Code

What unites the most successful sustainability experiments is an explicit renegotiation of the social contract between maintainers and the communities they serve. Rather than assuming that open-source contributions are gifts with no expectation of reciprocity, these projects articulate clearly what maintainers provide, what users and organizations receive, and what obligations flow in both directions.

This articulation requires a kind of honesty that the open-source community has historically been reluctant to embrace. Maintainers must be willing to say, plainly, that their time has value and that the project cannot continue without resources. Users and organizations must be willing to hear that message and act on it — not because they are legally required to, but because they understand that the infrastructure they depend on does not sustain itself.

For builders working within platforms like Condor, this conversation is not abstract. Every tool, library, and protocol that powers community-driven research and development exists because someone made a decision to build it in the open. Preserving that ecosystem requires treating sustainability not as someone else's problem, but as a shared condition of the commons we all inhabit.

The maintainer working at midnight deserves better than gratitude. They deserve a model that works.