Linus Torvalds's lessons on software development management

If anyone knows the joys and sorrows of managing software development projects, it wocould be Linus Torvalds, creator of the world's most popular open-source software program: the Linux operating system. For more
Than 20 years, Torvalds has been directing thousands of developers
Improve the Open Source OS. He and I sat down to talk about valid tive techniques in running large-scale distributed programming teams-and the things that don't work, too.

Torvalds
Says there are two things that people very commonly get completely wrong, both at an individual developer level and at companies.

"The first thing is thinking that you can throw things out there and ask people to help," when it comes to open-source software development, he says. "That's not how it works. you make it public, and then you assume that you'll have to do all the work, and
Ask people to come up with suggestions of what you should do, not what they should do. maybe they'll start helping eventually, but you should start off with the assumption that you're going to be the one maintaining it and ready to do all the work."

Torvalds continues, "If you start off with some 'kumba-ya feeling 'where you think people from all the world are going to come together to make a better world by working together on your project, you probably won't be going very far."

"The other thing-and it's kind of related-that people seem to get wrong is to think that the code they write is what matters," says Torvalds. most software development managers have seen this one. "No, even if you wrote 100% of the code, and even if you are
The best programmer in the world and will never need any help with the project at all, the thing that really matters is the users of the Code. The Code itself is unimportant;
Project is only as useful as people actually find it ."

I'll add at this point that this isn' t just a programmer problem. I 've seen entire companies get locked into the idea that "Perfecting" the program was everything. they then neglected what the users wanted from the program, supporting the users and so on. most
Of us who 've been in the business for a while have seen this cycle play out over and over again.

Expanding on that second point, Torvalds says that's why the Linux kernel team is "so very anal about the whole 'no regression' thing, for example. breaking the user experience in order to 'fix' something is a totally broken concept; you cannot do it. if you
Break the user experience, you may feel that you have 'fixed' something in the code, but if you fixed it by breaking the user, you just violated that second point; you thought the code was more important than the user. which is not true."

Torvalds concludes, "way too other projects seem to think that the code is more important than the user, and they break things left and right, and they don't apologize for it, because they feel that they are 'fixing' the code and doing the right thing."

To that I can only add "amen !"

On the importance of development tools

I also asked Torvalds about Software Configuration Management (SCM) tools like his owngit version
Control system. He replied, "I don't think tools are all that fundamentally important ."

"Now, what is important is that there's
Good workflow for the project, and tools can certainly help with that, "said Torvalds. "But most projects don't necessarily really need tools. there's a lot of projects that simply don't have enough changes to really require any tools at all for their
Work Flow; if you only have a few hundred patches per release, you can maintain those just about any way you want, including entirely by hand ."

Linux is a different story of course. "For the kernel, we have thousands of patches flying around every release, and a release roughly every three months, and so for us the tools really are very important," he says. "But I still don't think it was all that
Big A Mistake to just do tar-bils and patches for the first few years of development; it was a much smaller project back then, and it took several years for the lack of tools to really become a problem."

Besides, "Some tools Encourage workflows
That are actively detrimental, And I think CVS [concurrent
Versions System, a version control system] For example has caused a lot of projects to have the notion of a' commit cabal, '"Torvalds continues. "I personally tend to think tar-bils and patches are actually preferable to that-if only because they make
All developers 'equal, 'and you don't get the kind of model where certain people have 'commit access,' and the rest are second-class citizens. sometimes it's better that everybody is a second class citizen than that some people have an easier time at it."

Torvalds, I shocould note, knows CVS well and has hated it for years. As he said in
Google Talk in 2007, "I hate CVs with a passion ."

Torvalds continues, "much more important than the tools is the people. The maintainers, and the mindset ."

Keeping people on track

And how do these people work together today? I asked Torvalds about the role of theLinux
Kernel mailing list (lkml) in the process. he replied, "I think Linux used to 'happen' more on lkml than it does these days. the signal-to-noise ratio and just the pure volume of lkml means that most developers simply don't have time to really read lkml-
Best they scan subject lines. as a result, these days I 'd argue that most of the real development happens within the sandbox of single developers, and then email on more of a person-to-person scale is actually how things really get done."

That said, "That doesn' t mean that lkml isn' t important; it means that lkml has become the 'public band' of all those individual email threads," Torvalds adds. "So what ends up happening is that you have maybe four or five people involved in a discussion about
Their work, but lkml stays cc 'd on the whole thing. That turns what wowould otherwise be a purely private discussion into something where others can be jump in ."

Here's how it works, "A lot of people actually don't really 'read lkml; 'they often auto-archive it, but then react to certain keywords or, more often, [To] key people being involved in the discussion."

"It also acts as a kind of archiving notion," Torvalds continues, "so that people can refer to it later, and a lot of bugs
Reports end up being found by Googling for them. if somebody raises an issue, it may well be some odd hardware problem, but if Google shows that it's been raised several times on lkml in the past, that starts to indicate that it may be obscure, but it's
Certainly not some totally isolated issue ."

"So I think lkml is really quite important, but no, it's not how we keep people on track, '" he says. "All the developers tend to be pretty self-motivating, and they all have sane ideas (well, the core ones do by definition-because that's how they became
Core developers, by showing that they had good taste and high motivation ). it's important simply because that 'public part' of the discussions are still important, even if in practice it's often a pretty small core in any participant discussion. things are
Simply different when they happen in the open, "concludes Torvalds.

On delegating-and staying sane

Once, Linux was a solo project. It now has thousands of committers and contributors. I then asked, "How much delegating do you these days? Any thoughts on how to delegate to keep
One's sanity and the workflow flowing ?"

"If there's one thing I 've ve learned, it is that you have to learn to let go and not try to control people and the Code," he says. "If you don't think somebody else can do it on their own without your oversight, you might as well give up immediately as a maintainer."

He continues, "Yes, I often get involved in small details, but it's not because I don't trust people or don't delegate. it's because some small detail ends up being brought up to me. either it's a bug (and they are almost all just silly small details that got
Overlooked), or it's just some workflow issue that bothers me (like me complaining about the developer names not showing up properly in the logs earlier today to one sub-maintainer )."

Still, says Torvalds, "those details have to be occasional details, not the kind of 'look over the shoulder of the developer to check everything does. 'I trust sub-maintainers to do the right thing 99% of the time. and then, very occasionally, I end up complaining
Loudly about something. "say, for example, on how the open-source gnome
Desktop is, or rather isn' t, moving forward.

So, there you have it. that's some of the ways Torvalds does it. and, if you think you know better, ask yourself: Have I created a world-class operating system that runs
Most supercomputers, stock-exchanges, and websites like Google? If your answer's no, I 'd re-read his answers and take a long hard think about how you 've been managing your own projects.