This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
We don't all need to be Linus
An excellent paper on contributing to Linux, recently published by Jonathan Corbet (thanks to Stormy Peters for the link) provides a window into how the Linux community works. But it also provides a window into some of the practices you might not need to follow, if your project isn’t (yet?) "6 million lines of code, well over 1000 active contributors, and [sometimes] approaching 1000 changes per day." Probably the most important lesson for your own work is the scalability of the process Linus has evolved: you can use as little or as much as you find you need, once you’ve read the process document with an eye open to the key scaling factors—but there’s every chance you need less of this than does Linux, and any thought you need more is probably wrong.
The key is modularity. There are really two kinds of modularity in the Linux world, though they can interact in ways that make the lines a bit fuzzy. The first is that the vast content of the Linux kernel is in fact extraordinarily modular. The second is that the vast community of contributors is also extremely modular. You can see those "interactions" bubbling up already, can’t you? Both of these modularities come from a mix of the essential nature of the task at hand, and very careful engineering, both software and social, as the kernel has evolved.
As to the code modularity: it arises "naturally" because a multitasking, multiuser operating system has so many tasks to do that you really want to be independent: you don’t want the network, while it’s sucking over your email, to care whether you’re also typing in an editor; you don’t want the keyboard driver to behave differently when you’re typing into email than it does when you’re typing into code. The process allows great liberty for change within such boundaries while imposing some very strong prohibitions against crossing the boundaries. This sort of modularity is "Software Engineering 101," of course, but few projects have quite such a modularity opportunity as a kernel; everyone should be inspired by the success of the Linux community in protecting that resource, but you may have to think very hard about whether your own task offers so modular a base, and how you can best preserve what "modularity capital" you begin with.
Which brings us to the other modularity, the "people modularity." Where Linux code modularity is merely basic engineering (though, perhaps, to an unusual degree), the modularity of the developer community seems to be something Linus himself invented. The key is the phrase "subsystem maintainer." Although "there is exactly one person who can merge patches into the mainline kernel repository: Linus Torvalds," much of what he merges into the mainline he accepts because he trusts the "subsystem maintainer" who gave it to him. Sometimes there’s a "sub-subsystem maintainer" involed as well. Herein lies the scalability of the people-process: this trust can be delegated really arbitrarily deeply.
But note that even on so large a project as Linux, the three-level trust (Linus to maintainer to developer) accounts for the vast majority of work. If something as vast as Linux mostly gets by on a three-level trust hierarchy, there’s a pretty darned good chance that your project can get by on that or less. If you find yourself tempted to something more complex, you’re probably doing something wrong. Look to improving the "code modularity" part before going crazy on the "people modularity" bit.