Fast Company

Inspired by Work

What's most intriguing about "open-source" software isn't what it does -- it's how it gets created. Eric S. Raymond, open-source evangelist, explains why and how these programmers do their work -- and what that means for the rest of us.

Most of the gurus who describe the changing nature of work agree on some basic points: People do their best work when they're motivated by a sense of purpose. More and more work is becoming teamwork, and small, committed teams tend to do the best work. In a world of email, Web pages, and instant messaging, it's never been easier to work closely with people you've never met and who live in places you've never visited. Put simply, we are developing some radically new answers to some of the most fundamental issues about work: why people work, how they work, and what they expect from their work.

Eric S. Raymond, 41, has been thinking differently about work -- and working differently -- for the past 15 years. He is a provocative writer, an engaging speaker, and an accomplished hacker. Most of all, he's an influential evangelist for perhaps the most important new phenomenon in software. Raymond is a visible and vocal advocate of open-source software -- a radically different approach to software development that has produced, most famously, the Linux operating system, the Apache Web server, and the Perl scripting language.

What distinguishes open-source programs from other computer applications is that the core technology -- the underlying source code -- is totally visible and freely available to anyone who wants it. There are no patents, no trade secrets, no intellectual-property protections whatsoever. That's because no one person or company "owns" the software. A global, volunteer army of programmers create the software. These people work hard to fix bugs and develop new features mainly because they want to.

That may sound weird -- but it works. The Linux operating system had some 12 million users at the end of 1998, and Raymond estimates that there are about 750,000 developers scattered around the world. Linus Torvalds, now 29, who created Linux back when he was a college student in his native Finland, has become the technology world's latest celebrity geek. Meanwhile, Apache has the market-share lead in Web-server software, running on roughly 60% of the world's Web sites. And where users go, IPOs usually follow. Red Hat Software Inc., the best-known entrant in a growing field of companies working to commercialize Linux, recently went public -- and achieved a stunning market value of nearly $5 billion.

The rise of open-source development surprised many of the technology world's smartest leaders. But it didn't surprise Eric Raymond. He's been participating in the movement for years. (He actually runs an open-source project called fetchmail.) He's also been writing a series of influential white papers that explain how open-source programmers do their work. His first paper, "The Cathedral and the Bazaar," is legendary for its radical arguments and far-reaching influence. He has since written two sequels, "Homesteading the Noosphere" and "The Magic Cauldron."

His message? "People do their best work," he says, "when they are passionately engaged in what they're doing." In an interview with Fast Company, Raymond explains what the rise of the open-source community means for the rest of us -- what it says, not just about the future of software, but about the future of work.

Pretend you're addressing an audience of 500 human-resources professionals, most of whom have never heard of Linux or Apache. What can they learn from the open-source phenomenon?

There's one lesson that's really obvious: You cannot motivate the best people with money. Money is just a way to keep score. The best people in any field are motivated by passion. That becomes more true the higher the skill level gets.

In other words, enjoyment predicts efficiency. When are programmers happy? They're happy when they're not underutilized -- when they're not bored -- and also when they're not overburdened with inappropriate specifications or meaningless bureaucracies. In other words, programmers are happiest when they're working efficiently. This is a general preference in creative work. People are happiest when they're the most productive. People enjoy tasks, especially creative tasks, when the tasks are in the optimal-challenge zone: not too hard and not too easy. To some extent, that has always been true. But it becomes even more true as work becomes more about brains and creativity.

The flip side is that when people are frustrated with their work environments -- when they don't trust the institutions they work for -- it is virtually impossible for them to do great work. So you can ask the open-source community, "Why are so many people willing to devote themselves to do work for which few of them get paid?" You can also look at traditional companies and ask, "Why do even top executives hang 'Dilbert' cartoons on their office doors?" There's nothing funny about the popularity of "Dilbert." Companies should take that more seriously than they seem to.

Beyond pursuing a technical passion, why are people willing to work on open-source software?

There are lots of motivations. One is what I call "going for the glory." The open-source world is fiercely competitive. People like being part of a community in which they compete for their peers' esteem. People want to believe that they're working -- and competing -- with the best people in their field. I routinely deal with people who are the best programmers in the world. If you're working for a company, you might measure yourself against a few hundred colleagues. If you're working on a piece of open-source code, you might measure yourself against thousands of people all over the world.

We do keep score in the open-source world. It's just that more people focus on earning the esteem of their peers than on getting a bigger office. But even in an "esteem culture," people need to keep track of who's doing good work and who isn't. Our scoreboard is the "credit list" or the "history file" that's attached to every open-source project. If you do something important to advance a piece of code, that goes on the record and becomes part of the project's history for all time. If you see somebody's name on several credit lists, then you know that person is doing lots of good work.

It's an old idea, really. People who study primate societies make a distinction between two kinds of cultural interactions, agonic and hedonic. In agonic societies, you gain status by asserting dominance over others. In hedonic societies, you gain status by drawing attention to yourself. Open source is a hedonic culture.

If open-source programmers compete for attention, what impact does that have on the way they work?

It's difficult to convince great people to pay attention to you if you don't have a great reputation. To build a development community, you need to attract people by interesting them in what you're doing. You also need to keep them happy about the work that they're doing. Technical sizzle will go a long way toward accomplishing this. But your personality and that of your project matters too.

It's no coincidence that Linus Torvalds is a nice guy who makes people want to help him. It's no coincidence that I'm an extrovert who likes to "work the crowd." For example, one thing that everyone in this community knows about me is that I like firearms. In fact, at Linux conferences, I run an event called "Geeks with Guns." I teach people how to shoot. I do it because I love it, but it gives me a reputation as a somewhat colorful character.

I do need to make one important point: Don't confuse the idea of free software with the idea that it must be created by volunteer labor. Increasingly, open-source developers are getting tangible rewards for the reputations they've established. As venture capital pours into open-source software and as Linux-based companies get started, companies are competing to hire stars. In our world, it's easy to find the stars: Their names are in the projects' credits.

One harbinger of this trend was when O'Reilly & Associates, the leading publisher of books and manuals about open-source software, hired Larry Wall, the creator of Perl, and said to him, "Okay, you're on our payroll, and you get to be 'Mr. Perl' now." There was a pragmatic reason for O'Reilly to do that: When the Perl community flourishes, [CEO] Tim O'Reilly sells more books. But there was a passionate reason too: Tim O'Reilly really believes in Perl. He thinks it's cool. So he has come up with a business rationale to do what he really wants to do, which, in this case, is to support the continued development of Perl. I think that's where much of the entrepreneurial world is going. People are developing business reasons to do the stuff that gives them pleasure. Over time, I expect that more and more people will be paid to work on open-source projects.

For now, though, most open-source work is still volunteer labor. Isn't there still an assumption among the business establishment that if money is not involved, a product can't be rigorous?

If there is, it's a bad assumption. I certainly care about a world in which people do meaningful work. But the real point of the exercise is to develop the best software possible. And in most of the ways that matter, the open-source model is more disciplined and more rigorous than the traditional approach to creating software. The open-source model gets you better software.

One of the core practices used in open-source software is peer review: Because everyone can see the code, everyone can see your work. One obvious benefit of peer review is that mistakes get caught sooner. I call this Linus's Law, after Linus Torvalds: "With enough eyeballs, all bugs are shallow." If literally thousands of people are accessing a piece of code, each one eagerly looking for a nasty bug to fix, it's no surprise that mistakes get caught quickly.

Peer review also prevents fewer mistakes from being made in the first place. It changes how people approach their work. It changes the level of care that they take. If you know that thousands of people will be scrutinizing your work and that the errors you make will almost certainly be spotted, and if you care about your reputation, then you take great pains to create error-free work. That is different from the way people work in closed systems -- the way most companies function. Those people usually spend much of their time shifting blame for the errors that they make.

Here's a small example that may be surprising: The documentation for open-source software (the equivalent of user manuals and the like) is often much more effective -- much more helpful -- than the massive volumes that accompany closed commercial software. Open-source manuals may contain some misspellings and grammatical errors, but the information in these documents -- their capacity to zero in on the things that people really need to know -- is just amazing. Why? Because the people who created them really care about good documentation. They volunteered to do it. Also, if the documentation is lousy, the people who created it would get hammered. In the open-source world, bullshit is rarely tolerated.

That's one big reason why the Internet is so reliable. The four most critical pieces of infrastructure that make the Internet work are bind [Berkeley Internet Name Domain], Perl, sendmail, and Apache. Each one is open source and each is extremely reliable, because for years people have been constantly banging on the code, looking at the source, seeing what breaks, and fixing it. So you should not mistake expensive bureaucracy or corporate conventions for rigor. In this case, less "process" leads to better outcomes.

That's quite a flip on conventional wisdom. Are there others?

There is another reason that goes to the heart of how you create value in today's economy. The open-source movement clearly demonstrates that the more smart people you can persuade to work on a problem, the more likely it is that the problem will get solved. Writing code may be a solitary activity, but all the really great hacks have come from harnessing the attention and brainpower of entire communities. Developers who use only their own brainpower in a closed project are going to fall behind developers who know how to create an open, evolutionary context in which hundreds or thousands of people are spotting bugs and making improvements.

What goes for hackers also goes for companies. In the 21st century, one of the ways that companies are going to compete -- and this goes beyond software -- is to compete for the attention of outside brainpower. Remember, no matter how many smart people work for any one company, 99% of the smart people in the world will never work for that company. So how does the company persuade smart people, whom the CEO or the head of hr has never met, to volunteer their energy, their intelligence, and a few hours of their time to help the company perfect a product or improve an idea? How do you get the smartest collaborators, rather than just the smartest employees?

This idea tends to invert the conventional notion of a value proposition. In an indirect but powerful way, the value of a company in the future will be tied to how much value it can offer people on the outside, rather than how much value it can extract from people on the outside. In other words, can companies make it fun, interesting, challenging, and rewarding for people who are not their employees to contribute their time and ideas? Companies that successfully attract outside brainpower will absolutely eat the lunch of companies that don't.

So far, we've been talking about why people work. Let's discuss how people work. How do volunteers who are scattered all over the world, many of whom have never met one another, write code that is more reliable than most closed commercial software?

One of the most powerful features of the open-source model is its capacity to hold down global complexity. The structure of work and communication in the hacker community is decentralized and distributed. Also, many different groups of people are working on many different software modules, each of which is relatively small and simple, and all of which have to be compatible in the end. That's a good way to write software.

Work in the open-source community is organized by projects. With Linux, I'd estimate that at least 4,000 different projects are going on at any one time. The people who work on them are all volunteers. But the authority structure is clear. Authority follows responsibility. If you're willing to take responsibility, you have the authority to make decisions.

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.

And that's what Cisco did. The company saw it as a way to hedge risk -- in this case, the risk associated with the loss of these two developers. Cisco knew that this software would likely remain alive for a long time, because its user base and developer base are now spread across multiple companies. It's like diversifying a stock portfolio.

Open-source strategies also help you hedge against an even more important risk: epistemic risk, which is the risk that you don't know the right things and that you don't have the correct representation of the problem or the opportunity in the first place. As technology gets more complex and customers get smarter, predicting what people will actually do with the stuff you create -- or whether you're creating stuff that people want -- gets harder and harder. Markets become less, not more, predictable. So the greater the diversity of your developer population, the greater the diversity of the ideas and options that are available to you. Adopting an open-source strategy and inviting lots of brains to think along with you, will increase the chances that you'll develop features that customers want to use.

Much to my amazement, one of the companies that has taken the most aggressive lead in this area is IBM. I've been around the hacker culture long enough to remember the time before Microsoft, when IBM was the great enemy. But now it's a major backer of Apache. It's got an internal unit called AlphaWorks, whose charter includes a mandate to find stuff inside IBM that can be open-sourced and to make that happen. Why would IBM embrace these ideas? Because it decided years back to reinvent itself as a services company -- and it's been pursuing that strategy ever since. IBM understands that its only real advantage is the brains and energy of its people. When it comes to intellectual property, what matters today is the intellectual part, not the property part. A world in which there are no secrets is a world in which companies can't compete on the basis of secrets, but on the basis of service: Do you have the best people solving your customers' toughest problems?

William C. Taylor (wtaylor@fastcompany.com) is a founding editor of Fast Company. Contact Eric S. Raymond by email (esr@thyrsus.com), or visit his Web site (www.tuxedo.org/~esr), which includes his white papers, as well as resources on and links to the open-source community.

Add New Comment

0 Comments