August 25, 2026 marks 35 years since Linus Torvalds posted his plans for a new OS to Usenet. That day was not when he released any code—Torvalds simply asked Minix users what features they wanted and described a system he was already working on. The first version, Linux 0.01, wasn't uploaded until September 17. In the 35 years since, one person's experiment has grown into a project where thousands of developers update more than 70,000 source files.
Nine days before this anniversary, the latest mainline release, Linux 7.2, was published. Linux has not preserved a finished product; it has continuously absorbed changes from developers and shifting hardware. What sustained it for so long was not fidelity to an original design, but a system for verifying quality even as both the design and the people responsible for it kept changing.
When we say "Linux" here, we mean primarily the kernel—the core of the OS that manages hardware and resources. The Linux distributions most people actually use include other software as well, such as shells, libraries, and desktop environments. To compare scale and development practices across 35 years, we need to align on this boundary first.
August 25 Was an Announcement; the First Code Came on September 17
In his August 25, 1991 post, Torvalds—then a student at the University of Helsinki—revealed that he was building a free OS for 386/486 AT-compatible machines. He had been working on it since April and had reached the point where Bash 1.08 and GCC 1.40 would run. But he described it as "just a hobby," one that wouldn't become "big and professional like gnu."
The post was not a preview of a success story. Linux contained no Minix code and included a multithreaded filesystem, but it depended heavily on the 386's task-switching mechanism. Torvalds wrote plainly that it wasn't portable and probably never would support anything beyond the AT hard disks he had on hand.
Version 0.01, released September 17, made those limitations even more concrete. According to the official release notes, it had only been tested on two machines. Supported devices were limited to hard disks and displays, plus some keyboard and serial-line functionality; mount and umount weren't even implemented yet. The Finnish keyboard layout was hard-coded directly into the source. You could read the source and compile it, but you still needed Minix to actually boot the system.
The tight coupling to the 386 wasn't accidental. Version 0.01 used that CPU's paging and segmentation directly, skipped Minix's message-passing model, and handled system calls in a way that resembled ordinary function calls. The goal wasn't portability—it was getting something running quickly on the machine in front of him. That pragmatic choice pushed early development forward, but the work of porting to other CPUs was left to later developers.
In short, August 25 was the day Torvalds started gathering people, and September 17 was the day he started handing out code. Linux effectively has two "birthdays," and the significance of the 35th anniversary lies not in the first version being complete, but in the fact that it was opened to the world while still unfinished.
From 9,877 Lines to 39,815,032 Lines
XenoSpectrum tallied the official 0.01 and 7.2 tarballs preserved by kernel.org using a consistent method. We counted C and header files, and also included assembly, Rust, and Device Tree sources. The table below compares physical line counts, including comments and blank lines.
| Item | Linux 0.01 | Linux 7.2 |
|---|---|---|
| Release date | September 17, 1991 | August 16, 2026 |
| Source-type files | 83 | 71,934 |
| Physical lines (source-type) | 9,877 | 39,815,032 |
| Target architectures | Tightly coupled to 386 AT machines | 21 architecture families under arch/ |
The physical line count for source-type files in 7.2 is 39,815,032—roughly 4,031 times that of 0.01. The file count grew roughly 867-fold. The kernel that was once described as "not portable" now handles x86 alongside Arm, RISC-V, PowerPC, s390, and others, each in its own directory within the current source tree. This isn't the result of preserving the original constraints—it's the result of generations of developers trading them out.
Looking at all files rather than just source-type ones, 0.01 had 88 files versus 94,744 in 7.2. We narrowed the table to source-type files because comparing total line counts—which would include documentation and build configuration—would make it even less clear what exactly is being compared. Even so, coding languages and conventions differ across eras. The roughly 4,031-fold figure reflects a difference in scale viewed through the same lens, not a difference in development productivity.
That said, line count is not a measure of quality or adoption. Version 7.2 layers on new architectures and drivers, but also tests, documentation, and code to maintain compatibility. The roughly 4,000-fold figure indicates how much surface area now needs to be maintained. The question of who reads all that added code and decides which changes to accept has grown just as heavy.
Indeed, the official ChangeLog-7.2 lists 17,833 commit headers between 7.1 and 7.2—a volume that exceeds the roughly 13,000 commits the kernel's own development documentation cites as a typical example. The 35th anniversary is both a moment for looking back and a checkpoint in an active project that keeps absorbing a massive volume of changes.
Still, mainline 7.2 is not a finished product shipped straight to end-user devices. Distributions and device makers instead choose stable or long-term-support releases and combine the fixes they need. Keeping mainline's rapid pace of updates separate from the long-term compatibility that products require is itself one reason Linux has been able to spread across such a wide range of uses.
Removing the Ban on Paid Distribution and Delegating a Single Person's Authority
The distribution terms for 0.01 were not what they are today. It required that the complete source be made available and that copyright notices remain intact, while banning distribution for a fee. In the release notes for 0.12, Torvalds lifted that ban and announced a move toward compatibility with the GNU copyleft. The COPYING file in 7.2 states that the entire Linux kernel is provided under GPL-2.0-only together with the Linux-syscall-note.
Allowing paid distribution removed one obstacle to redistributing products that include Linux for a fee. But this change did not by itself generate upstream contributions from companies. Developers at companies participate in the same public review process and deliver improvements into mainline. What made that possible was the distributed development process described next.
The development process itself also moved away from decisions made by a single person. According to official documentation, roughly 2,000 developers are now involved over the course of a year. Patches are reviewed on the relevant mailing list, selected by subsystem maintainers, and passed up through higher-level maintainers before reaching mainline. Rather than sending everything directly to Torvalds, trust is passed along in stages.
This delegation also operates within a time frame. After the roughly two-week merge window for new features closes, successive release candidates work to reduce regressions. Once a stable release is published, the stable team backports critical fixes. The project has been able to maintain its release cadence even as it has grown, because development, triage, and stabilization are run as separate jobs.
Can Review Keep Pace for the Next 35 Years?
Linux 0.01 was tightly coupled to the 386 in order to run quickly, and it supported only a narrow set of devices. Version 7.2 spans 21 architecture families and absorbs more than 17,000 changes in a single development cycle. What connects the former to the latter isn't a design that was correct from the start—it's a system that lets anyone who finds an error or a limitation fix it in the open.
At the same time, distributing the work doesn't make the review burden disappear. New files demand specialized knowledge from whoever is responsible for them, and keeping old code around requires the experience to spot regressions. Now that more people write code than ever, what matters is whether the project can keep making decisions about which changes to accept, and keep passing knowledge from longtime maintainers to the next generation.
The post from 35 years ago was a short call asking users what features they wanted. Whether Linux can keep up this pace of updates for the next 35 years will be measured by whether it can secure enough people to read changes numbering in the tens of thousands, and enough maintainers willing to take on that responsibility. When looking at Linux 7.2 and beyond, it's worth checking not just the commit count, but whether the systems for review and handover are still holding up.