Brian Reed: Hey — quick question before we get rolling. You follow the open-source space more than I do. Did you always assume it was going to end up here, or does the actual shape of it still surprise you?
Eliza Ward: Honestly? The shape surprises me every time I look at it closely. We're talking about a movement that displaced Microsoft IIS and proprietary Unix servers — Apache HTTP Server and Linux just... ate them. Not by being cheaper. By being inspectable and moveable. That's the pitch that worked.
Brian Reed: And then IBM pays thirty-four billion dollars for a company built on free code.
Eliza Ward: Right — and that's the hinge. That's what today is about. The Red Hat acquisition in 2019 is the moment the market puts a price on something and the price is thirty-four billion and the thing being priced is, technically, available for zero.
Brian Reed: So what was IBM actually buying? Like, what's in the box for thirty-four billion?
Eliza Ward: They weren't buying the code. They were buying — I mean, think about it as the labor of translation. Enterprises were too understaffed to navigate open-source projects themselves, so Red Hat was the thing that stood between them and the raw community. That's rent on knowledge, not rent on IP.
Brian Reed: That's a genuinely different business than selling software.
Eliza Ward: It is. And it proves something that I don't think the open-source movement fully processed — that avoiding vendor lock-in is what enterprises say is the leading reason they adopt open-source, and yet — wait, here's the gap — by the time global cloud spending clears six hundred and seventy-eight billion in 2024, AWS, Azure, and GCP are running most of it, on Linux, on Kubernetes, on Apache-lineage software.
Brian Reed: Three companies. On top of free infrastructure.
Eliza Ward: Which is the question driving everything today. Open-source won. Linux won, Apache won. So — did the lock-in actually go away, or did it just move up a layer where nobody was looking?
Brian Reed: And is that the same problem, or is it a different problem with the same name?
Eliza Ward: That's the one I want to work out.
Brian Reed: Okay, let me try to make that concrete, because I think there's a cleaner way to see it. Imagine you're buying a car and the dealer says — this car only runs on fuel from our stations. Forever. You want to drive somewhere we don't have a pump? Too bad. That's what Microsoft IIS was. That's what Sun Solaris was in the nineties. The code was theirs, the interfaces were theirs, and the moment you were in, your bargaining power was gone.
Eliza Ward: And open-source is the car that works at any pump.
Brian Reed: Exactly — that's the whole game. You might pay more for the mechanic. Red Hat was the mechanic. But you could always drive away. That option existed. And that's not a small thing — that's the reason enterprises chose Linux over proprietary Unix, Apache over IIS. Not because Linux was free. Because it meant no single vendor could hold the keys.
Eliza Ward: Right — and the word is optionality. Future freedom. You're not buying software, you're buying the ability to leave.
Brian Reed: Which is a completely different thing than buying a discount.
Eliza Ward: Wait — and that distinction actually matters a lot, because... I mean, the research is pretty clear that avoiding lock-in is cited as the primary driver. Not cost savings. Enterprises were making a calculated bet on their own future leverage.
Brian Reed: So Red Hat's whole business — the thirty-four billion — it only works if the optionality is real. Like, if you couldn't actually leave, nobody pays premium support fees for the privilege of being on Linux.
Eliza Ward: That's it exactly. Red Hat's model depended on the underlying freedom being genuine. The services had value because the code was portable. Take away portability, the whole justification collapses.
Brian Reed: But here's what I don't get — the car analogy works for 2001. You're free of Sun Solaris, you're free of Windows NT, great. But by the time you're running Kubernetes on AWS, the mechanic is now also the only one who really knows the road.
Eliza Ward: Right — and the code is still portable. Technically. You can take your Kubernetes workloads anywhere. The problem is — actually, no, the problem isn't portability anymore. It's the operational cost of the move.
Brian Reed: So the car works at any pump. You just need eight months and two million dollars to find a new mechanic.
Eliza Ward: Which is — yeah, that's the gap nobody priced in. The license is free. The leaving is not.
Brian Reed: The leaving cost was never in the original equation. But hang on, because I think we're skipping the part that explains how any of this got big enough to matter in the first place.
Eliza Ward: The engine that built it.
Brian Reed: Right. Because none of this — not Linux, not Apache, not Kubernetes — none of it happens without this specific mechanic where developers fix the thing they personally need fixed.
Eliza Ward: Scratch your own itch. And the key word is 'own.' It's not altruism. It's — actually, let me put a person in it. It's 2002, Saturday morning, a backend engineer at a shipping logistics company. Her Apache HTTP Server is down. She finds the bug, patches it, commits it back to the project. Six hundred other engineers hit the same wall that year and do the same thing.
Brian Reed: And no proprietary R&D team has six hundred people all personally motivated to fix that one bug on a Saturday.
Eliza Ward: That's exactly it. No single vendor budget replicates that. Eric Raymond's whole argument in 'The Cathedral and the Bazaar' — the bazaar wins because the diversity of contributors means more itches, more patches, faster.
Brian Reed: The cathedral being — what, Microsoft? Sun?
Eliza Ward: Planned, hierarchical, closed. You ship when the team ships. Raymond's point was that the bazaar model produces quality through sheer parallel redundancy — and that was a genuine theoretical argument in 1997, 1998. But the legal floor that made it possible was twenty years earlier. Stallman, GNU Project, 1983. Copyleft licensing.
Brian Reed: The part I find almost counterintuitive — copyleft isn't just a license. It's a ratchet. Like, you can use the code, but you can't pull it private.
Eliza Ward: That's the mechanism. GPL locks the commons open. Which means every Saturday patch, every contributed fix — it stays in the pool. That's the compounding. Each new adopter expands the integration surface, the compatible tooling, the available expertise.
Brian Reed: So Git is maybe the clearest proof case here. Torvalds built it in 2005 because he needed it — personally needed it — to manage Linux contributions. That's the itch. And now it is literally the scaffold every software team on earth uses.
Eliza Ward: Wait — and the compounding there is almost ridiculous. Once enough teams use Git, every new tool integrates with Git, which means every new developer learns Git, which means switching to anything else costs — I mean, the ecosystem just seals around it.
Brian Reed: And the 1998 OSI founding — that's the moment someone said, let's not call this a political movement, let's call it a business strategy. Raymond and Bruce Perens essentially rebranded Stallman's ideological framework into something a CTO could put in a budget proposal.
Eliza Ward: Which is how Kubernetes gets donated to the Cloud Native Computing Foundation — vendor-neutral governance, nobody captures it, the ecosystem compounds faster than any proprietary alternative could track. That's the same logic, just at hyperscale.
Brian Reed: So the mechanism that kept Apache free from Microsoft — it's the same mechanism that let Google hand off Kubernetes and still win.
Eliza Ward: Right — and that's the thing we have to come back to, because the same compounding that made it impossible for proprietary software to compete is now doing something else entirely at the cloud infrastructure layer, and it's not obvious it's working the same direction.
Brian Reed: But that's the part that doesn't sit right — because compounding toward hyperscalers isn't a betrayal of the model. It might be the model working exactly as designed. Like, Google didn't capture Kubernetes. Google contributed the most engineers, so Google's itch is what got scratched.
Eliza Ward: Wait — say that again.
Brian Reed: The scratch-your-own-itch model assumed the itches were distributed. Thousands of engineers, thousands of different problems, collectively steering the project toward broad utility. But most top Linux kernel contributors now — they're full-time employees at Google, Microsoft, Meta, Amazon. Their itch is planetary scale. A three-person fintech startup's itch is, I don't know, reliable deploys on a Tuesday.
Eliza Ward: Those aren't equivalent inputs.
Brian Reed: No. And the roadmap follows the contributors. So CNCF governance is vendor-neutral in name — genuinely, the structure is there — but hyperscaler-weighted in practice because the firms with the most engineers are shaping what Kubernetes becomes.
Eliza Ward: And copyleft can't fix that. GPL prevents someone from pulling the code private, but it doesn't prevent — I mean, it doesn't stop a corporate contributor from steering architecture toward patterns that happen to favor their own managed-service offering. That's soft capture. The license has no mechanism for it.
Brian Reed: Which is the thing that actually worries me more than the license question. Because AWS EKS, Google GKE, Azure AKS — the code running underneath all three is open. Theoretically portable. But the moment you're running workloads inside EKS, data gravity kicks in. Your logs are in CloudWatch, your networking is VPC-shaped, your team knows no other operational surface.
Eliza Ward: The switching cost approaches — actually, it reaches what proprietary lock-in cost in the nineties. Same number, different origin.
Brian Reed: Right — but here's what I find almost perverse about it. Red Hat's thirty-four billion wasn't built on owning the code. It was rent on knowledge — enterprises too understaffed to navigate the raw community. But managed services just... automate that rent. AWS EKS doesn't translate open-source for you, it just absorbs you into a deployment environment you can't easily leave.
Eliza Ward: The translation layer became the trap.
Brian Reed: And the irony is — the movement that made this possible, Stallman's copyleft, Raymond's bazaar model, the whole compounding mechanism — it worked. It beat proprietary software. Linux is running the cloud. Kubernetes is the infrastructure standard. And the prize for winning is that three companies now control the deployment layer that sits on top of all of it.
Eliza Ward: The fence didn't disappear. It just got moved somewhere most enterprises aren't looking yet.
Brian Reed: And the thing I can't settle — I mean, I keep turning this over and I don't get to a clean answer — is whether that was always going to happen. Like, was the optionality ever transferable to a three-person fintech, or did it only ever belong to the firms that could put fifty engineers on a Kubernetes pull request?
Eliza Ward: That's the one. That's exactly the one I can't resolve either. Because enterprise adoption surveys say lock-in avoidance is the leading driver — not price, not TCO, lock-in avoidance. But exercising that optionality at scale requires... it requires the resources of the people who built the cage.
Brian Reed: The freedom was real. Just not equally reachable.
Eliza Ward: Yeah. And I don't know if that's a failure of open-source or just — actually, no, I think it might be the thing open-source was never designed to solve. Stallman's copyleft, Raymond's bazaar, the CNCF handing Kubernetes vendor-neutral governance — none of that addressed who has the capacity to move. It addressed who owns the code.
Brian Reed: Those are different problems.
Eliza Ward: Different problems. And we spent forty years solving one of them brilliantly. I think that's where I land — genuinely unresolved, but less confused about what the question actually is.
