One person held the code that runs every Android phone, cloud server, and supercomputer for 26 years. On April 21, he posted one message and then was silent.
Twenty-six years. One maintainer.
Every Android phone, every cloud server, every supercomputer on the planet depends on a single kernel subsystem to allocate, reclaim, and protect its memory. 164 source files, all interlinked. 17.9% of all Linux kernel security vulnerabilities between 2020 and 2024 came from this code.
One person reviewed the code going into this subsystem for 26 years.
On April 21, 2026, that person posted a message to the kernel mailing list saying he intended to begin stepping away.
Almost no one responded.
Two weeks later, at a developer summit in Zagreb, the memory management team tried to figure out how to replace him. They couldn't.
The Colonel of the Kernel
His name is Andrew Morton. He was stepping away from the Linux memory management subsystem, the part of the kernel responsible for deciding which programs get RAM, how much, and when to take it back. He had carried it since before it was even considered its own subsystem.
Before Morton touched the Linux kernel, he was building kit computers in Sydney. In 1984, he co-founded Applix Pty. Ltd. He designed its best-known product, the Applix 1616, a Motorola 68000-based machine sold as a DIY kit through electronics magazines. About 400 people bought one. It ran a custom multitasking operating system burned into ROM, a read-only memory chip that holds its data even when the power is off.
He spent the next decade at Nortel Networks managing software development in Australia, then moved his family from Wollongong to Palo Alto in 2001.
Somewhere in that transition, Linus Torvalds noticed him.
Around 2000, Torvalds "tapped him on the shoulder," as the histories describe it, recognizing Morton's ability to "play well with others and maintain sanity." The second quality is the rare one. Thousands of people can write kernel code. Almost no one can maintain sanity while reviewing thousands of other people's kernel code, year after year, for over two decades.
By 2003, eWeek ran a headline: "OSDL Brings Torvalds' Right-Hand Man on Board." The Open Source Development Labs (OSDL) had hired Morton to work on the kernel full-time. InformationWeek called him "Colonel of the Kernel" in 2007. Torvalds himself, characteristically deadpan, put it differently: "I think Andrew is listed as 'lead maintainer' simply because people take me for granted, so Andrew is the lead when you ignore me."
By 2007, Morton had signed off on 18,622 patches. Second only to Torvalds himself, who had 19,890.
Think of signing off on a patch like cosigning someone's loan. You are putting your name on someone else's work and saying: I reviewed this, I trust this, if this breaks production on a billion devices, my name is on the line. Morton did that 18,622 times, while also maintaining the staging tree where most of those patches landed first.
He has been at Google since 2006, maintaining the memory subsystem of the operating system that Google's entire infrastructure runs on out of Palo Alto for twenty years.
When Morton Laughs
The kernel's mm directory, short for memory management, contains 164 C source files. Morton told the room in Zagreb that terms like THP (transparent huge pages), cgroup (control groups), and NUMA (non-uniform memory access) each appear across a large number of those files. The core concepts bleed through everything.
"Everything is heavily interlinked," Morton said, "so trying to split up the subsystem will be challenging."
Then he smiled: "It's not my problem."
Morton could afford to laugh. The developers who would inherit pieces of his responsibility could not.
The mm subsystem is not some obscure corner of the kernel. Between 2020 and 2024, it accounted for 17.9% of all Linux kernel CVEs, publicly registered security vulnerabilities. When combined with networking, those two subsystems alone accounted for 38% of all kernel security vulnerabilities. Use-after-free and out-of-bounds write bugs, the most common CVE types in memory management, made up roughly 35% of all kernel CVEs in 2024.
This is the code that decides whether your phone's apps stay in RAM or get killed, whether your cloud database keeps its pages hot or flushes them to disk. It also decides whether a virtual machine's memory stays isolated from every other VM on the same physical host.
One person held this together, like a librarian who memorized the location of every book in a library with 164 rooms, all connected by hidden doors.
Two Weeks Later, Zagreb
The room at the Esplanade Hotel in Zagreb, Croatia, was full of memory management developers. May 4 through 6, 2026. The annual summit where kernel subsystem developers meet face-to-face to discuss problems that email cannot solve.
Morton opened the session by noting the silence after his April 21 announcement. Almost no responses. "That was a result of the fact that he was asking others to take on more responsibility," the session summary noted. Developers would have to take on a lot of tasks.
The catch-all integration tree, the central repository where all memory management patches are collected and tested before reaching the official kernel, had been Morton's since the early 2000s. David Hildenbrand would pick it up. Morton offered his thanks.
Hildenbrand is no amateur. He spent ten years at Red Hat in Munich and moved to Arm in late 2025. His first upstream kernel commit dates to 2014. He already maintains half a dozen other kernel subsystems. He was elected to the Linux Foundation's Technical Advisory Board in 2025.
At the 2025 summit, a year before his own announcement, Morton flagged the problem himself: nobody was reviewing David Hildenbrand's patches, because there were simply too many of them.
Hildenbrand was already overloaded before he inherited anything new.
The Culture Question
Morton used the Zagreb session to talk about something most maintainers never mention out loud: culture.
He described the mm team as "a great group of people; they are cooperative and quick to help each other." But he worried the community could "over time regress to be like other parts of the kernel or other open-source projects, where emails are ignored because maintainers are too busy." As far as Morton is concerned, "ignoring messages from contributors is shameful and unacceptable."
Dan Williams, another developer in the room, made the problem concrete. The community had "long depended on Morton to apply pressure when responses are needed." Morton was the person who made other people answer their email.
Every engineering organization has one senior engineer who replies to the thread everyone else pretends not to see. When that person leaves, the thread stays unanswered, the decision drifts, and six months later, a production incident traces back to the silence.
Who does that now?
Morton also raised the review problem. The review work across memory management is "quite lopsided," he said. A small number of people do the bulk of the reviewing, while many developers don't carry much review load at all. He said he does not understand why things work that way. Matthew Wilcox, one of those heavy reviewers, said he always tells newcomers to start by reviewing patches. "That advice is often not taken."
And then there is the AI question. Morton described the layers of defense that protect the kernel from bad code: community review, weeks of testing in the mm tree, weeks in the mainline, stable backports, distributor testing, and now Sashiko, an LLM-based review tool that has become another layer.
Hildenbrand pushed back on that last layer. He said LLM-based reviews "should not be posted to the public lists." His reasoning was human, not technical. Early-stage reviewers, the people the subsystem desperately needs to develop, "will be demotivated by seeing that automated reviews have already found many of the problems."
Machines finding bugs faster than humans is, technically, a win. But if it drives away the humans who would eventually become the next generation of maintainers, it is a loss the kernel cannot afford.
If the thought of one person holding this together for 26 years concerns you, clap, leave a comment, or share this with your open source team.
Morton himself noted that beginning reviewers "often focus on understandability issues that more experienced developers will skip over." That feedback makes the code more readable for everyone who comes after them.
What 40 Million Lines Lose
The Linux kernel is roughly 40 million lines of code. The 7.1 merge window alone pulled 12,996 changesets into the mainline from 2,011 developers, 342 of them contributing to the kernel for the first time.
Morton held the quality gate on one of the most dangerous corners of that codebase for 26 years. Memory management does not get conference keynotes or corporate sponsorship with a logo on the slide deck. But a single misplaced pointer dereference in this code can give an attacker root access to every server running the kernel.
Hildenbrand closed the session by thanking Morton and warning him: "The community was not going to let him go easily." A working group will be formed to figure out how the memory management community's development model should work going forward. Some sub-components may move to their own trees. There will always be the integration tree to pull everything together.
But Morton is not replaceable, and the reason is not technical. Other developers understand memory management. The problem is that he did the work no one else wanted to do, kept that pace for 26 years, answered every email, and expected others to do the same. That combination does not exist in another person.
"I do less than I used to," Morton said back in 2008. "Mainly because I have to. You can't do the same thing at a high level of intensity for over five years and stay sane."
That was eighteen years ago. He kept going for eighteen more.
If your company runs Linux (and it does), if your phone runs Android (and 3 out of 4 phones worldwide do), if your cloud provider runs on the kernel (and every single one of them does), then one man's sanity has been standing between your infrastructure and chaos for over two decades.
He just told everyone he's done.
What did your organization contribute to make sure someone is ready to take his place?
If your company runs on Linux and you have never thought about who maintains the memory subsystem, clap, leave a comment, or share this. The people picking up the work need to know someone is paying attention.
This week, I have a birthday! If you would like to contribute to the birthday gift, there is an official way to do so on Medium. Here is the screenshot of how to do it:
