The Quietly Radical Reality Beneath Every Website
Stop what you’re doing. Think about the last website you visited. The one you’re on right now is almost certainly running on open source software. Not maybe. Not probably. The data is almost boring in its certainty: over 96 percent of the world’s top million web servers run Linux. That’s not some niche operating system for hobbyists. That’s the foundation of modern digital civilization, built and maintained largely by volunteers and under-resourced teams who often don’t have the budget to hire enough people to handle support tickets.
This is what happens when something works so well that it becomes invisible. Infrastructure has this quality. You notice the power grid when it fails, not when it works. Same with open source. Apache, Nginx, PostgreSQL—these tools underpin billions of dollars in enterprise revenue across every industry you can name. Healthcare systems depend on them. Financial institutions route transactions through them. Your favorite streaming service probably wouldn’t exist without them. Yet the conversation around open source oscillates wildly between hype cycles and complete indifference, rarely landing on the simple truth: this is how the internet actually works.
The Structural Problem Nobody Wants to Admit
Here’s the thing that keeps me up at night, and I’ve been doing this long enough to recognize a pattern when I see one. Open source works too well. It works so well that massive corporations have built empires on top of it without building anything back. They extract value, ship products, generate billions in market cap, and when a critical project needs funding, they contribute a rounding error from their charitable foundation while issuing press releases about their commitment to community.
The burnout is real and it’s accelerating. Maintainers of foundational projects report working twelve-hour days on code that powers systems they’ll never own. Some of them work day jobs. The psychological toll is compounded by legal exposure—more on that in a moment—and by the simple fact that gratitude doesn’t pay rent. This isn’t sustainable and everyone knows it. We hit a breaking point around 2020 when several high-profile projects essentially said “we’re done” and the industry collectively gasped before going back to normal.
The good news is that some things have actually changed. GitHub started paying maintainers through their Sponsors program, which has distributed over thirty million dollars to creators. Major tech companies began establishing formal funding programs. The Open Source Initiative continues doing foundational work on licensing and governance. These are real commitments, not theater. But they’re still treating a systemic problem with individual band-aids.
Liability Just Became Everybody’s Problem
Let me introduce you to something that’s going to reshape open source in ways most people haven’t thought through yet: the EU Cyber Resilience Act. This regulation introduces liability frameworks that could hold open source projects responsible for security issues in their software. Think about that for a second. A volunteer maintainer in Romania now faces potential legal exposure for bugs that show up in enterprise systems operated by corporations with billion-dollar security budgets.
The regulation is well-intentioned. Security debt is real. We all know projects where the security practices are held together by hope and good intentions. But the implementation creates perverse incentives. Small projects might simply disappear rather than operate under legal threat. Some maintainers might require corporate sponsorship just to have liability insurance. Others might move to jurisdictions without these regulations. This isn’t theoretical. It’s already happening.
The deeper issue is that regulations written by people who don’t understand how open source actually works tend to break it in subtle ways. A maintainer spending thirty hours a week on a critical security library isn’t running a business. They’re performing a public good. Treating them like a software vendor fundamentally misunderstands the social contract. The policy problem and the funding problem are connected. You can either pay people to maintain infrastructure or you can create legal frameworks that scare them away. Pick one.
The Language Wars Are Reshaping System Security
Something genuinely interesting is happening at the level of low-level systems programming, and it’s worth understanding because it changes what’s possible going forward. Rust is replacing C in critical infrastructure. The Linux kernel is integrating Rust modules. Amazon Web Services has built significant portions of their systems in Rust. This isn’t fashionable language adoption. It’s a recognition that certain classes of bugs—the ones that have plagued C for four decades—can be prevented at compile time rather than debugged at 3 AM when your system is on fire.
The transition is slow because it has to be. You can’t rewrite everything overnight. But the trend is clear. When you have a choice between writing safety-critical code in C and Rust, and you have two equally skilled teams, the Rust system will have fewer vulnerabilities. This matters for open source specifically because the projects that form the bedrock of infrastructure—kernel components, container runtimes, network protocols—these benefit most from that guarantee.
This also creates an interesting dynamic where open source projects become laboratories for new approaches to system design. The best ideas migrate into production. The failures are public. This transparency is how we collectively get smarter about building reliable systems. It’s messy but it works.
What Actually Needs to Happen
The internet works because thousands of talented people decided to build things and share them. That’s not going to change. But the economic model around that generosity has become strained. The path forward requires three things that are currently happening unevenly. Sustainable funding mechanisms that don’t require maintainers to become entrepreneurs or corporate employees. Legal frameworks that recognize the difference between a business selling software and a community maintaining shared infrastructure. Better governance structures within projects themselves so that burnout doesn’t destroy critical tools.
Some of this is happening. Companies are starting to treat open source contributions as legitimate business expenses rather than PR exercises. Check out GitHub Open Source to see the scale of what’s being built and maintained. The statistics are sobering in their scope. Developers globally contributed over ninety million pull requests last year. The vast majority of those people were not paid to do it.
The real question isn’t whether open source survives. It will. The question is whether we build sustainable structures around it before another round of burnout crashes a critical project that half the internet depends on. Because that will happen eventually if we don’t treat this like the infrastructure problem it is. When it does, we’ll collectively decide we care for about six months, fund some initiatives, and then drift back to complacency until the next crisis.
If you’re building systems on top of open source—which, let’s be honest, you are—spend some time thinking about what you’re extracting and what you’re contributing. It doesn’t have to be code. It could be funding. Documentation. Security audits. Evangelism. The people maintaining the tools you depend on noticed you already exist. They’re just waiting to see if you’ll notice them back.