Amazon.com Interview: Tim O'Reilly

Tim O'Reilly talks to Amazon.com's Peter Leopold about the art of publishing excellent computer books, the future of Open Source, what is up-and-coming in technology, and the impact of the economy on technical book buying.

Amazon.com: Some books, like novels, have a story line, while others, like dictionaries, contain retrievable information. Tech books fall somewhere in between. Where do they fall, and how do you instruct your writers and editors to balance story with retrievability?

Tim O'Reilly: Edwin Schlossberg said, "The skill of writing is to create a context in which other people can think." This is true of fiction as well as nonfiction, of poetry as well as scientific papers. The ways that you create that context differ from format to format, but if you understand that a big part of your job is building a framework within which your reader will work, and upon which he or she will elaborate, you're a good part of the way toward becoming a successful writer.

Personally, I find that "telling a story" and "retrievable information" are not as far apart as might be suggested by your question. In fact, I often tell my authors that they are telling a story. In a good story, things happen for a reason. You know who the characters are and why they are doing what they are doing. If you don't know, there's a reason for that too (for example, because the author wants to create suspense). In the case of technical writing, there shouldn't be suspense; instead, what you are doing is telling a story that perfectly anticipates what the reader needs to know, so that he or she finds out at just the right time. If you're writing tutorial information, the application of this principle is obvious, but it also applies in the case of reference. In a good reference, readers need to understand the framework in which the information fits, so that they can find things, and so that when they jump to a random point, the context is readily apparent.

This is why, you'll notice, that just about every O'Reilly book has an introduction that explains its subject in broad strokes. The body of the book then drills down into detail. But because the story has been told once at a high level, the reader can dip in at any point and know where he or she is.

In the case of technical writing, there shouldn't be suspense; instead, what you are doing is telling a story that perfectly anticipates what the reader needs to know, so that he or she finds out at just the right time.

That being said, an unbeatable combination is to have both a narrative and tutorial volume that cover the same ground. For example, our X Window System series, which was popular in the late '80s, comprised a series of paired programming tutorials and reference manuals. The reference manuals always consisted of a set of "man pages"--one alphabetical page for each command or function. Once you understood how things fit together by reading the programmer's guide, the reference manual was for quick access.

This kind of reference book has gone out of style somewhat, but we've tried to keep the spirit of paired narrative and reference in our In a Nutshell series. These books typically aren't tutorials, but they do contain brief narrative overviews for experienced users, administrators, and programmers, which set the stage for alphabetical reference.

One of my favorite compact pairings of narrative and reference is the section on AWK in Unix in a Nutshell. This particular section was written by Dale Dougherty (who was one of the people with whom I launched the publishing phase of my business, and then later went on to create GNN, which some of your readers will remember as the first Web portal). Dale wrote an elegant little introduction to the basic concepts of AWK, followed by an alphabetical command reference--and it's all anyone who's done any programming at all needs to use AWK.

Amazon.com: Good technical writing is supremely difficult. Dava Sobel, John McPhee, and a few other virtuosos have managed to capture fact while maintaining a spirit of fancy. How does O'Reilly promote engaging technical writing?

O'Reilly: Gosh, I don't think of McPhee as "maintaining a spirit of fancy." What I've always admired about his writing is its transparency. The writing never gets in the way; it's like looking through a clear lens.

What's wrong with a lot of computer books is that they try too hard. What makes an otherwise dry narrative engaging is that the natural enthusiasm and insight of the writer shines through, and you can tell that they really care and know about the subject.

There is a wide range of effective styles. Brian Kernighan (co-creator of the C language and co-author of The C Programming Language, The Unix Programming Environment, and The Practice of Programming) has a spare, elegant style. He says exactly what he means; you can parse his sentences like a program. David Pogue, on the other hand (bestselling author of books ranging from Macs for Dummies and PalmPilot: The Ultimate Guide, to Windows Me: The Missing Manual and iMovie 2: The Missing Manual), writes rich, conversational prose. But both of them know what matters and why, and they are able to share that clearly and effectively with the reader.

Amazon.com: Hacker writing is notoriously lax in grammar and style. In one less-than-auspicious example, the author wrote, "Originally, Perl was written as a 'quick-fix' to a problem Larry Wall was having with his job. Typical of all self-admittedly lazy people, he found a better and easier way to do it, and thus Perl was born." How do publishers teach basic Strunk-and-White style (Rule 17: "Omit needless words") to authors who are technically adept but marginally literate?

O'Reilly: Well, we have editors who can work closely with them (if needed) to help them clean up what they write. I started my business as a technical writing consultantcy. I was the nontechnical half of a paired programmer-writer team. (I had a friend who was an out-of-work programmer. The only job he could find was a contract tech-writing job, which he didn't think he could pull off, until I said I'd help him to do it. To make a long story short, he never did learn to write, but I learned to love computers, so he went back to programming and I continued the business on my own.)

My favorite way to start a book is to find someone who appears to be able to do magic. (Remember Arthur C. Clarke's dictum: "Any sufficiently advanced technology is indistinguishable from magic.") Then I ask them to spill the beans on what they do.

So sometimes, the best way to edit is to just get out of the way. It's a gift to an editor or publisher when you get something that falls into place like that!

Amazon.com: You have been described as a superb technical editor as well as an inspired entrepreneur. What essential principles do you use to construct a book out of a manuscript?

O'Reilly: Thanks for the compliment!

So many of our best books start with the question, "How did you do that?!" The second thing is to put that knowledge in the right order. When I was first working as a technical writer and didn't really know very much, I relied a lot on my sense of pattern.

In fact, my favorite way to start a book is to find someone who appears to be able to do magic. (Remember Arthur C. Clarke's dictum: "Any sufficiently advanced technology is indistinguishable from magic.") Then I ask them to spill the beans on what they do. For example, early in my career (around 1983), I wrote what I think was the first-ever Unix system administration manual. I was working on contract at an early workstation manufacturer, writing the documentation for their graphics subsystem. For Unix documentation, they were simply shipping the man pages. And I noticed that the administrators seemed to know an awful lot of stuff that wasn't readily apparent from those pages! What's more, when someone wanted to know how to do something, they didn't start with the man pages; they started by asking one of the "wizards" how to do what they wanted. So I asked the management, "Whom are your customers going to ask?" They didn't have a good answer, so I persuaded them that I ought to interview the wizards and capture what they knew.

(I eventually acquired the rights to that manual back from the vendor, and subsequently licensed it to other companies. At one of those companies, it was rewritten and expanded by Mike Loukides, and then rewritten and expanded once again by Aeleen Frisch, who worked for Mike. When the company went out of business, I acquired the rights once again, and Aeleen rewrote the book a third time. We published it as the now-classic Essential System Administration. (As for Mike, he joined O'Reilly as an editor. He was the first O'Reilly editor besides me and Dale, and is actually responsible for many of the books that people think of as O'Reilly classics, books like DNS and Bind, TCP/IP Network Administration, the first edition of Java in a Nutshell, and most of our other Java books, from Enterprise JavaBeans to Java and XML.) But I digress.

So many of our best books start with the question, "How did you do that?!" The second thing is to put that knowledge in the right order. When I was first working as a technical writer and didn't really know very much, I relied a lot on my sense of pattern. I'd read a spec or other internal document again and again until I could see the organization of the underlying concepts. Often, authors tell the story in the wrong order, and the reader is wandering around in a maze. A great deal of the job of editing is putting the pieces in a straight line, and if there are several forks, making sure that the reader knows where he or she is and doesn't get a bit of one and a bit of another all in a jumble.

In many ways, the same kind of pattern recognition that has helped me identify and publish about many important topics long before they were on other publishers' radar (from the Internet and World Wide Web to Perl and Open Source) is the heart of my approach to editing. Often, there are a few key facts or concepts on which a whole lot hinges. You have to bring those things out, and make sure that they are the inflection points of the story, rather than leaving them buried or unsaid.

Amazon.com: What is the best way to convey technical information?

O'Reilly: By word of mouth. It's great to be able to have someone in the know show you how they did something, especially if they can still remember what they got hung up on when they first learned about it. A book is an attempt to reproduce that experience in a way that can be shared by a larger number of people.

We've always tried to reproduce that "over the shoulder" feeling in our books, filling them in with the kind of small details that someone might tell you in person but that are often left out.

The power of first-person narrative is also at the heart of another series of books I am responsible for--the Travelers' Tales series of anthologies. These books collect first-person accounts of visits to other countries as a way of giving would-be travelers the flavor of the place.

My brother James (who was an experienced newspaper travel writer) and I first came up with the idea for the series while lamenting the difference between the stories he would tell when he came home and the more sanitized versions that appeared in newspapers and magazines, and the laundry lists of places to go and things to do that appear in most guidebooks. We realized that the best way to prepare for a trip is to hear the stories of the people who've been there. This sparks ideas and makes the dry facts of a guidebook come alive.

The first book we developed was Travelers' Tales Thailand. Since then, I've been editorially involved in a few other Travelers' Tales books, notably The Road Within (which I edited with James and one of my other brothers, Sean) and Travelers' Tales Ireland, to which I contributed a story about a hiking trip in Ireland that I took with my brother Frank. (Yes, I'm one of seven children, and that's my mother on the cover of The Road Within !)

Amazon.com: The most remarkable technical book to appear in the past year was Carey Bunks's Grokking the GIMP from New Riders. With wide margins, glossy paper, and a colorful coffee-table presentation, it has staked its claim as the most beautiful book on freely redistributable software, and has introduced graphic art into the mix. How has the appearance of Grokking the GIMP affected O'Reilly's book design strategies?

O'Reilly: Not at all. In fact, I've never seen the book. I imagine some of the folks on my staff have, but we haven't had any discussion about it. A graphic approach isn't that appropriate for many of the subjects we cover.

I'm afraid we don't look very much at what the competition is doing. In fact, if there are good books in an area, we tend to stay away from it (unless we were there first, in which case we'll continue to expand our program.) Our main goal in publishing books is to be useful, which generally means documenting things for which there isn't already a good book. Sometimes it means rethinking an existing area to bring out important information that's been overlooked.

We think of our fundamental mission as knowledge transfer: finding out cool things that people at the leading edge have figured out, and writing it down so that others can learn from it.

Amazon.com: Questions on the Marketplace

Linux is the poster child of the free software community, and O'Reilly has published widely in and around Linux. But O'Reilly has also published widely on the Windows platform. From your nonpartisan viewpoint, where do you see the future of Linux, Windows, and Linux versus Windows?

O'Reilly: Old operating system distinctions don't matter as much as they used to. The Internet is the new operating system, and the real question is how that operating system will evolve. Microsoft, which is extremely good at seeing the big picture and using it to frame its product strategy, has articulated a vision of this new operating system via its .Net initiative, but Microsoft is not alone. Sun has been pursuing a network-centric vision of computing for many years, and in the period from 1996 through 1998 or 1999, when everyone was focusing on the Microsoft-Netscape browser wars, Sun technologies like Java were quietly becoming a key component of the Internet software development platform. Some people knocked the recent SunONE announcement as a hyped attempt to gain mindshare back from .Net (and it was rather over the top!) but at the same time, Sun really has been saying "The network is the computer" for a long time, and has developed technologies that collectively provide a great deal of Internet platform functionality. There's a lot of important Java-based middleware (e.g., from BEA systems) that is behind a great many of the key e-commerce sites and online B2B networks, for instance. J2EE makes this kind of thing a much more widely available part of the Java enterprise platform.

Meanwhile, a lot of the hype about Linux over the past couple of years has pretty much missed the point. So much of the rhetoric (at least for the first few years) has focused on re-creating the Windows desktop. I've felt a bit like I'm the only one harping on that issue. (In my first talk on Linux, in March of 1997, at the same conference where Eric Raymond first gave his seminal talk, "The Cathedral and the Bazaar," I urged the Linux community to turn its attention instead to the Web, not to be the next Microsoft but rather to be "the Intel Inside the next generation of computer applications." My talk met with a chilly reception at the time, but most Linux leaders now recognize that I was right.) Fortunately, while the rhetoric of Linux was somewhat misdirected, the emergent qualities of Open Source, the fact that there is no central direction but rather a free market of ideas, means that a great many developers have quietly been building the components of that next generation operating system just the same.

We think of our fundamental mission as knowledge transfer: finding out cool things that people at the leading edge have figured out, and writing it down so that others can learn from it.

Mozilla is really worth talking about separately, since Netscape's decision to open-source its browser was a watershed event in the computer industry. Obviously, this was too little too late to overcome Microsoft's market power, and Internet Explorer is now clearly the leader on the browser front. But it's amazing just how useful that open Mozilla code has become. Mozdev.org hosts more than 20 derivative projects that use Mozilla as a foundation. And there are others as well. For example, ActiveState's Komodo project (http://www.activestate.com/Products/Komodo) uses Mozilla as the basis for a cross-platform, multilanguage Integrated Development Environment (IDE). Komodo supports Perl, Python, and JavaScript development on Windows, Linux, and Unix. (Disclosure: I am an investor in and board member of ActiveState.)

But the story doesn't end with the Web. One of the things that's wonderful about Unix/Linux, and also about the fundamental architecture of the Internet, is that it defines some simple rules and protocols for programs that allow anyone, completely independently, to write a useful tool or component that can nonetheless interoperate with all the others. (I talked about this concept extensively in my JavaOne keynote last year; the text of that talk is at http://www.oreillynet.com/pub/a/251.)

And so, piece by piece, all kinds of useful functionality is being added to the Open Source Internet platform: Jabber adds instant messaging; the XML-Apache project adds XML parsing, style sheet processors, and support for SOAP (which I'll get to in a minute). Sphinx and Festvox add voice recognition and synthesis.

This emergent platform also overlaps with the Sun Java platform in ways that are not as widely recognized as they should be. The sometimes strident rhetoric of hardcore GNU/Linux partisans, who disdain Sun because its software isn't free of all restrictions, makes people believe that the open-source community eschews Java. But in fact, there are a great many Java-based open-source projects, from Jakarta (the Java-Apache umbrella framework) to Freenet. Enhydra, which brings J2EE enterprise Java functionality to the open-source world, is a crucial missing link.

A lot of the hype about Linux over the past couple of years has pretty much missed the point. So much of the rhetoric (at least for the first few years) has focused on re-creating the Windows desktop. I've felt a bit like I'm the only one harping on that issue.

Overall, .Net is an impressive, forward-thinking vision. I'm particularly excited about some of the work Microsoft is doing in thinking about Web services, with SOAP and UDDI, but the planned support for third-party languages like Perl, Python, and Tcl in the next release of Visual Studio is also going to be pretty neat. And C# is a recognition that Sun was right in arguing that we need some new languages for network-centric software development and a virtual machine-like approach (in this case provided by the CLR, or Common Language Runtime) to provide a base for execution on the disparate platforms, from PCs to handhelds and cell phones, that make up the next generation of Internet-access devices.

I imagine that Microsoft isn't going to give up its current platform dominance without a fight. I'm sure the company would like .Net to have the same kind of market share as Windows! But I believe it also recognizes that this will be an uphill battle, and that at least for the present, it needs to interoperate as part of a larger world.

I'm rather excited to think that we'll be getting all kinds of great new functionality from many new directions--that no one party has a lock on innovation. Competition need not be combat; it can be a joyous game of leapfrog, in which we constantly seek to outdo each other in inventing new and interesting functionality that makes the world a better place.

Amazon.com: Has Windows 2000 contributed anything that the free software world should have cause to celebrate?

O'Reilly: I tend to see Windows 2000 as the last of the desktop-centric Microsoft operating systems. Sure, they are going after the server market with it, but it's got all the baggage of history, and its framing metaphor is still the PC as the center of the universe rather than part of a networked Web. So I think that .Net is the Microsoft initiative that the free software world has to have its attention focused on.

In terms of recent Microsoft operating systems, the innovation I'm fondest of came in Windows 98, and that is the integration of a simple command line (in the form of the Address Toolbar) onto the desktop and into every window. Now, for the first time, you can type commands if it's easier to do so than point and click. To give a trivial example, if you want to run the Solitaire game, it's a heck of a lot easier to type sol in the Address Toolbar than it is to pop up the Start Menu, slide the pointer up to Programs, then over to Accessories, then Games, then Solitaire. Unfortunately, most users (even Unix/Linux users who are accustomed to command-line interfaces) don't realize they can do this, because Microsoft doesn't really push this option, and doesn't tell you the executable names of the various programs. You have to poke around in the Properties sheets to figure them out. One of the things we did in Windows 98 in a Nutshell was to document all the individual utilities in Windows and create "man pages" for all of the programs that you can run from this Windows command line.

I didn't actually know much about Windows when I started working on the predecessor to this book, Windows 95 in a Nutshell. We had gone through a succession of authors (some of them fairly well known PC book authors), but none of them seemed to be able to dig deep enough or to make the book rich enough to justify the In a Nutshell title. So I started playing with the system and wrote some chapters to show what I was looking for. One thing led to another, as I found the system becoming more and more usable as I learned more about it and wrote down a lot of things that just didn't seem to be documented coherently anywhere else.

I see a lot more common cause between Sun and the open-source community than what divides them, and I expect that over time the Sun Java platform and the open-source Internet platform will increasingly converge. (This is important. For that matter, though, I see Microsoft coming to this same party.)

Windows 98 and 2000 don't go all the way. Windows Script Host is supposed to provide scripting functionality, but it's never quite lived up to its promise. As a result, I need to install a few other things on a Windows system to feel really comfortable. I rely on MKS Toolkit and ActiveState's Perl for Win32 to give me the full suite of capabilities that I need.

Amazon.com: On Wall Street, 2001 is shaping up to be the revenge of bricks and mortar. How do you expect the shakeout in e-commerce to affect the technology book business?

O'Reilly: Well, it's certainly had an impact so far. We've actually gone so far as to correlate book sales in various technologies with the stock prices of related companies, and it's shocking how closely the curves overlap. Oracle book sales match Oracle's stock price, Java book sales track Sun's stock price, and so on. This confirms a point that I've often made: there's a lot of faddishness in the computer book market, in which people buy books to find out what's hot, rather than because they have real problems to solve. That's why high-end publishers like O'Reilly, Addison-Wesley, and Prentice-Hall tend to be less affected than entry-level mass market publishers. Our books appeal to the hardcore practitioners who need the information in their daily work, rather than just to the curious. In short, I think that 2001 will see continued growth in market share of high-end book publishers at the expense of low-end book publishers.

Amazon.com: Oreilly.com offers book reviews of competitors' books. How can oreilly.com avoid a conflict of interest? (FYI: Last summer, oreilly.com asked me to review a remarkably bad book that had been published by a competing publisher. My review was unsparing, and it was dismissed with the dismaying comment: "If you can't write anything nice, don't write anything at all.")

O'Reilly: Hmmm. First off, the book reviews you speak of are published on oreillynet.com, our technology portal site (the hub for sites like xml.com, www.perl.com, onJava.com, onLAMP.com, and openp2p.com, which we also operate), not oreilly.com, which is our corporate site.

Second, you seem to be confusing two points here. "Conflict of interest" would suggest that we would have happily published a negative review about a competitor's book. The fact that the editor in question wouldn't publish the review suggests something very different. If a book is so bad that nothing good can be said about it, it's probably not a good idea to dignify it with a review. As William Butler Yeats wrote in his wonderful translation of Oedipus Rex (or perhaps it was in one of the later plays in Sophocles' Oedipus cycle), for such a book, "Never to have lived is best, never to have drawn the breath of life or seen the light of day. Second best is a gay goodnight, and quickly turn away."

We've actually gone so far as to correlate book sales in various technologies with the stock prices of related companies, and it's shocking how closely the curves overlap.

This is not dissimilar to my publishing philosophy. We try to write books about interesting software, and just avoid boring software that there isn't much to say about. But once we make the choice to write or publish, we focus in on what doesn't work as well as what does, in a proportion that will hopefully provide the most benefit to the reader. I remember working with one of my authors in the days when I was an active editor. He complained that he couldn't do a good job on one chapter because the software was so buggy; I told him that made it one of the most important chapters! If he glossed over the problems, the reader might well waste hours coming to the same conclusion. He needed to be unstinting in working through this particular subsystem and pointing out all the pitfalls, since his job was to be a scout for the programmer and specify clearly what he'd found out.

Amazon.com: Electronic paper (and ultimately electronic books) is the subject of R&D at NIST and elsewhere. How does O'Reilly view the future of the silicon-based "print" industry?

O'Reilly: I think this is a wonderfully cool direction. I look forward to a world in which I have a cheap device that can hold hundreds or thousands of books. E-paper has the potential to create something that's far more similar to a printed book than anything we're seeing today, and that will be an enormous convenience.

That being said, I'm very fond of paper books. I have run out of wall space in my house for bookshelves. One of my hobbies is to collect old editions of bestselling books from bygone eras (many of them now largely forgotten) to find out just what people in that time found so compelling. I find that many "great" books have a timeless quality, but the second tier down, in which grand human themes stand out less than the time-bound peculiarities of an age, provide a fascinating window onto the past.

One of the big worries I have about a shift to electronic books is that older documents won't be easily preserved. We already see this on the Web. Electronic documents are more ephemeral than those in print. One area where we see the difficulty of the lack of long-term electronic memory is in the area of software patents. A great deal of knowledge dissemination now occurs not via print (or even electronic journals) but in less formal types of publishing such as Web pages or Usenet or mailing list postings. When the Patent Office goes to look for "prior art" on patent applications, much of it is invisible, and as a result, patents are being granted on many techniques that have previously been invented or practiced by many others. This is only one of many ways in which our social and regulatory systems haven't caught up with technology.

An even deeper worry is the trend toward locking up electronic content too tightly. I was absolutely appalled by the recent comments of Pat Schroeder, president of the Association of American Publishers, attacking libraries for making electronic journals available to their readers without charge. (See http://washingtonpost.com/wp-dyn/articles/A36584-2001Feb7.html) Feeling threatened by the Internet, publishers in fields from music to scientific journals are overreacting and overreaching. They have gone beyond seeking "copy right" to seeking "reader right" or "performance right." This is an extremely dangerous trend. For a blistering, and all-too-prescient indictment of this trend, see John Gilmore's thought-provoking essay "What's Wrong with Copy Protection" (http://www.toad.com/gnu/whatswrong.html). I'm also really looking forward to Larry Lessig's forthcoming book, which will cover some of these issues in more detail than last year's Code and Other Laws of Cyberspace (itself a book that anyone who cares about the future of the Internet ought to read).

Amazon.com: Novelist Stephen King's experimental e-serialization of his novel The Plant went offline recently, despite showing a profit. The official reason for the cancellation changed from failure of reader financial participation to the author's previous commitments. What has O'Reilly learned from The Plant publication experience?

O'Reilly: I rather liked King's honor-based system. It's an example of the kind of experimentation that will eventually lead us to a successful business model for online publication of books. I'm disappointed that King didn't stick with it, because these things take time to develop. Heck, O'Reilly was the first company ever to do advertising on the Web (in 1993, as part of the first release of our proto-portal, the Global Network Navigator, or GNN). At the time, nobody believed that advertising online would work, and we had to do years of heavy lifting (eventually selling GNN to America Online in 1995) before the marketplace had evolved enough to sustain ad-supported businesses like Yahoo! Now, while there are still failures of ad-supported Web sites (just as there are failures of ad-supported print magazines), no one disputes that it is a viable business model that can lead to successful businesses (albeit not as many as joined in the gold rush).

There will be many experiments. We're running one ourselves. Our recently released Safari eBooks service provides "O'Reilly content dial tone," so to speak, for a monthly subscription fee. NetLibrary is pursuing the library model online. There will be many failures, but eventually also many successes in online publishing.

The other thing that's important to recognize is that new media create new formats. You can't just watch the success or failure of a direct translation to a new medium. Movies were originally adapted from plays, but eventually became a medium in their own right, with players and dynamics very different from those of the theater. In some ways, interactive computer games are one successor to the novel (and the television program)--and they are already a huge business. Web sites are successors to magazines and newspapers and some types of books. For that matter, online help has become a successor to one type of book--the software manual!--such that David Pogue's Missing Manual series and our own In a Nutshell series have been able to exploit a real niche by providing a print-based alternative to information that is currently largely provided online. The story is always more complicated than it looks, and attempts to simplify almost always get it wrong.

Amazon.com: The free software movement requires free documentation. How does O'Reilly attribute its commercial success selling into a freely redistributable market?

O'Reilly: There's a real confusion between free documentation and free books. A program like Perl has great free documentation, but it also has free commercial books. When the authors update Programming Perl , they also update the various online documentation--or more to the point, the two efforts inform each other. Putting a book online may not actually be the best way to produce online documentation. Each form has different requirements.

I'm disappointed that [Stephen] King didn't stick with [The Plant ], because these things take time to develop. Heck, O'Reilly was the first company ever to do advertising on the Web (in 1993, as part of the first release of our proto-portal, the Global Network Navigator, or GNN). At the time, nobody believed that advertising online would work, and we had to do years of heavy lifting.

The opportunity that I built O'Reilly around was that the software research community behind Unix didn't see it as their objective to produce a commercial operating system. They provided sufficient documentation to advance their own objectives. But when it came to reaching a wider audience, there was a lot left unsaid. And by taking the time to fill that gap, we were able to add enormous value.

If someone wants to write a book as a freely redistributable document, I'm happy to support them by publishing it, if it's a worthwhile book. But there are an awful lot of topics for which the finished book will never exist unless someone has the financial incentive to create it.

My goal is to find the balance of free and proprietary that produces the greatest amount of value, both for creators and for their users. I like open-source software and open standards because they encourage creativity and allow easy entry to the market; I like commercial activity, which sometimes (though not always) needs to be proprietary to a greater or lesser extent to create enough revenue to justify itself, because it fills needs that may not be addressed by volunteer or "scratch your own itch" efforts.

As an old teacher of mine once said, "You pick the hat to fit the head."

Amazon.com: The peer-to-peer paradigm diffuses ownership and control of information, as manifest in its most notorious form by Napster. How do you see the peer-to-peer paradigm affecting the relationship between the for-profit publishing community and the free software community?

O'Reilly: I don't agree with your statement that peer-to-peer "diffuses ownership and control of information." It may decrease control, but it certainly doesn't eliminate the concept of ownership. One of the points I like best in Eric Raymond's essay "Homesteading the Noosphere" (which is included in the book The Cathedral & the Bazaar, just out in a revised second edition) is that there really is a system of implied property rights even with the freest of free software. In some ways, the rights of creators are more deeply emphasized by systems in which those rights are not enforced by legal (or worse, technical) mechanisms, but by a recognition that those are moral rights. Civilized people don't go around stealing things not because some law stops them but because they recognize that taking something that belongs to someone else is not the right thing to do. As Lao Tsu says in the Tao Te Ching, "Losing the way of life, men rely on goodness. Losing goodness, they rely on laws."

In Code and Other Laws of Cyberspace , which I referred to earlier, law professor Lawrence Lessig explores the complex interactions between code, laws and regulations, market dynamics, and social mores. An overemphasis on laws, or on code-based attempts at regulation like copy protection, leads us to forget that we need to work on the social contract between creators and their audiences. Part of the problem with some of the industries that are most threatened by technologies such as Napster is that they have lost their moral legitimacy. Both artists and consumers feel ripped off. Publishers must add value; they don't simply have some hardwired right to exist.

Part of the problem with some of the industries that are most threatened by technologies such as Napster is that they have lost their moral legitimacy. Both artists and consumers feel ripped off. Publishers must add value; they don't simply have some hardwired right to exist.

It's always tough when technology forces a change in marketplaces. Existing players complain or fight back. But it's tough for the marketplace to find a new equilibrium when the law comes down on the side of the old order. Everyone needs to stay flexible, tone down the fear-mongering, and experiment to find business models that generate enough money for content producers.

The other thing that bothers me about your statement is that it implies that P2P is all about control of information. File-sharing is only one small part of a much bigger picture, which includes network collaboration à la Groove and the rise of Instant Messaging as a platform, distributed computation, and Web services. Some of my thoughts on this topic (and those of some of the key leaders in the P2P space) are collected in the upcoming book Peer-to-Peer, edited by Andy Oram. They are also the focus of the P2P conference I'm holding in Washington, D.C., in September.