Linus Torvalds: "Git proved I could be more than a one-hit wonder."

Commentary: The world rightly lauds Linus Torvalds for Linux, but Git will arguably have a bigger impact.

img-5421.jpg

Linus Torvalds (l) and Dirk Hohndel (r) at the Open Source Summit Europe 

Image: Matt Asay

Recently some neighbor kids asked me what I do for a living. "I read and write emails," I told them. They weren't very impressed.

However, they'd likely be a bit more impressed had they heard the same thing come from the mouth of Linus Torvalds, founder of the Linux operating system. In a fireside chat at the Open Source Summit Europe, Torvalds was asked how he spends his time as the kernel maintainer. "I read email," was Torvalds' reply. But not just any email. The email Torvalds answers helps to keep over 25 million lines of code humming for the hundreds of millions of Linux-powered devices worldwide. So it kind of matters if he replies.

SEE: 20 quick tips to make Linux networking easier (free PDF) (TechRepublic)

As important as those emails are for keeping Linux going, it's arguably the project for which he doesn't answer emails that will ultimately have a bigger impact on the world. 

Torvalds is keeping current with the commits

Despite his pivotal role in writing Linux, Torvalds says that he doesn't really code anymore. "I'm not a programmer," he insisted. Instead, his full-time job is to read email or, more concretely, the inbound commit messages that explain proposed changes to the Linux kernel. "Commit messages to me are almost as important as the code itself," Torvalds said. "Sometimes the code changes are so obvious that no explanation is necessary, but this is rare."

"In the end," he continued, "My job is to say no. And developers know that if they do something bad, I will say no. But in order to say no, I have to know the background. So I read email to know what's going on." 

I've written recently about the importance of commenting one's code--it's a good way to signal the "why" behind code, helping future developers to better understand why you chose a certain approach to a problem. As Jef Raskin has noted, "[T]he fundamental reason code cannot ever be self-documenting and automatic documentation generators can't create what is needed is that they can't explain why the program is being written, and the rationale for choosing this or that method. They cannot discuss the reasons certain alternative approaches were taken." 

SEE: How to build a successful developer career (free PDF) (TechRepublic)   

While Torvalds is describing something different and more important than code comments, as Dave Smith called out), the same principle applies. As a bonus, Torvalds indicated, it helps to "explain why the code does something and why some change is needed because that in turn helps the managerial side of the equation, where if you can explain your code to me, I will trust the code."

And while we rightly laud Torvalds for Linux, arguably his bigger innovation is the means developers use to collaborate on those proposed changes: Git

Torvalds is not a one-hit wonder

In an impressively candid moment of self-reflection, Torvalds said the impetus behind Git was to prove to himself that he wasn't just a "one-hit wonder." "We all have self-doubts," he suggested. "Linux was 'just' a reimplementation of Unix. Git proved I could be more than a one-hit wonder." 

Not that Torvalds really wanted to write a new source control management (SCM) system. As Torvalds stated in an interview a few years back, "I really never wanted to do source control management at all and felt that it was just about the least interesting thing in the computing world." Uninteresting and yet profoundly important. Nor did he think it would have the impact it has, and certainly not beyond Linux, as he said in this same interview: "What I find interesting is how it took over so many other projects, too. Surprisingly quickly, in the end. There is a lot of inertia in switching source control systems; just look at how long CVS and even RCS have stayed around, but at some point git just took over."

Not that Torvalds takes all (or even most) of the credit for the success of Git. "I maintained Git for six months, no more," he acknowledged this week at Open Source Summit Europe. "The real credit goes to others. I'll take credit for the design." 

Many years later, Git has completely changed the way software is developed. If nearly all software now includes open source components, no small amount of credit is due to how Git revolutionized software development. Yes, we had version control systems before Git, but none that unlocked collaboration in the same way. As Torvalds put it in that earlier interview:

I think that many others had been frustrated by all the same issues that made me hate SCM's [Source Control Management systems], and while there have been many projects that tried to fix one or two small corner cases that drove people wild, there really hadn't been anything like git that really ended up taking on the big problems head on. Even when people don't realize how important that "distributed" part was (and a lot of people were fighting it), once they figure out that it allows those easy and reliable backups, and allows people to make their own private test repositories without having to worry about the politics of having write access to some central repository, they'll never go back.

He's right. 

Whether he's taking credit or not, and whether he could have foreseen how big Git (and Linux) would be, it's impressive that two primary pillars of modern computing came from the keyboard of an understated Finn. Based on the crowd that mobbed him after the conclusion of the morning keynotes, it's clear that people are happy to give him the credit he richly deserves. But maybe, just maybe, the thing that he will ultimately be remembered most for is Git. It may not have the brand that Linux does, but it unlocks the potential for a million other Linux-like projects to grow.

Disclosure: I work for AWS, but nothing herein is directly or indirectly related to my employment there.

Also see