The Kernel as a Model: Why Open Source Works

The Linux Foundation recently posted a video interview with Linus Torvalds that took place at September's Linux Kernel Summit. Torvalds, the man behind the Linux kernel, and the project's chief coordinator, is always interesting to hear and the ten minute video is well worth watching.

Torvalds' insights range from disarmingly truthful (email is a fine method for communicating, but the Summit is needed because it's good to see people) to keenly introspective (kernel and userland issues are rough, because no one sees things in quite the same terms).

Listening to Torvalds, I couldn't help but feel that the terms "kernel" and "userland tools" could be swapped out for any other two different (but interconnected) open source components -- X and GTK (or Qt), or even an application and its non-developer userbase. Essentially, what he was saying applies not only to the kernel, its development, or those attending the conference. It applies to open source software as a whole.

He describes beautifully why open source works. It isn't the usual "many eyes viewing the code" idea (as true as that also may be). It is a very honest "we work in the areas we're good at, you work in the ones you're good with, and then we see how these pieces make each other more useful."

Torvalds, I think, hit squarely when he said that quality comes from people taking pride in the code they write and (this is equally important) getting involved and taking things personally. A kernel developer who takes pride in writing code dealing with system calls would not feel terribly confident, happy or content writing a front end to an application, and vice versa. With no pride, no feeling of accomplishment or ownership of at least some part of the project -- any project -- it's not merely that the output is "just software." It's a chore. It's a job. And while many kernel developers are paid, it seems clear, at least hearing Torvalds, that most don't see those jobs as a chore.

Contributing to an application makes it your project on the one hand, and opening the code makes it everybody's project on the other. I think Torvalds is right when he talks about quality. Calling tech support for help with an issue in a proprietary application may solve the problem -- or just leave you with a glitching piece of software. Filing a bug report, and talking to the developers to reach a conclusion gets everyone actively involved in the fix.

Good work, and personal responsibility is why it works, regardless of any one person's central area of focus.