The Linux phenomenon — procurement bypass, irreversible dependency, and a sample size of one

I've been trying to explain why the services model races to the bottom and how companies fight to reintroduce scarcity. But every conversation about open source sustainability eventually hits the same counterargument: "What about Linux?"

Linux is the proof that open source works at scale. The question is whether it proves anything about open source in general — or whether it's so unique that it's the exception that misleads.

The bypass

The part that surprised me most: Linux didn't win through corporate strategy. It won because it bypassed corporate governance entirely.

In the late 1990s, enterprise technology decisions went through procurement — business cases, legal reviews, budget approvals, vendor evaluations. The entire enterprise software industry was built on selling through that process. Microsoft, Oracle, IBM, SAP — their sales cycles targeted CTOs and procurement committees.

Linux ignored all of it. A developer could download it, install it on a spare server, and start running workloads. Zero cost meant zero decision points. No money changed hands, so no governance process was triggered. By the time management noticed, Linux was in production. The question wasn't "should we adopt this?" but "can we afford to rip it out?" — and the answer was no.

This is a fundamentally different adoption pattern from proprietary software. Proprietary software enters through the front door — procurement. Linux entered through the side door — a developer who needed something and grabbed it before anyone could say no.

The bypass is closed

Here's the part people miss: that specific bypass doesn't exist anymore.

Modern enterprises have open source programme offices (OSPOs), licence compliance scanning, software composition analysis, and approved-software catalogues. Open source adoption today goes through governance — lighter than proprietary procurement, but governance nonetheless.

The irony: Linux is the reason. Once organisations realised that unapproved software was running critical production workloads everywhere, they built processes to manage it. The procurement bypass created the conditions that made it unrepeatable.

The investment phase

With Linux irrevocably in production, a second dynamic kicked in. Contributing to the kernel became a business necessity.

The kernel's top contributors aren't volunteers — they're Intel, Google, Red Hat (IBM), Huawei, Meta, AMD, Oracle. Engineers on salary. Why pay people to maintain something you get for free? Because "free" has hidden costs. If your cloud runs on Linux, kernel bugs are your bugs. If your CPUs need Linux, kernel support is your market access. If a subsystem you depend on has one burnt-out maintainer, you have a business risk you don't control.

Contributing is risk management. And the investment follows the dependency: Intel contributes to hardware support. Google contributes to networking and containers. Meta contributes to memory management and BPF. No dependency, no contribution.

Why this doesn't generalise

I spent time thinking about what makes Linux unrepeatable. The full analysis is in The Linux Phenomenon, but the short version:

1. The timing — Linux filled a vacuum when Unix was fragmenting and the internet was creating server demand. That vacuum doesn't exist anymore.
2. The GPL — copyleft forces companies that ship Linux-based products to contribute changes back. Most modern projects choose permissive licences that enable free-riding.
3. The scope — nobody forks the kernel because the maintenance burden is too large. Most projects can be viably forked by a single well-funded company.
4. The governance — Torvalds has maintained technical authority for three decades through a singular combination of judgement and stubbornness. You can't manufacture that.
5. The criticality threshold — enough companies depend on Linux that collective self-interest sustains it. Most projects never cross this threshold. Below it, you get the xz utils problem.

The lesson Linux teaches: open source can produce extraordinary software when conditions align. The lesson it doesn't teach: that those conditions are reproducible. The Linux phenomenon is real. It is also a sample size of one.

If you're building an open source project and your sustainability plan is "Linux did it," you need a different plan. And if you want to pressure-test whether your project has the structural conditions for sustainability, that's exactly what the evaluation workshop is designed to do.