Are We Serious About the Health of the OS That Makes the World Go Around? Maybe Not.

On April 21, 2026, a man named Andrew Morton posted a message to the Linux kernel mailing list saying he intended to begin stepping away from the memory management subsystem he had maintained for 26 years.

Almost no one responded.

Let that land for a moment.

The Linux memory management subsystem is the code that decides which programs get RAM, how much, and when to take it back. It is not glamorous. It does not have a logo. It does not get announced at re:Invent.

It is also the foundation on which every Android phone, every AWS instance, every Azure VM, every Kubernetes cluster, every AI training run, and every nuclear command-and-control system running Linux sits. It touches 164 heavily interlinked source files. Between 2020 and 2024, it accounted for 17.9% of all Linux kernel security vulnerabilities. It is, by any serious engineering definition, critical infrastructure.

One person reviewed the code going into it for 26 years.

This is not a story about open source being poorly funded, though that is also true. This is a story about sovereign infrastructure risk that almost no government or enterprise security team has bothered to model.

Think about what your organisation depends on Linux for right now. Your databases. Your container workloads. Your networking stack. Your AI inference pipelines. If you are in defence, logistics, energy, finance, or healthcare, the answer is: almost everything that matters. Linux is not a vendor product you can call a support line about. It is the substrate. It is the ground you build on.

And the ground was held together, at its most critical layer, by one individual.

Morton did not leave because he was burned out or bitter. He left because he had been carrying something no single person should carry for this long, and the community — meaning the companies that profit most from Linux — had done almost nothing to change that structure. When the developer summit convened in Zagreb two weeks after his announcement to discuss succession, they could not figure out how to replace him. The architecture of dependency he leaves behind is genuinely difficult to distribute.

That is a systemic failure. It did not happen overnight.

The questions your security team should be asking after this are not being asked.

Who are the other Andrew Mortons? Which other critical kernel subsystems are maintained by a single individual, on the basis of personal commitment, without formal succession planning, without redundancy, and without any organisational accountability if they stop? The answer is: more than you want to know.

Sovereign AI infrastructure strategies are being written in Canberra, Brussels, and Washington right now. They discuss GPU procurement, data residency, model training policy, and export controls. Very few of them discuss the health of the kernel subsystem stack that all of that infrastructure runs on. This is a significant gap. You cannot build a sovereign AI capability on top of a software commons you have made no investment in sustaining.

This is not theoretical. Morton’s announcement is a concrete, datable event. The community’s near-silence in response is a concrete, datable signal. The inability of a room full of senior kernel developers to articulate a clean succession model is a concrete, datable problem. The risk has been assigned no owner, no budget, and no remediation timeline — because it sits in a space that governments treat as someone else’s responsibility and enterprises treat as a vendor’s problem.

It is neither. It is yours.

Serious organisations fund the maintenance of infrastructure they depend on. This is not a novel concept. You pay for power grid redundancy. You pay for water treatment oversight. You pay for network uptime SLAs. You do not simply assume that critical shared infrastructure will maintain itself because it has so far.

The Linux Foundation exists. The Kernel Security Team exists. The LKML exists. The mechanisms for contribution are well-established. What is missing is the will — specifically, the will of the enterprises and governments that extract the most value from Linux to treat its maintenance as a line item rather than a charity.

A serious sovereign AI infrastructure strategy includes a budget line for upstream kernel contribution. A serious enterprise security posture includes an assessment of which open source maintainers represent single points of failure in your dependency graph. A serious government technology policy includes asking whether the software commons underpinning national infrastructure has adequate succession depth.

None of this is technically difficult. It requires only the acknowledgment that the infrastructure you depend on does not maintain itself, and that the people who have been maintaining it for decades deserve something more durable than goodwill and community gratitude.

Andrew Morton is stepping away from something he built and held for 26 years. The response from the industry that runs on his work was, essentially, silence.

If that does not disturb you, you are not paying attention to what your infrastructure is actually made of.

The health of Linux is not a kernel developer problem. It is a CTO problem. It is a CISO problem. It is a procurement problem and a policy problem and, increasingly, a sovereignty problem.

The question is not whether the Linux memory management subsystem will survive Morton’s departure. It probably will, messily, over time. The question is what we are prepared to do differently — institutionally, structurally, financially — before the next Morton posts his message and the room goes quiet.