Contributions to the Linux kernel are at record highs, but the number of people who review and merge those contributions has not grown at the same rate. This is the kernel maintainer bottleneck: the constraint has moved from writing code to getting it reviewed and accepted. For embedded teams sending drivers and board support upstream, it means longer lead times and a real advantage for patches that are easy to review.
If you have sent a patch to a kernel subsystem and watched it sit on the mailing list for weeks, you have met the kernel maintainer bottleneck first hand. The problem is usually not that your code is wrong. It is that the small number of people who can review and merge it are handling more work than ever. Kernel development in 2026 has plenty of hands writing code. What it has less of is time to review that code and move it toward the mainline.
This is not a complaint about individuals. It is a structural feature of how the kernel is built, and it is now discussed openly by the people who run the project. Understanding it helps you plan upstreaming work realistically instead of being surprised by it.
More code, more contributors, every year
By raw activity, the kernel community looks healthy and is still growing. The 6.18 release, which closed the last full development cycle of 2025, brought in 13,710 commits from 2,134 developers. That developer count is the highest in the kernel’s history. The release also drew 333 first-time contributors, just short of the record 335 set a year earlier in 6.12.
Across the full year covered by releases 6.13 through 6.18, the kernel absorbed 80,035 non-merge changesets from 5,275 developers working for 372 known employers. Greg Kroah-Hartman has noted that every single release now features the work of at least 200 first-time contributors. The supply of people who want to write kernel code is not the problem.
Where the kernel maintainer bottleneck actually sits
Writing a patch is the part of the process that scales with the number of contributors. Reviewing and merging that patch does not scale the same way, because it depends on a much smaller and more stable group of people.
The tags recorded on merged commits show this. In 6.18, 53.6% of commits carried a Reviewed-by tag and only 9.0% carried a Tested-by tag, both typical figures for recent releases. The most active reviewers are close to the same names release after release; as the kernel’s own statistics put it, the community’s most diligent reviewers are seemingly in it for the long term. On the merge side, just over half of all patches reaching the mainline pass through the hands of maintainers employed by only five companies: Meta and Google, Intel and AMD, and Red Hat. When a handful of trusted people gate most of the flow, their available hours determine how fast everyone else’s work moves.
💡 Key insight: The limit on kernel throughput is not how much code gets written. It is how much code a small, relatively fixed set of reviewers and maintainers can examine and accept.
A warning from 2018 that reads differently now
This concern is not new. In 2018 Daniel Vetter, a longtime graphics maintainer, studied how often maintainers commit their own patches and used that as a proxy for maintainer capacity. He found that the number was falling relative to the kernel’s growth, and that the community was not training new maintainers fast enough to keep up. His extrapolation was blunt: “around the year 2025 large numbers of kernel maintainers will do nothing else than be the bottleneck, preventing everyone else from getting their work merged and not contributing anything of their own.”
He also pointed to a double standard that still exists: ordinary contributors must get their patches reviewed, while maintainers can commit their own code with no recorded review. His darker forecast, that the community would implode under its own bureaucratic weight, did not come true. Contributions kept climbing to record levels. But the underlying concern he raised has moved from a contrarian blog post to a mainstream topic that the project now plans around.
💡 Key insight: The kernel did not collapse under maintainer load. Instead, the load became a first-class process problem that the project actively manages, rather than an edge worry that gets dismissed.
Burnout, succession, and more patches than ever
The human side of this is now discussed directly at the yearly Maintainers Summit. At the 2023 summit, Ted Ts’o observed that maintainers end up absorbing every task nobody else wants to take on: patch review, release engineering, testing, and responding to security reports. Those expectations have only grown over time.
The 2025 Maintainers Summit, held in Tokyo on 10 December, devoted a full session to continuity and succession planning. There are now provisions so that no single person is a point of failure: several people can commit to Linus Torvalds’s repository, and the stable tree has similar redundancy. If a smooth handover ever became impossible, the plan is for the attendees of the most recent summit to convene and decide the path forward. Torvalds, for his part, has signed a new contract with the Linux Foundation and does not plan to step back soon.
Two recent developments show why the process layer, not the code, is often the part under strain. The bcachefs filesystem was removed from the mainline kernel in 2025 after repeated disagreements over the development process, an episode one participant described as a “perfect storm.” And the same 2025 summit opened a discussion toward a policy for machine-learning tools in kernel development, driven in part by a simple worry: tools that generate patches faster add review load to the same limited group of people.
What the kernel maintainer bottleneck means for your team
If your work involves sending drivers, board support, or fixes upstream, the bottleneck has direct, practical consequences. A few habits help you work with it rather than against it.
- Budget real lead time for upstreaming. A non-trivial driver or board-support series can take several release cycles to land, not one. Plan product schedules around that reality instead of an optimistic single-cycle merge.
- Make patches cheap to review. Small, well-split series, clear commit messages, and included tests move faster because each one costs a maintainer less time and attention.
- Become a reviewer, not only a submitter. Review capacity is the scarce resource. A team that helps review other people’s work in a subsystem builds the trust and goodwill that gets its own patches merged.
- Prefer subsystems with active, multi-person maintainership. Where you have a design choice, a well-staffed subsystem is less likely to stall on one person’s availability.
- Keep an out-of-tree plan. If a series will not land before you ship, know the cost of carrying it as a downstream patch and have a concrete plan to upstream it later.
These are exactly the working habits we focus on in our Linux Kernel Infrastructure training, where writing reviewable, mainline-ready code is treated as a core skill rather than an afterthought.
💡 Key insight: For an embedded team, the useful response to the bottleneck is to lower the review cost of your own contributions and to help carry the review load, not to wait for the constraint to disappear.
Key takeaways
- Kernel contributions are at record highs; review and merge capacity is the real constraint.
- Only about 54% of merged commits carry a recorded review, and just over half of all patches pass through maintainers at five companies.
- Daniel Vetter predicted a maintainer bottleneck around 2025; the collapse he feared did not happen, but the concern is now a mainstream process topic.
- Burnout, succession planning, and a growing volume of machine-generated patches are all active concerns for the people who run the project.
- Teams that write reviewable patches, help review, and budget for longer upstreaming timelines get their code merged with less friction.
Frequently asked questions
What is the kernel maintainer bottleneck?
It is the gap between how much code is submitted to the Linux kernel and how much a relatively small group of reviewers and maintainers can review and merge. Writing patches scales with the number of contributors; review and acceptance do not.
Is the Linux kernel running out of maintainers?
No. Every release still draws record numbers of contributors, including at least 200 first-time contributors. The narrower concern is that review and merge work is concentrated in a small, stable group, and training new maintainers has not kept pace with the growth in contributions.
How long does it take to get a patch merged upstream?
It varies by subsystem, but a non-trivial driver or board-support series often takes several release cycles rather than one. Well-split, clearly described, and tested patches move faster because they cost reviewers less time.
How can an embedded team reduce the impact of the bottleneck?
Budget lead time for upstreaming, make patches small and easy to review, contribute review effort back to the subsystem, prefer subsystems with active multi-person maintainership, and keep a plan for carrying code out-of-tree if it will not land before you ship.
Further reading
- Jonathan Corbet, “Some 6.18 development statistics”, LWN.net, 1 December 2025.
- Daniel Vetter, “Linux Kernel Maintainer Statistics” (LWN summary), LWN.net, April 2018.
- “The 2025 Maintainers Summit”, LWN.net, December 2025.
- Jonathan Corbet, “2025 Maintainers Summit development process discussions”, LWN.net, 16 December 2025.
- “Reducing kernel-maintainer burnout”, LWN.net, 2023 Maintainers Summit coverage.
