Inspired by Work

Most Linux projects have a lead -- a benevolent dictator. The job of the lead is to act as the clearinghouse for changes to the code that might increase complexity. The lead must decide which new code gets incorporated into the source file, which bug fixes are the most elegant, and so on. Anyone who wants it has access to the code, but only one person can change the code.

I am a project lead for a piece of software called fetchmail. I have a total of 685 people on my two core mailing lists. I haven't met very many of these people, but I interact with all of them through email. There are a few different modes of interaction: Somebody might notice a bug, develop a patch, and send it to me. If it's a good fit, I incorporate it. That's the simplest and the most common mode of interaction. At the other end of the spectrum, we sometimes have very involved discussions about issues of architecture and design -- email debates that can go on for a long time. One of the project lead's jobs is to enable those discussions and then bring them to closure.

Different communities organize things a bit differently. Linux embraces the benevolent-dictator model that I just described. The Perl community has a rotating cast of benevolent dictators. At any one time, only one person has the so-called patch pumpkin, a mythical token that lets you change the source code. Typically, Larry Wall has the patch pumpkin, but he passes it to other people from time to time. You are a person of consequence in the Perl community if you are a present or former pumpkin holder. The Apache community has a committee of key developers who vote on major changes to the source code.

We've talked about the virtues of working this way. What's hard about this way of working?

It's a milieu that challenges you to operate at the highest levels of honesty and commitment, because if you don't, people won't choose to work with you. It can be intellectually and emotionally exhausting. It can eat up your life if you let it. Lots of really bright people are out there, all competing with you -- even if they're competing for attention, rather than for money. So if you're not operating at your peak, or you're not operating from a position of integrity, then you're not going to succeed.

It's also harder to persuade people to do boring but necessary work. Fetchmail has hundreds of people working on it. But all those people are volunteers; they focus on what they find most interesting. Of course, not all parts of the software-development process are equally compelling. So my only option when it comes to doing boring work is either to do it myself, which isn't very much fun, or to find people who don't consider the work boring. I can't pay -- or even coerce -- anyone to do something that they don't want to do. I wouldn't change that, but it creates a challenge sometimes.

Lately, you've been speaking at major conferences and visiting some big companies. How are established business leaders reacting to the open-source phenomenon?

I'm seeing both more intelligence and more inertia than I thought I would. The executives I've spent time with inside some of the big companies are "getting" the idea more quickly than I expected them to. I thought the real battle would be for them to get comfortable with the concepts, and, once they did, they'd be quick to act. But, in fact, just the opposite has been true.

There have been a few interesting examples of big companies getting serious about the open-source route. A few years ago, two programmers at Cisco got the job of writing a print-spooling system for use over Cisco's global corporate network. That challenge was far from trivial. The goal was to create a system that would let someone sitting in, say, San Jose print out a document on a printer in Bombay. The system also had to make sure that in the event of an out-of-paper or low-toner condition, the document would be printed by the next-best printer that was available. The team came up with a clever set of modifications to the standard Unix print-spooler software plus some wrapper scripts that did the job.

Then they realized that they, and Cisco, had a problem. The two programmers who had worked on that project were the ones who wrote, understood, and cared about the code. They knew that they were not going to work at Cisco forever. (These days, who works at any company forever?) Eventually, they would leave and their code would rot; it wouldn't be upgraded to reflect new conditions. No developers like to see that happen to their work. So the programmers urged Cisco to release their application as open-source software. Their argument: By encouraging a community of codevelopers and users, Cisco would be seeding a pool of people who would keep upgrading the software, at no additional cost.