The Linux Kernel at 35: How Open Source Became the Infrastructure Layer of the Entire

The Most Important Software Project in History

In August 1991, a 21-year-old Finnish computer science student named Linus Torvalds posted a modest message to the comp.os.minix Usenet newsgroup: “I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu).” Thirty-five years later, that hobby project runs the vast majority of the world’s web servers (Linux powers over 78% of web-facing servers, per W3Techs 2025 data), 100% of the world’s 500 fastest supercomputers (per the TOP500 list — a streak unbroken since November 2017), the entirety of Android’s approximately 3.9 billion active devices, the infrastructure of every major cloud provider (AWS, Azure, Google Cloud, Oracle Cloud), and the embedded systems in cars, routers, smart TVs, and industrial controllers worldwide. By any measure — deployment scale, economic impact, developer participation, or longevity — the Linux kernel is the most important software project in human history.

The kernel itself — the core component that manages hardware, memory, processes, and system calls — has grown to over 40 million lines of code, a milestone crossed in January 2025 when the Linux 6.14-rc1 release reached 40,063,856 lines. The codebase has doubled in size over the past decade. It supports dozens of CPU architectures (x86, ARM, RISC-V, PowerPC, s390), hundreds of hardware drivers, and nearly every networking protocol in use. Each kernel release (approximately every 9-10 weeks) incorporates contributions from over 2,000 developers representing more than 1,700 organizations. The development velocity is remarkable: the 6.15 kernel alone brought 14,612 changesets — the busiest release since 6.7 — with 262 first-time contributors and contributions arriving at a rate of approximately 8 patches per hour.

What makes Linux’s dominance particularly striking is that no single entity owns it. The kernel is licensed under GPLv2 — anyone can use, modify, and distribute it, provided they share their modifications under the same license. This legal framework transformed Linux from a student project into a commons-based resource that trillion-dollar companies depend on but cannot monopolize. The economics of this arrangement — where competitors collaborate on shared infrastructure — is arguably the most successful experiment in collective resource management in the history of technology.

The Development Model: Organized Chaos at Scale

The Linux kernel development process is a masterclass in scaling collaborative software development. At the apex is Linus Torvalds, who remains the project’s “benevolent dictator for life” (BDFL), personally reviewing and merging code into the mainline kernel. In February 2026, Torvalds confirmed that the next kernel release after 6.19 will be Linux 7.0 — expected in mid-April 2026 — continuing his tradition of bumping the major version number when minor versions reach the high teens. Beneath Torvalds sits a hierarchy of subsystem maintainers — approximately 1,000 individuals responsible for specific domains: networking (maintained by David Miller and Jakub Kicinski), file systems, memory management, device drivers for specific hardware families, architecture-specific code, and security subsystems.

The workflow operates through a “pull request” model predating GitHub’s popularization of the concept. Developers submit patches to subsystem maintainers via email (the kernel development process still runs primarily on the Linux Kernel Mailing List — LKML — and email-based patch review, not GitHub pull requests). Maintainers review, request revisions, and eventually merge patches into their subsystem trees. During the two-week merge window at the start of each release cycle, subsystem maintainers send pull requests to Torvalds, who merges them into the mainline. The subsequent 7-8 weeks are the “stabilization period” — only bug fixes are accepted, ensuring each release meets quality standards.

The corporate composition of kernel contributors has shifted dramatically over three decades. In the early years, individual volunteers dominated. By 2025, the Linux Foundation’s kernel development report shows that 85%+ of contributions come from developers employed by corporations. Intel and AMD together account for 17.4% of commits, while Meta and Google maintainers each handle roughly one in eight patches flowing into the kernel. The top contributors by company typically include Intel, AMD, Google, Red Hat (IBM), Meta, Microsoft, NVIDIA, Samsung, Huawei, and Qualcomm. Greg Kroah-Hartman, the stable kernel tree maintainer, logged over 6,800 commits in 2025 alone. These companies employ kernel developers full-time because their products — chips, cloud services, mobile devices, networking equipment — depend on Linux kernel support. The investment is not altruistic; it is strategic. A company that contributes drivers and features upstream avoids the cost of maintaining a permanent fork and ensures its hardware and services are first-class citizens in the Linux ecosystem.

The Economics of Open Source Infrastructure

The Linux Foundation, the nonprofit organization that hosts the Linux kernel project and hundreds of other open-source initiatives (Kubernetes, Node.js, Let’s Encrypt, RISC-V International, OpenSSF), is on track to exceed $300 million in annual revenue for the first time in 2025 — with a forecast of approximately $311 million. Its 3,000+ member organizations — including every major technology company — fund this through membership fees ranging from $5,000 (Silver) to $500,000 (Platinum) annually, supplemented by project services ($83M), training and certification ($29M), and event sponsorships ($58M). The Foundation employs Linus Torvalds and key infrastructure staff, organizes conferences, funds security initiatives, and provides legal and governance infrastructure for its hosted projects. Of that total, the Foundation spent $8.4 million specifically on the Linux kernel project in 2025.

The economic value that Linux creates dwarfs the investment in its development. A 2024 Harvard Business School study estimated that the demand-side value of all widely-used open-source software — the cost if companies had to build equivalents internally — exceeds $8.8 trillion. (The supply-side cost to recreate the code itself is a comparatively modest $4.15 billion, underscoring how much economic leverage open-source infrastructure provides.) Linux, as the foundational layer, represents a significant fraction of that figure. AWS alone generated $128.7 billion in revenue in 2025 running Linux-based infrastructure. Every Docker container runs a Linux kernel. Every Kubernetes cluster orchestrates Linux containers. The cloud computing industry — valued at approximately $900 billion in 2025, depending on the research firm — is built, quite literally, on Linux.

This creates what economists call the “free rider problem” at massive scale. Companies capture enormous value from Linux while contributing a fraction of that value back. The OpenSSF (Open Source Security Foundation), established in 2020 after the Heartbleed vulnerability exposed how critical open-source projects were maintained by exhausted volunteers, has mobilized over $150 million through its Open Source Software Security Mobilization Plan, backed by commitments from Amazon, Google, Intel, Microsoft, and others. But the broader question persists: is the current funding model — corporate memberships, foundation grants, and voluntary contributions — adequate to sustain the infrastructure that underpins the global digital economy? The Log4Shell vulnerability (December 2021), which affected a Java logging library maintained essentially by two volunteers, suggested the answer is “not yet.”

The Succession Question and Governance Challenges

Linus Torvalds turned 56 in December 2025. He shows no signs of stepping back — he remains actively involved in kernel development, patch review, and the occasional fiery mailing list critique of substandard code. In a self-deprecating post accompanying the Linux 7.0 RC1 release in February 2026, Torvalds joked that someone “more competent who isn’t afraid of numbers past the teens” would eventually take over. The comment was characteristically playful, but the project’s dependence on a single individual’s judgment, taste, and availability is a governance risk that the community has begun to address.

The kernel’s de facto succession plan involves a layer of trusted maintainers who could collectively assume Torvalds’s role. Greg Kroah-Hartman, the maintainer of the stable kernel tree and one of the most prolific kernel developers in history, is widely regarded as a potential successor. The kernel’s MAINTAINERS file — a massive document mapping every subsystem to its responsible developers — represents an institutional knowledge base that distributes authority. In practice, Torvalds’s role has already evolved from hands-on coding (he rarely writes new code himself anymore) to architectural decision-making and quality gatekeeping.

The governance challenge extends beyond succession to the cultural dynamics of a project with thousands of contributors. In 2018, Torvalds took a brief leave of absence and the kernel adopted a Code of Conduct (based on the Contributor Covenant) to address long-standing concerns about hostile communication on LKML. The transition has been largely successful — the kernel development community, while still direct and technically demanding, has become more inclusive. The Linux 6.15 release included 262 first-time contributors, suggesting that the community is not deterring new participants. However, maintainer burnout remains a systemic issue: many subsystem maintainers are responsible for reviewing hundreds of patches per release while maintaining their own employer’s contributions, and the workload is unsustainable without expanding the maintainer pool. The kernel’s 11,089 total contributors across 1,780 organizations in 2025 represent an enormous talent base, but the bottleneck is at the maintainer level, not the contributor level.

Security: The Challenge of Securing Everything

When a single piece of software runs on billions of devices, every vulnerability has planetary impact. The Linux kernel’s attack surface is vast: 40+ million lines of code, hardware drivers for thousands of devices (many contributed by hardware vendors with varying security discipline), and a networking stack that handles every protocol from TCP/IP to Bluetooth to NFS. The kernel security team, coordinated by Greg Kroah-Hartman and others, handles vulnerability reports, develops patches, and coordinates disclosure — but the scale of the challenge is immense.

Recent years have brought increased attention and resources to kernel security. The Kernel Self-Protection Project (KSPP) has been integrating security hardening features — stack protectors, address space layout randomization (KASLR), control-flow integrity (CFI), and memory safety improvements — into the mainline kernel. Google’s KernelCI project provides continuous integration testing across hundreds of hardware configurations. The Rust-for-Linux initiative, which began merging Rust language support into the kernel in 2022, represents the most ambitious attempt to address memory safety — the category of bugs (buffer overflows, use-after-free, null pointer dereferences) that accounts for approximately 70% of security vulnerabilities in C-based systems software.

The Rust story reached a decisive turning point in 2025. At the Kernel Maintainer Summit in Tokyo in December 2025, Rust was officially promoted from “experimental” to a core part of the kernel — making the kernel’s official languages C, assembly, and Rust. Greg Kroah-Hartman called the Linux 6.13 release (January 2025) “the tipping point” for Rust driver development. Dave Airlie, maintainer of the DRM (Direct Rendering Manager) subsystem for GPU drivers, stated that the DRM project was about a year away from requiring Rust and disallowing C for new drivers. Android 16 devices shipping with Linux 6.12 already include a Rust-written ashmem memory allocator in production, meaning millions of devices are running Rust kernel code today. Kroah-Hartman has reported that Rust drivers are proving safer than their C counterparts, with fewer interaction issues between Rust code and the C core than expected.

With Linux 7.0 (expected April 2026), Rust support ships as officially stable — no longer under any experimental umbrella. The practical challenge of training kernel developers in Rust and establishing Rust-specific review processes is ongoing, but the trajectory is clear. Rust-for-Linux is no longer a question of “if” but “how fast,” and it may prove to be the most consequential security improvement in the kernel’s history, gradually replacing the C code most prone to memory safety bugs with a language that prevents them by design.

Frequently Asked Questions

Sources & Further Reading

• Linux Kernel Development Report 2025 — Linux Foundation
• TOP500 Supercomputer Operating System Statistics — TOP500
• Web Server Usage Statistics — W3Techs
• The Value of Open Source Software — Harvard Business School
• Rust in Linux’s Kernel Is No Longer Experimental — DevClass
• Linux Kernel Source Code Surpasses 40 Million Lines — Linux Today
• Linux Foundation Annual Report 2025 — Linux Foundation
• Linux Foundation Expects to Break $300M in Revenue — Phoronix
• Development Statistics for the 6.15 Kernel — LWN.net
• Linus Torvalds Confirms Linux 7.0 — Phoronix
• Kernel Self-Protection Project — KSPP Wiki