The most-used software on Earth is maintained by people who sometimes can't afford rent. Daniel's been chewing on this one — he says open source exposes a deeper tension in how modern economies reward human effort. People genuinely want to contribute useful things to the commons: code, knowledge, tools, research. But the system rewards work through ownership, scarcity, employment. So you get this strange outcome where foundational technologies create enormous value while their maintainers get almost nothing, even as companies built on top of that work become extremely profitable. He wants to know why socially valuable contribution is so disconnected from financial reward — is this just an unavoidable feature of markets, or can we design systems that better align contributing to the commons with actually making a living? And he wants us to look beyond software, to the deeper question: can societies build structures where people don't have to choose so sharply between work that advances collective human potential and work that reliably pays them?
This is one of those questions where the more you stare at it, the weirder it gets. Because the disconnect isn't a glitch. It's built into the logic of how markets work.
So let's start with the most famous example of this tension — the code that runs the internet itself, and the moment everyone suddenly noticed the problem.
Heartbleed, twenty fourteen. OpenSSL is the encryption library that secures something like a third of the web — every time you see that little padlock in your browser, there's a good chance OpenSSL is doing the work underneath. And in April twenty fourteen, researchers discovered a bug that had been sitting in the code for two years. It let attackers pull chunks of server memory — passwords, private keys, session cookies — straight out of the machine. Catastrophic.
And the team maintaining this thing?
Four people. One of them, Steve Marquess, was effectively working for a dollar a year. They had a small office in Maryland. They were fielding bug reports from companies worth hundreds of billions of dollars, and they couldn't afford to hire a second full-time developer. When Heartbleed hit, Marquess wrote this blog post that I still think about — he said, and I'm paraphrasing, "we're operating on a budget that wouldn't cover a single decent software engineer at any of the companies that depend on us."
A dollar a year. For the encryption that protects the global banking system.
And that's not even the most extreme case. The Linux Foundation did an estimate — they put the replacement value of all open-source software somewhere north of four hundred billion dollars. That's what it would cost to rewrite from scratch what's already been built and given away. Meanwhile, a survey a few years back found that something like sixty percent of maintainers have never been paid for their open-source work, and among those who have, the median is a few thousand dollars a year. It's a rounding error.
So the question is — why does this happen? Why does the market systematically undervalue the things that create the most value? Let's look at the mechanism.
The core of it is that markets price scarcity, not value. This is the thing people miss. Diamonds are expensive because they're scarce, not because they're useful. Water is cheap because it's abundant, not because it's unimportant. And open-source code, once it's written — it's a public good. Non-rivalrous and non-excludable. My use of it doesn't diminish your use of it, and you can't stop me from using it once it's out there.
So the marginal cost of the next user is zero.
No, wait, that's the word you're not supposed to use.
You can say it once.
I'm saying it. The marginal cost is zero, so the price collapses to zero. This isn't a bug in market logic. It's the logic working as designed. The market is doing exactly what it's supposed to do — driving the price toward the cost of providing one more unit. It just so happens that for digital public goods, that cost is nothing.
And that's where the absurdity lives. The thing is more valuable than almost anything else in the economy, and the price is zero.
Right, and this is not new. This is the part I think gets overlooked — people talk about open source like it's a novel problem the internet created. But the pattern of public goods being undervalued by markets predates software by centuries.
Walk me through that.
Gutenberg. The printing press is arguably the most transformative invention of the last thousand years — it enabled the Reformation, the scientific revolution, mass literacy, democracy. Gutenberg died in relative poverty. He lost his printing workshop in a lawsuit, and by the time he died in fourteen sixty-eight, he was living on a small pension from the archbishop of Mainz. The man who invented the machine that made mass communication possible couldn't monetize it effectively.
The compass, same thing. Transformed navigation, opened up global trade routes. The people who refined it didn't get royalties on every ship that crossed the Atlantic.
The scientific method itself. The entire edifice of modern science runs on the principle that you publish your findings openly, anyone can replicate them, anyone can build on them. The inventors of the core ideas — Newton, Galileo, Darwin — they didn't get a licensing fee every time someone used calculus. Darwin died comfortably because he came from money and wrote popular books, not because natural selection generated revenue.
So the pattern is: you create something foundational, it becomes infrastructure, the price goes to zero, and you hope someone gives you a pension.
And infrastructure is the right word here. Roads, bridges, the power grid — these are all things where the social value is enormous and the market price to the user is often zero or close to it. We've solved this for physical infrastructure through public funding. Nobody expects a bridge to turn a profit. We just... build it, because we've decided as a society that bridges are worth having.
But code is different, somehow. We expect code to pay for itself.
Because code lives in the private sector in a way that bridges don't. The internet grew up in this weird space between academia, government research, and private enterprise. Open source inherited that ambiguity — it's infrastructure, but it's not treated as infrastructure.
There's another layer here. The employment angle. You mentioned this earlier — the modern economy rewards work through employment contracts.
Right, this is crucial. An employment contract bundles two things together: compensation and control. The employer pays you, and in exchange they get to direct your labor. Open source breaks that bundle. Contribution is voluntary, so compensation becomes optional. The system has no mechanism to price "contribution to the commons" because it has no mechanism to enforce scarcity on it. You can't say "pay me or I'll stop maintaining this" — well, you can, but the license already gave everyone the code, so they can just fork it.
And someone will. Someone will fork it and maintain it for free, at least for a while.
Which brings us to the tragedy of the commons — except it's inverted. The classic tragedy of the commons is that a shared resource gets depleted because everyone uses it and nobody maintains it. Overgrazing the pasture. But with open source, the commons isn't being depleted — it's being enriched. The problem is the opposite. It's what Michael Heller calls the tragedy of the anti-commons.
Explain that.
Heller's idea is that fragmented ownership can lead to underuse of resources. Too many people have the right to exclude others, so nothing gets built. The classic example is empty storefronts in Moscow after the fall of the Soviet Union — you had six different parties with a claim on the same property, and nobody could open a shop because any one of them could veto it. With open source, the anti-commons flips again. Nobody can exclude anyone, so the resource gets overused while the creators get undercompensated. The value is created but cannot be captured.
The pasture is lush, the sheep are fat, and the shepherd is starving.
That's the image.
So if the mechanism is structural, not accidental, then the question becomes: what do we do about it? What has been tried, and what has failed?
Let's start with what exists. The big one is corporate sponsorship. Google, Microsoft, Meta — they all employ maintainers for critical open-source projects. Google pays people to work on Linux kernel security. Microsoft owns GitHub and funds a bunch of projects through it. Maintains React and PyTorch. This is real money, and it keeps a lot of important infrastructure alive.
But.
But it creates a dependency where corporate priorities shape the commons. The projects that get funded are the ones that serve corporate interests. If you're maintaining a library that's critical to, say, a nonprofit news organization or a small government agency, and no big tech company depends on it — good luck.
So the commons gets shaped by whoever has the deepest pockets.
And that's not necessarily aligned with what the commons actually needs. There's also the foundation model — the Linux Foundation, the Apache Foundation, Mozilla. These provide institutional support, legal infrastructure, sometimes direct funding. The Apache Foundation has something like three hundred projects under its umbrella. But they're perpetually underfunded relative to the value they steward.
And then there's crowdfunding. Open Collective, GitHub Sponsors.
Which has helped — GitHub Sponsors has moved something like forty million dollars to maintainers since it launched. That's not nothing. But it's a rounding error compared to the hundreds of billions in value. And it tends to concentrate on the most visible maintainers. The person who wrote the trendy frontend framework can pull in six figures. The person maintaining the compression library that every data center depends on? Maybe a few hundred dollars a month.
So the money flows to the surface, not the foundation.
And that's exactly the structural problem. The market prices visibility, not depth.
What about the bounty model? Paying for specific bugs.
This one's instructive because it's been tried repeatedly and it almost always fails. The idea is you put a cash reward on a specific bug or feature, and someone claims it by delivering the fix. The problem is it fragments attention. Maintainers chase bounties instead of doing the unglamorous work that keeps the project healthy — documentation, refactoring, reviewing other people's code. And it incentivizes gaming. People submit low-quality patches hoping one will slip through, or they camp on high-value bounties and rush out fixes that create more problems down the line.
So you get a lot of activity and not much progress.
You get a marketplace for quick fixes, not a system for sustainable infrastructure. It's the equivalent of paying firefighters per fire instead of funding the fire department.
There's another model you haven't mentioned. The patronage model. The Medicis funding artists.
Right — and this actually works, in a sense. Renaissance Florence produced extraordinary art because wealthy families competed to fund it. But it's inherently arbitrary and unstable. Michelangelo had patrons. Thousands of equally skilled artists didn't. And when the Medici family fell, the funding collapsed. Patronage depends on the whims of the wealthy, and the wealthy have whims.
So we've got corporate sponsorship that distorts priorities, foundations that are perpetually underfunded, crowdfunding that rewards visibility over depth, bounties that incentivize gaming, and patronage that depends on rich people's moods.
That's the landscape. And I should say — none of these are bad things in themselves. Corporate sponsorship has kept critical projects alive. Foundations provide real infrastructure. Crowdfunding has helped individual maintainers pay rent. The problem is the scale. None of these mechanisms come anywhere close to matching the value being created.
Which brings us to the deeper question. What does "work" mean in a post-scarcity information economy?
This is the thing I keep coming back to. If the marginal cost of distributing knowledge is zero, then the price of knowledge should approach zero. That's efficient, that's good — we want knowledge to be free. But then how do knowledge workers live? This is the same tension that drove the transition from agrarian to industrial economies. When farming became mechanized, millions of people had to find new kinds of work. The social contract had to be renegotiated.
And we're in the middle of that renegotiation now, with information.
We are, and we haven't really admitted it yet. The old social contract was: you work for a company, they pay you, you produce things the company sells. But more and more valuable work doesn't fit that model. Contributing to open source, writing documentation, maintaining datasets, doing peer review — all of this is real work that creates real value, and almost none of it happens inside an employment contract.
So what are the emerging alternatives? What might a mature system look like?
There are a few threads worth pulling on. One is universal basic income — decouple survival from employment entirely. If everyone has a floor, then contributing to the commons becomes a viable choice rather than a sacrifice. You don't have to choose between doing useful work and paying rent.
The objection is always that people would stop working.
And the evidence from the experiments that have been run — Finland, Kenya, Stockton, California — doesn't really support that. People do work. They just do different work. More care work, more creative work, more community work. The kind of work that markets systematically undervalue.
But UBI is a political nonstarter in a lot of places.
Sure. So there's another model: public option funding. Government grants for open-source infrastructure, the way we fund roads and bridges. The EU has something called the Next Generation Internet programme that does exactly this — it funds open-source projects that are critical to internet infrastructure. Germany has a Sovereign Tech Fund that's put millions into open-source maintenance. These are small programmes relative to the need, but they're proof that the model works.
Treat code as infrastructure and fund it like infrastructure.
That's the digital commons movement in a nutshell. Code, data, knowledge — these are infrastructure. They should be publicly funded, like libraries. The interesting design question is whether you can build incentive systems that reward contribution to the commons without recreating scarcity.
The answer might be?
I think — and I'm not certain about this — but I think the answer lies in separating "compensation for effort" from "price for access." Pay maintainers for their time, not for the code's market value. You don't charge per use of the encryption library. You fund the people who maintain it, because maintaining it is work, and work deserves compensation.
You're paying for the labor, not the product.
The product is free — that's the point. The labor that produces and maintains it is not. And we already accept this model in other domains. We pay teachers. We don't charge students per fact learned. We fund universities. We don't charge per citation of a research paper.
But we also underpay teachers and underfund universities, so maybe that's not the best example.
Fair. But the principle is sound even if the execution is flawed. The point is that we have conceptual models for funding public goods through collective investment. We just haven't applied them systematically to digital infrastructure.
What's the obstacle? Is it technical, political, cultural?
I think it's mostly cultural. There's a deep assumption that if something is valuable, the market should be able to price it, and if the market can't price it, maybe it's not actually valuable. That assumption is wrong — we've established that — but it's incredibly sticky. It shapes policy, it shapes funding decisions, it shapes what kind of work people consider "real."
The market can't price a sunset, but nobody argues sunsets aren't valuable.
Right, and the difference is that sunsets don't require maintenance. Open-source software does. Someone has to write the patches, review the pull requests, respond to the security reports. That's labor, and labor has a cost, even if the output is free.
The uncomfortable possibility is that the disconnect is not a bug but a feature — the commons is valuable precisely because it's outside the market, and trying to price it might destroy what makes it work.
That's the tension. If you attach a price to something that's currently free, you risk turning it into just another commodity. The gift economy aspect of open source — the fact that people contribute because they want to, because it's meaningful, because it's part of a community — that's real, and it's fragile. Monetize it badly and you could kill it.
But leaving it unmonetized means the maintainers burn out.
Burnout is the other side of the same coin. The gift economy works beautifully until it doesn't. And when it doesn't, the person who's been giving burns out and walks away, and suddenly a critical piece of infrastructure is abandoned. We've seen this happen. The npm left-pad incident in twenty sixteen — one developer unpublished an eleven-line package, and it broke thousands of projects, including major ones at Facebook and Netflix.
Eleven lines of code.
Eleven lines. And the developer didn't do anything wrong — he was in a trademark dispute and unpublishing was his right. But the system had no redundancy, no funding, no institutional support. It was all held together by the implicit assumption that this one person would keep maintaining this tiny thing forever, for free.
Before we wrap up, Hilbert — you've been quiet on this one. You've got some history with this, don't you?
Hilbert: Late nineties. I ran a small web-hosting company out of a strip mall in Tempe. Apache, Perl, Sendmail — the whole stack was open source. Every month I'd send invoices to my clients, and every month I'd think about the fact that my entire business depended on software maintained by people I'd never met, who had no obligation to fix anything if it broke.
Did it break?
Hilbert: Not catastrophically. But the anxiety was real. You'd see a security advisory come through and think — is this the one? Is this the week the maintainer decides they've had enough and walks away?
Did you ever try to pay them?
Hilbert: That's the part I wanted to mention. I tried. Nineteen ninety-eight, I think. Apache was running something like sixty percent of the web at that point. I called the Apache Foundation — or whatever they were called then, it might have just been the Apache Group — and I said I wanted to send them five hundred dollars. The person on the phone laughed. Not meanly. Just — they didn't have a mechanism. No donation page, no payment processing, no nothing. They said if I really wanted to, I could mail a check to someone's house.
You couldn't give them money.
Hilbert: The infrastructure for rewarding the commons was so underdeveloped that even when someone wanted to pay, the system couldn't take the money. I ended up buying the core developers a case of beer once when I was at a conference. That was the extent of my contribution.
A case of beer for the software that ran your business.
Hilbert: It was good beer. But yes.
Did you mail the check?
Hilbert: I didn't. I meant to. I had the address on a Post-it note on my monitor for about six months. Then we moved offices and I lost it.
That's almost worse. You had the impulse, you had the money, you had the address, and it still didn't happen.
Hilbert: The payment rails didn't exist. That's my point. Everyone talks about this like it's a willingness problem — people don't want to pay for open source. But for years, the infrastructure to accept payment literally didn't exist. Even now, it's still surprisingly hard to send money to the right person. You can sponsor a GitHub account, but half the projects you depend on aren't on GitHub, or they're maintained by someone whose account you can't find, or they're maintained by a team and you don't know how to split the money.
The institutional gap is at least as big as the cultural one.
Hilbert: I'd say bigger. My brother-in-law works in municipal water systems. He says the same thing about infrastructure generally — the pipes are underground, nobody thinks about them, and when they break, everyone acts surprised that pipes need maintenance. He's not to be trusted on most things, but he's right about that.
The pipes are underground. That's the whole thing, isn't it?
Hilbert: It is.
That detail about the donation infrastructure — it really captures the whole problem. Let's pull back and think about what this means.
The question Daniel's really asking, I think, is whether we can build a society where contributing to the commons is as viable a career path as working for a corporation. And I don't think the answer is purely technical. Better payment rails would help. Government funding would help. But underneath all of that is a deeper question about what we consider work.
We've built an economy where the default way to make a living is to produce something scarce and sell it. But the most valuable things — knowledge, code, ideas, infrastructure — they're not scarce. They want to be abundant. And we don't have a good answer for how to compensate the people who create abundance.
The printing press made knowledge abundant. The people who built it died poor. Open source made software abundant. The people who maintain it are burning out. The pattern is so consistent that you have to wonder if it's not a problem to be solved but a condition to be managed.
Or a choice we keep making without realizing it. We could choose to fund the commons. We do it for roads and bridges and libraries and public schools. We just haven't extended that logic to the digital world.
The uncomfortable possibility is that we haven't because we don't want to. Funding the commons means collective investment — taxes, public institutions, redistribution. It's easier to pretend the market will sort it out, even when we know the market can't price a public good by design.
The question sits there. What would a society look like where contributing to the commons is as viable as working for a corporation? We've got fragments of the answer — public funding, better payment infrastructure, a cultural shift in what we count as work. But the full picture isn't there yet.
Maybe it won't be until we stop treating the disconnect as a temporary glitch and start treating it as a structural feature that requires structural solutions. The market isn't going to fix this. The market is doing exactly what markets do. The question is what we build alongside the market.
Hilbert, anything else before we go?
Hilbert: I still have the Post-it note. Found it in a box last year. The address was in Maryland.
Of course it was.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for keeping this show running — he's maintained more infrastructure than he lets on.
If you've got thoughts on this one — or if you've ever tried to donate to a project and couldn't figure out how — email the show at show at my weird prompts dot com. We read everything.
We'll be back soon.
