Not All Code Is Created Equal: The Uncomfortable Truth About Which Open Source Projects Actually Survive

There's a story open source culture loves to tell about itself. The best code rises. The most useful tools get adopted. Developers vote with their pull requests, and the cream floats to the top. It's a clean, democratic narrative—and it's mostly fiction.

The reality is messier and, frankly, a lot less fair. Whether an open source project survives long-term has less to do with technical quality and a whole lot more to do with who's funding it, which company decides to adopt it, and whether the people building it have the financial cushion to keep going when the work stops being exciting and starts being exhausting.

That's not a cynical take. It's just what the data—and a lot of lived experience—keeps showing us.

The Quiet Lottery of Corporate Adoption

Let's start with the most obvious variable: corporate backing. When a major tech company—Google, Meta, Microsoft, Amazon—decides to throw its weight behind an open source project, that project doesn't just get resources. It gets legitimacy. It gets engineers whose salaries are already covered. It gets conference talks, blog posts, and a built-in user base of developers who work at companies that trust that brand.

React didn't survive because it was objectively the best JavaScript UI framework in 2013. It survived because Facebook built it, used it in production at massive scale, and had the marketing reach to make it feel inevitable. Vue.js, which many developers argue is more approachable and equally capable, spent years scrapping for donations through Patreon while its creator, Evan You, essentially ran a one-man sustainability experiment in public.

Vue made it—but barely, and not without serious financial stress along the way. Plenty of technically comparable projects didn't.

The question nobody likes to ask out loud: what did we lose when those other projects died?

Who Gets to Keep Building

Here's where the equity problem gets really sharp. Open source contribution has never been demographically representative of the broader developer community, let alone the broader public. Studies have consistently found that the overwhelming majority of open source contributors are white men in wealthy countries with stable employment—people who can afford to donate nights and weekends to unpaid work because their day jobs already cover the bills.

That's not a moral failing of those contributors. It's a structural problem. When your survival model depends on volunteer labor, you naturally get contributions from people who can afford to volunteer.

The downstream consequence is brutal: the problems that get solved in open source are disproportionately the problems faced by people who already have resources. Developer tooling for well-funded startups? Robust. Infrastructure for enterprise cloud deployments? Excellent. Lightweight tools designed for low-bandwidth environments in rural America or accessible software for users with disabilities? Chronically underfunded, often abandoned, frequently built by a single exhausted maintainer who eventually burns out and disappears.

This isn't abstract. Think about the accessibility tooling ecosystem. Or localization libraries for languages that aren't English, Spanish, or Mandarin. Or offline-first applications designed for communities without reliable internet. These projects exist. They matter enormously to real people. And they die at a rate that their technically shinier cousins simply don't.

Case Studies in Survival (and Its Absence)

Consider the diverging fates of two projects that launched around the same time with similar ambitions.

Kubernetes, Google's container orchestration system, was open-sourced in 2014. Within two years, it had a dedicated foundation (the CNCF), multi-million dollar corporate sponsors, and hundreds of paid engineers contributing to it. Today it's effectively the backbone of modern cloud infrastructure.

Around the same period, a small team built an open source platform designed to help community health clinics in underserved US neighborhoods manage patient data without expensive proprietary software. The code was solid. The need was real. The team was passionate. But there was no Fortune 500 company whose core business depended on it thriving. Grant funding ran dry. The maintainers took jobs that paid actual salaries. The project is still technically on GitHub, last updated four years ago.

Same era. Similar technical quality. Radically different outcomes—because one project sat at the intersection of corporate infrastructure needs and venture-backed startup culture, and the other one didn't.

The Foundation Problem

Open source foundations were supposed to help solve this. The Apache Software Foundation, the Linux Foundation, the Eclipse Foundation—these organizations exist in part to provide neutral governance and financial stability for projects that matter.

And they do help. But they also have their own gravitational pulls. Foundation membership costs money. The projects that get elevated to foundation status tend to be the ones that already have significant corporate interest. It's a bit like a mutual aid network that only helps people who are already doing okay.

There are exceptions. NumFOCUS has done meaningful work supporting scientific computing projects that don't have obvious corporate sponsors. The Sovereign Tech Fund in Germany has started paying maintainers directly for work on critical infrastructure. In the US, some philanthropic organizations have started treating open source sustainability as a digital public goods problem rather than a market problem—which is the right frame, even if the funding is still modest.

But these efforts are drops in a very large bucket.

What Meritocracy Actually Requires

If we actually want open source to function like the meritocracy it claims to be, we have to be honest about what that requires. Merit can't win if it can't survive. A brilliant project maintained by a single developer in their spare time while working two jobs will always lose to a mediocre project with three full-time engineers behind it—not because the code is better, but because one team can answer issues at 2 p.m. on a Tuesday and the other one can't.

Real meritocracy requires leveling the conditions under which merit can be expressed. That means funded maintainers. It means active outreach to bring in contributors from communities that have historically been excluded from open source culture. It means foundations and funders actively asking: whose problems aren't being solved here, and why?

It also means the broader tech community—companies especially—taking seriously their dependence on open source infrastructure that they didn't build and aren't paying for. The free rider problem in open source isn't just about money. It's about who gets to decide which projects are worth sustaining.

The Stakes Are Real

This isn't just an internal debate for developers. The tools that survive in open source shape what gets built on top of them. If the projects that make it are disproportionately the ones solving problems for well-resourced people in well-connected places, then the technology layer underneath our digital lives is quietly optimized for some people and not others.

That's a collective problem. And solving it is going to take more than hoping the best code wins.

Because right now, it often doesn't.