Talk is cheap. Show me the code.#

This phrase isn’t just a slogan. It’s the operating system of Linux development. No design documents that never get implemented. No meetings that could have been an email. No “we’re looking into it.” If you have an idea, you write the patch. If the patch is good, it gets merged. If it’s not, you fix it or you don’t. No politics. No bureaucracy. Just code.

Torvalds has seen corporate development: months of planning, endless reviews, and tasks that should take a day stretching into quarters. He built the opposite. Linux moves fast because contributors demonstrate their work. The kernel doesn’t run on promises. It runs on patches that compile, boot, and don’t break existing systems.

The Bcachefs lesson: Discipline over convenience#

The Bcachefs removal wasn’t personal. It was structural. The kernel has strict rules: during release candidates, only critical fixes. No new features. No “just this once.” Overstreet pushed substantive changes for data-recovery purposes. Torvalds rejected them. The exchange escalated. Overstreet’s response crossed a line. Torvalds’s response was to remove the entire subsystem and mark it as externally maintained (DKMS).

Why? Because the rules exist for a reason. The kernel runs on phones, servers, embedded devices, supercomputers. A single bad merge can cause data loss, security holes, or system-wide outages. The release discipline exists to protect users, not to please maintainers. If one maintainer gets special treatment, the whole system collapses. Torvalds would rather lose a filesystem than lose the trust in the process.

Git: Born from kernel pain#

Before Git, Linux used BitKeeper. A proprietary tool. A single point of failure. When the relationship soured, Torvalds didn’t hire a committee to “evaluate alternatives.” He wrote Git in a weekend. A distributed version control system that was fast, simple, and didn’t need a central server. Today, Git powers GitHub, GitLab, and virtually every software project on the planet.

The lesson? When the tool doesn’t fit, build a better one. Don’t wait for permission. Don’t form a task force. Just solve the problem.

The Torvalds paradox#

He’s been criticized for his tone. Harsh. Direct. Sometimes offensive. He’s also been praised for taking a step back, reflecting, and apologizing when he crossed the line. The paradox is that his intensity and his willingness to admit mistakes come from the same place: he cares about the code. Not about being liked. Not about being diplomatic. About shipping something that works.

For Torvalds, the kernel is a shared responsibility. Thousands of maintainers, millions of lines, billions of users. The only way it works is through clear rules, consistent enforcement, and a culture where merit is the only currency. Your patch either improves the system or it doesn’t. Your argument either holds up or it doesn’t. No amount of lobbying, seniority, or “we’ve always done it this way” changes that.

Rules#

• Code is the contract. If you can’t show it, it doesn’t exist.
• Process exists to protect users. Breaking it “just this once” is how systems fail.
• Trust is earned. Maintainers who violate the rules lose the privilege.
• Build when you need to. Don’t wait for the perfect tool. Create it.
• Meritocracy scales. Linux proves that a strict, code-first culture can run the world’s most critical software.

In short: Linus Torvalds is the anti-CEO. No quarterly reports. No stakeholder presentations. No “we’re pivoting.” Just code, discipline, and a refusal to compromise on what matters. The kernel runs the world because he runs the kernel with the same rigor he demands from everyone else.