12

Free and Open

We hackers were actively aiming to create new kinds of conversations outside of traditional institutions … This wasn’t an accidental byproduct of doing neat techie stuff; it was an explicit goal for many of us as far back as the 1970s. We intended this revolution.

—Eric S. Raymond¹

No question matters more to reporters than “What’s the story here?” If the reporter doesn’t ask that question him- or herself, some managing editor will.

Yet the story format is incapable of containing the full truth behind whatever subject the reporter might cover. That’s because stories, by design, require conflict or struggle. Whether the topic is politics, the weather, fashion, or sports, you need some kind of trouble or the reader moves on. The cheapest metaphors for trouble—the ones with the biggest boxes of words to work with—are war and sports. Thus, when writing about technology, the easiest stories to write are product versus product, company versus company, CEO versus CEO. But not everything that matters can be found on battlefields and arenas, imagined or real. Such is the case with FOSS.

While a zillion “Windows versus Linux” and “Bill versus Linus” stories ran in the 1990s and the 2000s, there never was much of a fight, because Bill Gates, Linus Torvalds, and their respective projects were driven by different motivations, and they labored in different ways in different organizations toward goals that were only superficially similar and competitive. Yes, Windows and Linux were both operating systems and, in some cases, competed. But Windows had to make money for Microsoft, while Linux just had to make things work. That deeper difference is far more important than the superficial similarities between the two operating systems and the markets they serve.

Here’s another way to look at it: Microsoft had a story, while Linux didn’t. While Microsoft needed to succeed in the commercial marketplace, Linux simply needed to succeed as a useful blob of code.

The dull story-free fact of Linux’s life is that its only job is being the best possible operating system for the widest variety of applications. All other FOSS projects also have the same kind of mundane and straightforward purposes. Thus, they succeed simply by working and being used. Asking Linux, Perl, or Python for their business model is like asking the same of granite or sunlight.

It might have made great copy if Torvalds, the creator of Linux, were a Filippo Brunelleschi or a Christopher Wren, and if Linux’s programmers were building a great cathedral. But Linus came up with Linux “just for fun” (also the title of his book about it²), and that’s what keeps him going as Linux’s alpha maintainer. Rather than sculpting fine works of art, Linux programmers “submit patches.” When asked specific questions about what Linux actually does in the world, Linus answers, “That’s user space. I only do kernel space.”³ That’s not the kind of thing Brunelleschi or Wren would have said.

Yet, the results of work by Linux programmers are beyond profound. Today, most of the sites and services we enjoy on the Net and the Web (including nearly all of Google, Yahoo, Amazon, Facebook, Twitter, and Wikipedia) are built on top of Linux or its close relatives, plus Apache, another FOSS code base, which serves about 60 percent of all the Web’s pages.⁴ Both Linux and Apache have the charisma of pavement. And they’re just two among millions of other dull but essential FOSS code bases.

The total number of FOSS projects may never be known. At the current growth rate, GitHub will probably soon pass 2.5 million code repositories for over a million programmers, if it hasn’t already by the time you read this. SourceForge will pass 300,000, and who knows how many more will be using Google Code (it doesn’t post numbers). All those code bases were created by and for intelligent minds at the Internet’s ends. Nearly all of them began with one individual’s work. And all of them grow by accretion of unique contributions by other individuals, all contributed by way of the Net.

Active and useful FOSS code is social as well as personal, in the sense that the writers of free and open code need to cooperate with each other. Yochai Benkler explains this in both “Coase’s Penguin, or Linux and the Nature of the Firm” and The Wealth of Networks. In “Coase’s Penguin,” he writes,

The central organizing principle is that the software remains free of most constraints on copying and use common to proprietary materials. No one “owns” the software in the traditional sense of being able to command how it is used or developed, or to control its disposition …

I suggest that we are seeing … the broad and deep emergence of a new, third mode of production in the digitally networked environment. I call this mode “commons-based peer-production,” to distinguish it from the property- and contract-based models of firms and markets. Its central characteristic is that groups of individuals successfully collaborate on large-scale projects following a diverse cluster of motivational drives and social signals, rather than either market prices or managerial commands.⁵

Thus, while commons-based peer production may be better for producing code than “property- and contract-based models,” smart firms are also advantaged by adapting to the open source code production model, rather than by fighting it.

IBM offers a good example of adaptation. In the late 1990s, while other companies fought the adoption of Linux by their customers and their own engineers and IT departments, IBM took to heart the lessons of token ring’s loss to Ethernet. Upon discovering the extent of Linux development going on inside the company, IBM decided not only to adopt Linux, but to brag about investing a billion dollars in it.⁶ All that noise made IBM’s effort seem much easier than it really was. Dan Frye, vice president for open systems development at the IBM Systems and Technology Group, told me it took a number of years before IBM management learned that it couldn’t tell its Linux developers what to do—but that instead the reverse was true: Linux developers were the ones taking the lead. Here is how Andrew Morton, one of the top maintainers of the Linux kernel, explained the relationship between wise companies and open source developers:

Look for example at the IBM engineers that do work on the kernel. They understand (how it works) now. They are no longer IBM engineers that work on the kernel. They’re kernel developers that work for IBM. My theory here is that if IBM management came up to one of the kernel developers and said “Look, we need to do that,” the IBM engineer would not say, “Oh, the kernel team won’t accept that.” He’d say, “WE won’t accept that.” Because now they get it. Now they understand the overarching concern we have for the coherency and longevity of the code base.

Given that now these companies have been at it sufficiently long, they understand what our concerns are about the kernel code base.⁷

Andrew now works for Google.⁸