Open Source: The Model for Collaboration in the Age of the Internet
Pages: 1, 2, 3

Dangers Up Ahead

  • When it comes time to chronicle the dangers facing the Internet and open source, myths also abound:
    • It's a battle between proprietary software and free software.
    • Microsoft is the great enemy.
    • Government regulation is going to spoil things.
  • It's certainly true that companies have tried to "embrace, extend and extinguish" open standards. (And I should note that Microsoft is not the only one. In fact, Netscape started down this path with regards to the Web first; I gave my first talk warning about the dangers of Netscape's strategy to seize control of web APIs back in 1995.)
  • It's also certainly true that the government could bollix things up pretty badly, but the greatest dangers are more insidious and more complex. To explain them, I want to take a brief discursion into the argument of a fabulous book, which all of you should read, if you haven't already, Lawrence Lessig's Code and Other Laws of Cyberspace.

The Architecture that Supports the Internet and Open Source

  • Lessig argues quite compellingly that there is a complex interaction between architecture (code), social mores, the market, and government regulation in creating many of the features that we take for granted in our society. He makes the further case that as architecture (code) changes, we may need to make changes in regulation as well, in order to preserve the status quo rather than to change it.
  • Lessig points out that many of the things we take for granted about the Net, which are perhaps best summed up by John Gilmore's famous dictum that the Net regards censorship as damage and routes around it, are becoming less true, due to changes in internet architecture brought about by e-commerce. The myth of the Net, Lessig says, is that it is unregulable. The myth of the Net is that it is a weapon of free speech, a weapon against aggression. The truth is that, as we are increasingly seeing, the web is also a tool for the invasion of privacy, for the tracking (and potential suppression) of free speech, for the diminishment and trivialization of human rights, on a previously undreamed scale.
  • Lessig talks about the implications of changes in the Internet architecture for privacy, for free speech, and for the prospects of Internet regulation in his book. I won't go into details about how he characterizes the architecture of the Internet, but I will go on a Lessig-inspired meditation about the architecture that has thus far supported open source:
  • Open source projects typically flourish in an environment consisting of small, cooperating programs with defined inputs and outputs, rather than monolithic integrated environments. Linux and the Internet are both ecologies of cooperating programs that have grown up in the wild have learned to live together. Linus points out in his essay in our book Open Sources that the architecture of Linux supports independent developers in a way that the architecture of Windows does not, even were Microsoft to offer Windows under an open source license.
  • At bottom, open source depends on open standards. The ability of independently developed programs to cooperate via standard protocols and data exchange formats was one of the great insights that led to the development both of Unix and the Internet. One of the roles of open source software has in fact been to enforce open standards. It is questionable whether the web would still be open without Apache, or e-mail without Sendmail.
  • The problem spaces being pursued were on the fringes, without great commercial attention. A program could be developed for a very narrow purpose, what has come to be called "a developer scratching his own itch". Often programs were developed for reasons that were indirect. For example, Sendmail was developed because Eric Allman thought it was easier to write a mail forwarding program than to give everyone in CS at Berkeley mail accounts on his Arpanet-connected machine. In this environment, your return on investment is the solution to your own problem; what you get by giving the software away is a dividend, as other people find bugs, enrich its functionality, or adapt it to other related problem spaces.
  • Once the profit motive enters the picture, a developer is trying to scratch someone else's itch, which is a very different proposition. It requires different skills. One of the things that the open source community needs to do is to continue to foster work on the fringes, not just on the mainstream; where is the cool stuff that no one can find a real use for yet, but that breaks new ground? I like stuff like Kevin Lenzo's work with voice recognition, or with "answer bots" that participate in IRC or IM environments.
  • One aspect of being on the fringes is that programs have time to take root, rather than being quickly discarded if they don't lead to immediate success. One of the myths of open source is that it's a rapid development methodology. There are contexts in which this is a true statement, but overall, the growth of open source is more akin to the development of a rich humus. Topsoil grows at a rate of an inch every 100 years. You can grow fabulous plants quickly in that soil, but the soil itself is a product of slow time. Look at most of the famous open source success stories. Many took 10, 15, or 20 years to take off. I have first-hand experience with my own company, which started out as a company providing documentation for many of these programs. Because the programs we wrote about were out of the mainstream, we had all the time in the world. We took six years (and six authors) before we produced our Sendmail book. Many of the books we produced focused on niches in which there was literally no competition.

    Now that open source and the Internet are front and center, we have to realize that the fundamental environment in which they evolved has changed dramatically. This is not to say that open source cannot compete and thrive in that environment, just that to deny that change is likely to lead to being blindsided. Most importantly, we need to realize that a project may be a huge success even though it doesn't give instant results. Open source projects often have unintended consequences. In fact, you might say that OS is the architecture of unintended consequences. Many of the greatest successes come not from the vision of the original designer but the uses to which newcomers put the original tool. Perl found its full flowering only when the Web came along. We're seeing the real fruit of Mozilla not in the next generation of Netscape's web browser, but in the ways that parts of Mozilla are showing up in other projects, from Zope as a web content management platform, to Eazel's next-generation Linux desktop.

  • All of these metaphors have a lot of parallels in sustainable agriculture. I've already mentioned the time required to build up topsoil. What's more, we learn the importance of recycling, of putting nutrients back into the soil. A key part of open source is not just what big flowers you grow, but how much rots and is plowed back in to enrich the next generation. One of the big differences between open source and commercial software is the extent to which code is recycled -- and that doesn't just mean "code reuse" -- it means that ideas, freely shared, form the compost from which other ideas can grow. It means that failed projects are as important to the open source ecology as those that succeed.

Pages: 1, 2, 3

Next Pagearrow