The Plan For Linux After Torvalds Has A Kernel Of Truth: There Isn’t One

Opinion The Linux kernel is a remarkable creation. It has achieved a fundamental status in the industry, and thus the world, unmatched in scope, stability, and reputation. It powers lightbulbs to supercomputers, not to mention the billion-plus global army of Android. It covers a host of processors, a massive array of supported devices and an unparalleled choice of distributions.

You know all this. You also know, but most probably rarely think of, the regular cadence of new versions that come along more regularly than the seasons. You may not know that each accumulates around 20,000 updates, some from future versions, some for code more than a decade old. The kernel development and maintenance system has evolved to manage whole classes of virulent ills, such as dangerously insecure and deeply embedded CPU design flaws. People laud Apple for making four hardware architectural transitions between the Motorola 68K in 1984 and Apple Silicon in 2024. Linux currently supports a dozen or so. It’s hard to keep count.

Torvalds’ typing taste test touches tactile tragedy

READ MORE

The most startling Linux kernel feature is none of the above, but what’s missing. There has been virtually no drama, at least none visible to those who depend on the tech. It is both rapidly evolving and stable, and almost entirely invisible. It is entirely user-focused and built by volunteers. It is virtually inconceivable that it works, and totally inconceivable that anything else could come near.

It is also unthinkable that this would have happened without Linus Torvalds. How and why this came to pass is a story of a resonance with the mysteries of how low-level code and hardware come together to infuse life into both, the drive to do it properly, and the superpower to herd the ubergeek. The tech was right, the time was right, and… — well, that story is still being written.

Yet it must end. At some point, Torvalds will no longer be the Penguin Emperor. It may be a peaceful abdication far in the future. It may be neither. The unthinkable will have to be thought. Succession will have to happen, and there’s no plan for how that will work.

That’s not quite true. Torvalds has said that there’s no need for formality. Who is in line to step up when he steps off changes, and that’s fine. What matters, he says, is the trust earned over time among the community for the top tier of maintainers. The next benevolent overlord will appear naturally. It’s true that many decisions are made throughout the community by those other than Torvalds, and the degree of open discussion about absolutely everything from small details to major innovations is naturally far more open and communitarian than humanity normally enjoys. Torvald’s moral authority pervades, and others have already inherited it. That’s the plan.

This is dangerous. Succession is always a time of uncertainty for those who like the way things are, and opportunity for those who do not. The Linux kernel project has many tensions that are themselves remarkable for being universally agreed but with little urgency about fixing them.

This discussion of the Linux Kernel Report by Jon Corbet of LWN.net from the Open Source Summit has lots of reassuring stats with a very frank analysis of the project’s long term challenges. It’s a conservative, risk-averse community, which is a good thing, which makes necessary innovation, like moving to Rust, hard. Such difficulties are magnified by how overstretched developers — but more critically maintainers — are. Many are in effect doing two jobs, the one they’re paid for, and the Linux kernel work. It seems the $100bn companies who need Linux are happy for their employees to contribute, as long as they don’t have to pay. That gets old faster than you do.

This leaves the project vulnerable. Companies such as Red Hat are keen to twist open source to their commercial advantage, while fears of benchmark manipulation have gone towards rejecting innovations in configurable scheduling. Maintenance is frequently thankless, and under ever-increasing pressure as fuzzing and AI produce bug reports in huge quantities for triage.

Experienced volunteers are motivated by many things, but everyone has a limit. When Torvalds goes, the sense of discontinuity will be hard to bear, and the opportunism of commercial interests to grow influence will be non-zero. These are problems now that need addressing before they are ripened by events, and this is where succession planning should take place.

They can be every bit as formal and open as everything else — they have to be — and they can and should be iterative, experimental and focused. How do you create an environment where wise experience-hardened veterans can share experience with fresh-faced youth, while the fresh-faced youth takes on the workload? If you can’t manage a transition without documentation, what then? How, at heart, do you build mutual trust between generations who don’t speak the same language?

The Linux kernel is an amazing creation with an amazing creator, and both have demonstrated the ability to transition at their own speed and in good time. Succession can work that way. It can also be far less accommodating. Hope, as they say, is not a strategy. ®

Original Source