Good Infrastructure Doesn't Ask to Be Noticed

Governments are now funding open source software as public infrastructure. The Eclipse Foundation noted that organizations and public institutions are shifting from one-time donations to long-term funding partnerships with open source maintainers. The GitHub Blog describes this as a maturation: OSS is recognized as digital public infrastructure, not just a developer hobby.

This is the correct framing. It took longer than it should have.

What infrastructure means

Infrastructure is what you depend on without thinking about it. Roads, water systems, electrical grids — these are not noticed when they work. They're noticed when they fail.

The dependency is real and constant. The awareness is conditional on failure.

Open source software has been functioning as infrastructure for decades. The Linux kernel, OpenSSL, curl, git — these are dependencies of essentially every modern system. They're maintained by small groups of people, often without institutional funding, under conditions that would be unacceptable for any other critical infrastructure.

The xz backdoor incident made this visible briefly. A single maintainer, burned out and under social pressure, was manipulated into accepting malicious contributions to a tool that underpinned SSH authentication across a significant portion of the global computing ecosystem. The backdoor was caught — narrowly, by accident.

The response should have been: this is what happens when critical infrastructure is maintained by underfunded individuals. The funding model is the vulnerability.

Instead, the initial response was mostly technical: audit your dependencies, check your build systems. Which is correct but incomplete.

Why the funding model matters

Infrastructure that runs without institutional support is infrastructure that can fail without institutional recourse.

When a road fails, the city fixes it. When OpenSSL has a critical vulnerability, the maintainers — often volunteers — fix it on whatever timeline their unpaid availability allows. The gap between criticality and support is the structural vulnerability. Not a code vulnerability. A funding one.

The shift to long-term funding partnerships is closing this gap. Organizations that depend on open source infrastructure are paying to maintain it, not just consuming it and hoping someone else pays.

This is economically rational. The alternative — every company that depends on OpenSSL reinventing their own TLS implementation — is both more expensive and less secure. Shared infrastructure is efficient. Efficient infrastructure should be funded.

The product philosophy this connects to

I built Ordia with a specific philosophy: software should work without being noticed. The best version of Ordia is the one where development teams don't have to think about it — the coordination overhead just doesn't accumulate, blocked states surface automatically, context doesn't get lost.

This is the infrastructure model applied to product design. Not "here's a new tool you should use," but "here's a layer that solves the structural problem so you don't have to think about it."

Open source infrastructure works the same way. Linux doesn't have a UI that asks you to engage with it. Git doesn't send you push notifications. They work, reliably, at the layer where the work happens, without requiring attention.

The software that asks to be noticed is usually the software that hasn't fully solved the problem it set out to solve. Good infrastructure doesn't compete for attention. It removes the need for it.

What government funding signals about maturity

The shift to government and institutional funding of OSS isn't just about sustainability. It's about recognition that the software ecosystem's foundational layer is a public good.

Public goods — by the economic definition — are non-excludable and non-rivalrous. OSS fits: anyone can use it, and one person's use doesn't reduce another's. The funding problem for public goods is well-understood: private incentives under-produce them because the benefits aren't capturable by the producer.

The history of open source is the history of public goods being produced by altruism, reputation, and occasional corporate self-interest — mechanisms that work, but produce under-investment relative to actual dependency.

Government and institutional funding is the correction. Not charity: recognition that the dependency is real, the value is real, and the infrastructure model requires institutional support to be sustainable.

The gap that remains

Funding long-term OSS development through partnerships and institutional investment solves the sustainability problem for the maintainers who are visible enough to attract institutional attention. It doesn't automatically solve it for the long tail of smaller projects that are equally critical for specific ecosystems but don't have the name recognition to attract funding.

The broader version of the model — one that would actually match the infrastructure analogy — is something proportional to dependency. Companies whose revenue depends on specific open source projects should contribute in proportion to that dependency. Not as optional good-citizenship, but as a structural condition.

That's politically harder and not where the current shift is going. The current shift is voluntary, relationship-driven, and concentrated on the most visible projects.

It's the right direction. The pace is slow relative to the risk.

The honest version of the analogy

The road analogy breaks down in one specific way: roads are built and maintained by the same institutions that mandate their existence. Open source is built by individuals and small teams, mandated by nobody, and depended on by everyone.

The funding shift acknowledges the last part. It doesn't yet fully address the first two.

What would actually match the road analogy: OSS used as critical infrastructure would be treated as critical infrastructure in how it's resourced, who maintains it, and how succession is handled when maintainers burn out or leave.

The xz incident was a near-miss. Near-misses are information. The information is: the funding model for critical OSS infrastructure does not match its criticality.

The direction is right. Good infrastructure doesn't ask to be noticed. Funding it shouldn't require a crisis to make the dependency visible.