The Linux kernel community is experiencing a small, quiet but symbolic changing of the guard. Alex Gaynor, one of the early names behind the Rust for Linux initiative, has formally stepped down as co-maintainer of the Rust code in the kernel. The change is already reflected in the MAINTAINERS file of the main tree and is expected to land with Linux 6.19, leaving Miguel Ojeda as the sole official maintainer of the Rust subsystem, supported by several reviewers.
Beyond a simple one-line update in a file, Gaynor’s departure is a good moment to look back at how the effort to bring Rust into the kernel has evolved and what challenges lie ahead.
From PyCon Experiment to Kernel Code
In his email to the development lists, Gaynor recalls the origins of the project: in 2018, at PyCon, he and Geoffrey Thomas created linux-kernel-module-rust as an experiment to see whether it was possible to write kernel modules in Rust.
What many in the community first saw as a curiosity has since become the foundation of today’s Rust for Linux effort. The idea of introducing a memory-safe language into the heart of the operating system has gained traction, especially because of Rust’s ability to reduce memory-related bugs—one of the classic sources of vulnerabilities in C.
Gaynor himself admits that the project “has far exceeded” what they imagined back then. Rust support is now officially present in the kernel tree, several APIs and drivers written in Rust have been accepted, and the discussion is no longer about if Rust will be used, but where and to what extent.
A Matter of Time, Not of Interest
In his message, Alex Gaynor explains his decision without drama: he hasn’t had the time for a while to keep contributing code or reviews, and removing his name as maintainer is simply an honest acknowledgment of that reality.
This is a common scenario in long-running open-source projects, where professional and personal responsibilities change over time. Rather than hold on to a role he can’t exercise with the required dedication, Gaynor has chosen to step aside so others can fully take on the day-to-day work of maintenance.
Miguel Ojeda, the current leader of the Rust-for-Linux effort, replies with a brief but meaningful “it has been a pleasure,” and applies the patch to the rust-next branch, which serves as the base for ongoing Rust kernel development.
Miguel Ojeda as Sole Maintainer—But Not Alone
With Gaynor’s exit—and that of Wedson Almeida Filho last year—the “RUST” section of the MAINTAINERS file is now headed only by Miguel Ojeda ([email protected]) as main maintainer. He is supported by several reviewers (Boqun Feng, Gary Guo, and Björn Roy Baron) who remain actively involved in development and code review.
In practice, this means that the ultimate responsibility for accepting changes and setting the technical direction of Rust support in the kernel will rest more visibly on Ojeda. That said, the kernel’s development model remains deeply collaborative: reviewers, patch authors, and other subsystem maintainers all have a say in significant changes.
As always in Linux, the key will be balancing rapid progress in Rust adoption with the stability and coherence expected from a project with millions of lines of code and thousands of contributors.
What Does This Mean for the Future of Rust in the Kernel?
In the short term, Gaynor’s departure does not change the technical roadmap. Ongoing work—new safe APIs, more drivers written in Rust, and deeper integration with critical subsystems—will continue under the coordination of Ojeda and the rest of the team.
However, it does highlight two important realities:
- The need for generational hand-off among maintainers.
Rust for Linux has moved beyond the heroic phase—few people, long hours, everything up in the air—and entered a more stable cycle. That demands a broad enough base of maintainers and reviewers to handle patches, review code, and mentor new contributors. Spotting and training future maintainers will be crucial. - The lasting value of pioneers, even when they’re no longer on the front line.
Ojeda implicitly acknowledges that without the early work of Gaynor and Thomas, the project might never have reached its current level of maturity. The Linux community is full of similar stories: people who opened paths for others to follow years later.
Technically, the Rust-for-Linux effort still faces serious challenges: widening architecture support, maturing internal APIs, convincing more subsystem maintainers to accept Rust drivers, and proving—backed by numbers—that the promise of fewer memory bugs leads to fewer CVEs and fewer regressions.
Another Step in the Normalization of Rust
Alex Gaynor’s exit can also be read as a sign of normalization. When a project leaves its early, experimental stage and becomes part of everyday infrastructure, it’s common for pioneers to scale back their involvement and for responsibility to spread across a broader group.
Today, Rust has already proven it can coexist with C in demanding environments like the Linux kernel, and its presence in other systems software—browsers, databases, hypervisors, even firmware—is growing. The conversation has shifted from “is this possible?” to “how do we integrate it in the best possible way?”
Meanwhile, Gaynor’s name will disappear from the RUST section of the MAINTAINERS file, but his contribution remains embedded in the very fact that kernel-level Rust support exists and has a reasonably clear future.
Frequently Asked Questions
Who is now responsible for maintaining Rust support in the Linux kernel?
The official maintainer is Miguel Ojeda ([email protected]), who leads the Rust-for-Linux effort. He works with a group of reviewers who help evaluate patches and guide the evolution of the codebase.
Does Alex Gaynor’s departure put the Rust-for-Linux project at risk?
No. His decision is about limited personal time, not technical disagreements. The project has an active community and Rust code already merged into the kernel, so its continuity doesn’t depend on a single person.
What does Rust bring to the kernel compared to C?
Rust includes memory-safety guarantees at the language level (ownership, borrowing, stricter types) that reduce the likelihood of classic bugs such as buffer overflows, dangling pointers, or use-after-free errors. The goal is to cut down on vulnerabilities tied to these issues.
Can any developer start contributing Rust code to the kernel?
Yes, although it’s still essential to understand the kernel’s architecture and follow its contribution rules. There are specific Rust-for-Linux guides and mailing lists where new contributors can ask questions and submit their first patches for review.
Sources: phoronix y Kernel List
