by Linus Torvalds, as told to Steven Vaughan-Nichols

Five Things Linus Torvalds Has Learned About Managing Software Projects

Aug 04, 20084 mins
DeveloperOpen SourceProject Management Tools

Linus Torvalds explains how he keeps the people and software on-track, with the software quality Linux demands.

Linus Torvalds needs no introduction in operating systems or open-source circles. He’s the creator, muse and chief developer of the Linux operating system. Torvalds started Linux while he was in college in 1991. Today, Linux is the foundation of multibillion-dollar companies including Oracle, Novell and Red Hat. It’s used on computers from small office servers and home office desktops to the New York Stock Exchange.

Torvalds does this by managing a self-selected team of over a thousand developers around the world, united only by a mailing list (the Linux Kernel Mailing List) and a source-code management system (Git). Torvalds herds Linux programming cats from multiple major companies, such as IBM, Intel and SGI, as well as the occasional stereotypical developer programming in a basement.

How does he do it?

Find people you can trust.

My personal guiding principle is that I try very hard to find people I can trust, and then try to get out of their way as much as possible. I don’t mean totally unconditional trust; but on the other hand, once somebody maintains something, he really should be able to make all the normal daily decisions.

Be trustworthy yourself.

I, in turn, try to make myself as trustworthy as I can. And in this context, “trustworthy” is a lot about not surprising people. In other words, it’s not some kind of fuzzy, feel-good Kumbaya trust where we all love each other; it’s more about the fact that people know my opinions and where I stand on things. While they may not necessarily like or agree with them all, at least they can trust me to be reliable.

Be honest—sometimes painfully honest.

Part of that, by the way, is not feeling shy about saying impolite things or showing some emotion. So I’d rather flame people for doing stupid things and call them stupid, rather than try to be too polite to the point where people didn’t understand how strongly I felt about something.

There’s the saying, “On the Internet, nobody can hear you being subtle.” Okay, so the saying is really, “On the Internet, nobody knows you’re a dog” or any number of other things, but my saying is the “hear you being subtle” one. That’s because, to be blunt, subtlety or sarcasm simply doesn’t get through, or it may not translate to other cultures.

You also have to let the others get their say in.

Part of that, of course, is ending up having to sometimes say, “I was wrong.” That can be hard. But I make it easier for me by often writing my flames something along the lines of: “You’re a completely incompetent idiot, and I’m not going to apply this patch because it’s obviously broken and is a total piece of sh*t. And here’s why…” But then at the end I’ll include:

“And hey, maybe I’m just being a d*ck, and you can prove me right, so please explain to me why you did that horrible thing. Please? Hmm?”

This gives people the ability to tell me I’m being a d*ckhead and I was wrong, and that all the reasons I called them idiots were actually bogus.

Of course, it doesn’t happen all that often. Or maybe it does, and people are just too polite to point it out in public. Not that I’ve met all that many polite people in kernel development, but that’s probably because I’ve scared them all away.

A combination of bluntness and honesty leads to the best code ending up in Linux.

Anyway, the theory goes that it’s better that people know how you feel than then to be surprised by it later when you simply refuse to take their code. Or—even worse—if you end up taking crap code because you feel it’s too hard to call it crap and to tell them why you refuse.

Additonal Note: When Torvalds speaks, people listen.

What Torvalds didn’t mention is that many other open-source projects have floundered when they try to get everyone working in the same direction. While Torvalds’ methods may sound harsh, they have also worked for more than a decade.

One reason this is so is because when Torvalds is wrong, he’s willing to admit it. In other projects (not just software development projects), a refusal to ever admit fault decreases confidence in a leader and lowers morale.

Perhaps the most important reason that Torvalds’ methods work is that he commands enormous respect in programming circles. When Torvalds flames someone, developers listen to his specific complaints. They don’t dismiss his comments as mere insults or evidence that Torvalds really doesn’t understand their work. In other development circles, programmers might walk out; in Linux, the best developers stick it out, because they know that Torvalds really does know what he’s talking about.—sjvn