Foreword

The most well-known organizational models of getting things done whether it's building a house, producing a motion picture, or writing software tend to concern the prediction of and commitment to specific outcomes, mitigating risk to the plan, and correcting surprises along the way. In such models, innovation is seen to happen at the moment of inspiration of the idea and the remaining 99% of the effort is perspiration, to paraphrase Edison. Say it along with me: "Yeah, right." This view looks at innovation as a very solitary sport; we want to talk about Steve Jobs as the guy behind the iPod, rather than the mix of good engineers and product marketing types who collaborated with Steve to find the right sweet-spot combination of features and fashion.

We also want to talk about Linus Torvalds as the guy responsible for Linux, but that's even less close to the truth than the Jobs/iPod example. Linus' brilliance is not in creating an unprecedented technology innovation, nor in plotting the perfect road map for the Linux kernel, nor in having a full-time staff of his own to assign work to. The brilliance inside Linus is his ability to orchestrate the aggregated interests of thousands of other developers, all individually scratching their own itch (or that of their employer), and thereby making a product renowned for reliability, performance, and the features people need. Linus' role is like that of an air traffic controller watching the skies fill with ideas, prototypes based on those ideas, and serious production-quality code implementing the best of those ideas then deciding when that work is mature enough to land at the airport known as Linus' official kernel source code repository.

It's been said that humility is the most underrated force in the world today. Successful open source leaders demonstrate this over and over by driving for consensus on major ideas, making it clear their own ideas are open to challenge, and being as transparent as possible. Building a sense of empowerment amongst the developers is more important than meeting ship dates with specific features, and more important than creating zero-defect software. The Apache Software Foundation, for example, believes that its first order of business is creating healthy software developer communities focused on solving common problems; good software is a simply an emergent result.

In fact it couldn't happen any other way, and here's why. The Open Source Definition is a list of terms that are requirements of any license claiming to be an open source license, and any project claiming to be an open source project must have such a license. One of the key themes of the OSD is "the right to fork": the right to create a derivative work and redistribute it to other people under the terms of the same license, without the approval of the original developers. This doesn't happen often; most of the time, when someone fixes a bug or adds a minor feature, they usually offer it back to the original developers, and if the project is well run, that ends up in a subsequent release. But when it needs to happen when the original developers have moved on to other things, or worse, become difficult to work with the right to fork acts as an essential device to carry a project forward.

Among many other benefits, this rule means that leadership in an open source community comes not from leverage or control, but from finding common interests and expertly managing what is volunteered. Open source projects don't compete for "market share" for dollars from the user base because there aren't any. Instead, they compete for developer mind share and heart share, and that's not going to flow to a leader who's obstinate, unresponsive to the user community, or technically unsophisticated.

Those who see open source as a bunch of zero-price software created by impossibly altruistic amateurs don't get this at all. The rest of the world, though, is starting to clue in to the idea that the software industry doesn't have to be a zero-sum game, and that letting go of a little control and ownership might actually result in something grander in return. This notion is larger than just software. Professor Eric von Hippel at MIT has charted a history of interesting experiments and patterns in the domain of "user-led innovation" companies who have experimented with involving their customers in the design of follow-up products; or delivering toolkits rather than finished works, allowing customers to create new uses or solve more complicated problems. The Wikipedia is a huge example of participatory creation that sounds like it should be an unmanageable chaos, but instead has developed a reputation for being more complete, up-to-date, and balanced than any series you could buy and put on your bookshelf.

These successes don't just happen by magically pressing the "Be More Open" button on the keyboard. There is a universe of best practice and lore that before now has been largely an oral tradition, picked up by sitting on a good project mailing list for years and learning the patterns of communication and process.

Karl has done the software development world a tremendous favor by finally capturing much of that in this book. While the software engineering world is much more comfortable with the concepts of open source, software developer communities, and unpredictable outcomes than they were before, there are still not enough leaders with Karl's grasp of the nuances that make all the difference. With this book, that can change.

Brian BehlendorfApache Software Foundation and CollabNet