Open source ideas in the organization

Linux grows. Can it become mainstream? IBM seems to think so with it’s The Future Is Open ad (Mac users, use IE to open the Quicktime clip).

Marketing hype aside, Linux is the best example of the open source movement. Say whatever you will, but what’s happening with Linux is pretty incredible. Microsoft has no idea how to tackle it. Who do they kill? It’s mostly a corporate tool right now but why couldn’t it eventually go consumer. But that’s not what I’m musing about today.

I just finished an article in Wired about Linus Torvalds which made me think whether there’s any learnings from the open source movement which could be applied to modern day software development practices.

Almost from the beginning, Torvalds has surrounded himself with a circle of deputies he calls “maintainers.” These are programmers whose contributions have impressed him in a particular category – networking, say, or file system management – so that now they contribute code as well as screen the contributions of others that fall into their area of expertise.

“Nobody gets declared into any of these positions,” explains Alan Cox, who until this summer was responsible for those layers of the operating system that communicate with disk drives. Instead, Torvalds will simply start relying on that person to help him weigh the merits of others’ work; suddenly the programmer finds himself occupying an exalted role.

Today, Torvalds has a dozen maintainers who help him manage upcoming versions of Linux. According to Cox, Torvalds tends to have a different relationship with each one. Some he’s collaborated with for many years and trusts implicitly. Others he reviews more closely because “perhaps he doesn’t trust their design decisions or some of their coding,” writes Cox in an email. “We all have our weaknesses.” That’s one of the great advantages of the open source model, Cox adds: constant feedback and peer review.

Seems as though Torvalds is the big man on campus, so to speak. That wasn’t a surprise to me. The dozen or so chief architects is what I didn’t hear about. To my knowledge, this sort of setup in a software development company is definitely not standard. There’s usually one smarty pants [insert position title here] that pretty much inflicts everyone else in the company with their benevolent power.

This geographically dispersed group meets at least once a year to talk about its goals for the operating system. “Linus sets a philosophical direction about how he likes the code to be,” says Andrew Morton, who has been working on core components of Linux since 2000. “The rest of us pretty much follow his lead.” Torvalds has final say over their decisions, but it’s extremely rare for him to overrule any of them.

In a way, Torvalds is less a ruler (or a hood ornament, for that matter) than an ambassador, roaming his virtual world and exerting his influence to prevent technical fights from devolving into sectarian battles.

The notion of a chief software architect surrounded by a group of leads who really own their areas, is a pretty interesting structural concept to me. Seems like the winning idea here is that those leads have control over their own destiny but still need to answer to someone who the overall owner of the vision.

But how to guard against poor software engineering? That’s where the notion of surviving rigorous peer review comes into play. Here’s a faky-poo example:

‘So, you say you’re the networking lead for Linux? Fancy. But your proposal sucks. Here’s why and everyone in the Linux networking community agrees with me.’

At least that’s how I imagine things working in Linux development. If true, boy the common folk in the Linux community really do have a lot of power – – if they want to take it on.

Maybe I’m naive, but I think this sort of structure could work great in software development companies. That is, only decisions that survive the constant feedback and review from all employees should be the ones that go forward. I’ve always believed that superior products come from collaboration. How’s this for a general take away:

To increase shareholder wealth in software development, increase collaboration.

Collaboration, transparency, peer review. Great open source concepts that (I think) should only make any software development org better.