When OSS Becomes Public Infrastructure, Who Owns the Direction?

The GitHub blog's 2026 open source outlook identifies a significant shift: governments and institutional bodies are increasingly funding critical open source infrastructure, treating it as essential public digital infrastructure — comparable to utilities like water or energy.

The sustainability argument is clear. Many foundational projects have been maintained by underfunded individuals for years. Financial precarity creates single points of failure. An unmaintained dependency in a widely-used project is a public risk. Government funding, framed this way, is a rational response.

It also changes what open source is, in ways that aren't discussed alongside the funding announcements.

The independence that made OSS useful

Open source software has produced some of the most useful software ever built partly because it was built outside of political and commercial constraints. The people writing it were motivated by technical interest, personal utility, or ideological commitment to software freedom. They made decisions based on what made the software better.

This is not how government-funded projects work. Government-funded projects work within procurement cycles, reporting requirements, stakeholder approval processes, and political contexts that change with administrations. The funding comes with accountability structures. Accountability structures require justification. Justification requires legibility to non-technical decision-makers.

None of that is wrong in itself. But it changes the software.

What gets funded and what doesn't

Public funding of digital infrastructure isn't politically neutral. Decisions about which projects constitute "critical infrastructure" are made by people with limited technical visibility and significant political context. A dependency that underlies half the internet's TLS implementations is critical infrastructure in an engineering sense. Whether it becomes critical infrastructure in the policy sense depends on whether the right people made the case at the right time to the right committees.

This introduces selection effects. Projects with visible institutional backers, established governance documentation, and advocates who can navigate procurement processes will receive funding. Projects maintained by a solo developer in a timezone with limited institutional representation may not, regardless of technical importance.

The indie developer in this scenario — building or maintaining a project used by thousands of developers because it solves a real problem well — doesn't fit the procurement template. Their project may be equally critical. Their ability to receive public funding is substantially lower.

The governance requirement

Government funding typically requires governance structures that demonstrate accountability: boards, steering committees, documented decision-making processes, audits. For projects currently maintained by one or two people, this is not free. It requires either creating those structures (time and energy that's not going into the software) or partnering with a foundation that provides them (losing the simplicity that made the project viable in the first place).

The result is a pressure toward institutional OSS and away from individual-maintained OSS. The projects that can absorb governance overhead get funded. The ones that can't stay on the donation model, which is broken, or disappear.

This is a subtle monoculture risk. The funded projects will share governance characteristics that have little to do with technical quality: formal structures, clear ownership chains, documentation aimed at auditors. That's not what makes software good.

The alternative models

Corporate sponsorship through GitHub Sponsors, Open Collective, and similar platforms has been growing. This model has different failure modes: it concentrates funding in projects with marketing-legible value, often skips the foundational layers (the projects that other projects depend on but that end users never see), and creates implicit dependencies on the priorities of sponsoring companies.

Neither model is clean. The question is which failure modes are preferable and for whom.

For an indie developer building tools I actually use: corporate sponsorship through platforms with low overhead is more compatible with how I work than institutional funding with governance requirements I'd need to maintain. The friction of the funding should be proportional to the complexity of the project. Government infrastructure funding has friction proportional to public accountability requirements, not to project complexity.

What gets lost

The software that runs cleanly, solves a specific problem well, and doesn't grow beyond its scope — this is often maintained by one person who decided to write it because it didn't exist. Nobody funded it. Nobody told them to build it. It exists because the problem was real and the person had the skill and autonomy to solve it.

When the framing shifts to "critical infrastructure," the implicit value judgment is that bigger, more visible, more institutionally-backed projects are what matters. The long tail of small, precise, well-maintained tools that underlie the larger projects becomes invisible in the policy discussion.

The GitHub data shows a growing gap between open source participants and maintainers with genuine ownership. Government funding doesn't close this gap — it redirects resources toward the projects that already have institutional structure, which are already the ones with the most resources.

The practical implication

I maintain code that I use. I contribute to projects where the problem is one I understand. The projects I value most are often the ones with no institutional backing — they exist because someone found a clean solution to a specific problem and chose to share it.

These projects don't benefit from being recognized as public infrastructure. They benefit from being allowed to remain what they are: focused solutions maintained by people who understand them, for the benefit of people who need them.

The infrastructure framing is not wrong for the foundational layer — OpenSSL, curl, SQLite. These are genuinely public goods with sustainability risks. But the solution calibrated for that layer is a poor fit for the rest of the open source ecosystem.

Treating all OSS as infrastructure to be funded and governed like utilities will produce utilities. That's not what most OSS is, or should be.