So Linus has joined the war on slop, on the side of slop. "Yay." Truly the coolest of beans in today's news feed.

The main take I'm hearing today is that this is a lesson in why your project shouldn't have a Benevolent Dictator For Life (BDFL) model of governance. I understand where those people are coming from - if you already dislike the BDFL model, you don't really have a reason to look deeper, even if we've seen multiple high-profile committee-led open source projects go the same sloppy direction (the Rust core development process comes to mind with the whole infamous "not includin' the ethics" blowup).[^1]

Now, I would argue that under normal, healthy ecosystem preconditions - we'll get back to that, it's the meat of the post - [this isn't the end of the world, even if it's inconvenient](/blog/fuller-stack/002d-trust-me-or-dont). There's supposed to be a bit of a clear sequence of events when a project's governance fails its constituents:

1. The project has a clear figurehead as a value beacon. It sucks for those values to turn rancid, but the good news is we can see it really clearly when it happens.
2. People move to alternatives, if they're not cool with the new direction.
3. If no alternative exists, somebody will create one, often by forking.

This has happened a hundred times in the open source community, so it's noteworthy to point out the actual failure mode happening today: Linux is "too big to fail", or at least the open source version of it - "too big to replace."

It's easy to think of Linux as a work product rather than a work process. You can point at a tarball full of source code or a git repository and say "that's Linux!" and you're not entirely wrong, but specifically through the lens of ongoing support, you're not adequately right. Linux is also the people who make the software. Linux is the regular patches that you _need_ because Linux is too big to be complete or correct, and when some new vulnerability inevitably gets announced, a giant C codebase you don't have the skills to modify _will not save you._ It's distribution channels, it's funding. It's literal thousands of interpersonal trust relationships and unthinkable hours of free(ly contributed) labor. **It is, compared to almost every other open source project or would-be development team, resource-infinite, while also a focal point of vendor lock-in for driver development.**

So when Linus Torvalds himself says "if you don't like it, fork," he's invoking the same snideness towards the no-AI community that has historically been used to wrangle proprietary companies into contributing code. The Linux kernel isn't just large, it's fast-moving, so if you need to modify it to support a product you sell, dealing with upstream is the only practical option - what are you gonna do, maintain a patchset that keeps getting broken by upstream development? The only change-resilient way to make your own kernel modifications is to get them merged on the kernel team's terms, so the kernel team (and their vast well of resources) are the ones on the hook to maintain it. Forking is an impractical solution for anyone, and that's the point. That's the leverage. That's the subtext beneath the words - you can do things the Linus's way, or you can go eat a tin can, sharp-end first.

This leverage works because, for many people, there's nowhere else to go. Other operating systems like the BSD family exist, but can represent significant downgrades in performance and device support for consumer hardware. And after that, your alternatives only get more obscure. Many of them have to implement shims to run Linux drivers, and that doesn't always work smoothly.

Certain categories of project are _large by convention,_ like web browsers - the feature scope is so large that you end up with only a small handful of well-maintained options. Operating system kernels fall in this category too. If you care about broad device support and high performance, that's a level of effort that prohibits a lot of competition, and of the three major options you have, two of them (Windows, OS X) are proprietary. And yet, competition is necessary for the mechanisms of a healthy open source ecosystem to work properly. We can't really tolerate "too big to fail" - or, in a certain sense, we comfortably _can_ until it becomes abruptly uncomfortable, at which point we're already well up a creek with precious little we can do about it, and that's the problem.

The actual solution here, rather than elevating any project to infallible status, is to understand that portable drivers - which can run on many different kernels cleanly - are the only structural way to break kernel monopolies. I'm not really talking about process isolation, [that's more of a microkernel thing](/software/mercury), but I'm talking about maintainership isolation. Whether Linus or an entire foundation of commercially-funded stakeholders decides to shit the Linux kernel bed, I don't care - it should be _inconsequential_ if that bed gets shat in.

Ideally, we get some standards for how drivers talk to kernels, which would be a valuable abstraction for letting new and small kernels have a chance in this world. It could even be largely inspired by the Linux kernel module interface, reducing the effort to move existing driver effort to neutral ground, since most of it is in Linux today. But standards are hard if they're not just formalizing stuff people already do, so I honestly think the effort for portable drivers _has_ to predate the standards. What we need, is people writing drivers:

 * as separate repositories,
 * with a common core that's device-specific,
 * and different platform-specific glue code for various kernels.

At some point, if a new standard forms, that's just another kernel-side platform that drivers can support to get massive kernel portability for free. This isn't a new idea, either - do you think the Nvidia proprietary GPU driver for Linux doesn't share code with the Windows version behind the scenes? But doing this explicitly, in open source drivers, is a shift we owe ourselves to make - sooner rather than later.

[^1]: We've also seen BDFLs use their position of authority to reject AI slop conclusively.