Monday we requested questions for Tim O'Reilly, of O'Reilly & Associates. Tim obviously put a lot of time into coming up with thoughtful answers, which we have published below. We've also invited Tim to join in the discussion here if he can find time, but please don't get upset if he can't. "Busy" is an understatement for this man!
How often are books revised? Open to the author?
In our early days, we revised our books constantly. For example, I did ten editions of Managing UUCP and Usenet between 1986 and 1991--about one every six months. The book grew in something much like an open source software process, where I was constantly incorporating reader feedback, and rolling it into the next printing. We didn't do a big marketing push about it being a new edition, we just had a change log on the copyright page, much like you do with a piece of software, each time you check it in and out of your source code control system.
Now that we're much larger (and many of our authors no longer work directly for us), it's harder to do that, but we still roll in a lot of small changes each time we go back to print.
The reason why it's harder mainly has to do with the inefficiency of retail distribution. When there are thousands of copies sitting in bookstores waiting to be bought, rolling out a "new edition" is a big deal, since you have to take back and recycle all the old ones. So you have to go through a process of letting the inventory "stored in the channel" thin out. This means that, especially for a very successful book, you can't do updates as often as you otherwise might like. We slipstream in fixes to errors and other small changes, but major changes need to be characterized as a "new edition" with all the attendant hoopla.
There is also the issue you advert to in your question, and that is the availability of the author to do the update. Sometimes an author like David Flanagan has a number of bestselling books, and he updates them in round-robin fashion. Sometimes an author loses interest in a topic, or gets a new job and doesn't have time any more, and we have to find someone else. Sometimes the technology is fairly stable, and so we don't need to do a new edition.
Sometimes we know we need a new edition, but we just get distracted, and don't get around to it as quickly as we should! At least we don't do what a lot of other publishers do, which is issue a "new edition" for marketing reasons only, where the content stays pretty much the same, but it's called a new edition just so they can sell it in freshly to bookstores.
Fatbrain.com has recently announced that it will offer an electronic publishing service, E-matter. What do you think about offering documents for download for a fee? Is this something that O'Reilly might be undertaking in the future?
Well, we were part of FatBrain's ematter announcement, and we're going to be working with them. But I have to confess that the part of their project I liked the best wasn't the bit about selling short documents in online-only form, it was the idea of coordinating sale of online and print versions.
I know that there's a lot of talk about putting books up online for free, and we're doing some experiments there, but to be honest, I think that it's really in all of our best interests to "monetize" online information as soon as possible. Money, after all, is just a mutually-agreed ratio of exchange for services. When the price is somewhere between zero and a large number, based on negotiation, the uncertainty often means that the product is not available.
In general, I foresee a large period of experimentation, until someone or other figures out the right way to deliver AND pay for the kinds of things that people want to read online. We've seen it take about five years to develop enough confidence in advertising as a revenue model for the web (starting from our first-ever internet advertising on O'Reilly's prototype GNN portal in early 1993). Similarly, I think that the "pay for content" sites--whether eMatter or ibooks.com, or books24x7, or itknowledge.com--will take some time to shake out. Meanwhile, we're playing with a bunch of these people, and doing some experiments of our own as well.
Not to start a free SQL server war here, but I notice there is a (quite good) book on mSql and MySql, but nothing for PostgreSQL. Are there any plans to cover it in the near future?
We're looking at this but haven't started any projects yet. We've had a huge number of requests for a book on PostgreSQL, and we're taking them very seriously.
You've said that the Linux Network Administrator's Guide sold significantly less than would normally be expected as a result of the text of the book being freely available on the net. By what sort of margin? How many copies did it sell, and how many would you have expected to sell under normal circumstances? Would you release another book in a similar manner if the author accepts that they'll make less money from it? Did the book actually make a loss, or just not make as much profit as expected?
Well, it's always hard to say what something *would* have done if circumstances had been otherwise. But on average, the book sold about a thousand copies a month in a period where Running Linux sold 3-4000 and Linux Device Drivers about 1500. Now the book is badly out of date (though a new edition is in the works), but you'd expect that there are more people doing network admin than there are writing device drivers. (And in fact, reader polls have actually put the NAG at the top of the list of "most useful" of our Linux books.)
Frank Willison, our editor in chief, made the following additional comments about the NAG and its free publication:
"We can demonstrate that we lost money because another publisher (SSC) also published the same material when it became available online. Because the books were identical, word for word (a requirement the author put on anyone else publishing the material), every copy sold of the SSC book was a loss of the sale of one copy of our book.
One interesting side note was that SSC published the book for a lower price than we did. Of course, we had the fixed costs: editing, reviewing, production, design. But those fixed costs didn't make the difference: when you took out the retail markup, the difference in price was equal to the author royalty on the book.
The above may be too much info, and isn't directly related to current Open Source practices, but it still chafes my butt."
If I had to quantify the effect, I'd guess that making a book freely available might cut sales by 30%. But note that this is for O'Reilly--we've got books with a great reputation, which makes people seek them out. And we cover "need to know" technologies where people are already looking for the O'Reilly book on the topic. For J. Random Author out there, open sourcing a book might be a terrible idea, or a great one. An author with some unique material that doesn't fall into an obvious "I already know I need this" category can build a real cult following online, and then turn that into printed book sales to a wider audience. We're hoping to do the same thing in publishing Eric Raymond's The Cathedral and the Bazaar (and other essays) this fall. Most of you guys have probably read them online, but there is a larger population who've probably heard the buzz, and will pick them up in the bookstore. On the other hand, an author who puts a lousy book online will only show this to the world, and sales will be 10% of what they'd been if the reader hadn't been able to see the book first.
Perhaps more compelling is the evidence from the Java world, where sales of the Addison-Wesley books based on the Sun documentation (which is mostly available online) are quite dismal, while our unique standalone books (as those from other publishers) do quite well. More importantly, though, programmers in our focus groups for Java report spending far less overall on books than programmers in other areas, because they say that they get most of the info they need online.
All of this is what tells me we need to tread carefully in this area, since I have to look out for the interests of my employees and my authors as well as my customers. In the end, free books online may look like a great deal, but it won't look so good if it ends up disincetivizing authors from doing work that you guys need.
And frankly, we have conversations all the time that go like this: "I'm making $xxx as a consultant. I'd love to write a book, but it's really not worth my while." At O'Reilly, we try to use authors who really know their stuff. So writing a book is either a labor of love, or it's a competitive situation with all the other things that author could be doing with their time. So money is an issue.
(two out of three submitted) What books would you recommend a budding writer should read and study? and Do you read every book you publish?
Books about writing that I like are Strunk & White (The Elements of Style) and William Zinsser's On Writing Well. But really, read any books that you like. Reading good technical books, and thinking about what works about them for you, is always great. We learn far more by osmosis than by formal instruction. So read, and then write.
Going back to the recurrent questions about free documentation--a great way to learn to write is to do it. Contribute your efforts to one of the many open source software projects as a documentation writer, get criticism from the user community, and learn by doing.
I would say that the ability to organize your thoughts clearly is the most important skill for a technical writer. Putting things in the right order, and not leaving anything out (or rather, not leaving out anything important, but everything unimportant), is far more important than trying to write deathless prose. The best writing is invisible, not showy. My favorite quote about writing (which came from a magazine interview that I read many years ago) was from Edwin Schlossberg: "The skill of writing is to create a context in which other people can think."
As to your second question: alas, I no longer have time to read everything we publish. We have a number of senior editors whose work I trust completely -- I never read their stuff unless I'm trying to use it myself. For new or more junior editors, I generally do a bit of a "sample" of each book somewhere during the development process. If I like it, I say so, and don't feel I have to look at it again. If I don't like it, I may make terrible trouble, as some of my editors and authors can attest.
One of the biggest compaints aong critics of the BSD operating systems is the lack of available books. Since O'Reilly is the leader in Open Source documentation, you are well positioned to enter the BSD market. With that in mind, why hasn't O'Reilly published any BSD books in recent memory?
Every once in a while we make a stupid editorial decision, as, for instance, when we turned down Greg Lehey's proposed BSD book (now published by Walnut Creek CDROM). This was based on the fact that the BSD documentation, which we'd co-published with Usenix, had done really poorly, and the relative sales of our original BSD UNIX in a Nutshell relative to our System V/Solaris one. That was many years ago now, and BSD has emerged from the shadows of the AT&T lawsuit, and become a real force in the open source community. So I definitely think that there are some books that we might want to do there. Proposals are welcome.
That being said, so many of our books cover BSD (just like they cover Linux, even if they don't say Linux on the cover). After all, BSD is one of the great mothers of the open source movement. What is Bind, what is sendmail, what is vi, what is a lot of the TCP/IP utility suite but the gift of BSD...it's so much part of the air we all breathe that it doesn't always stand out as topic that gets the separate name on it.
Would you ever consider making previous editions of certain books free for download when supplanted by newer editions?
For example, when Larry Wall finally gets around to writing the 3rd edition of the Camel (probably about the same time as Perl 6), would you consider making the second edition available in electronic format?
I realize this has the possibility of forking documentation, but it's hard to find anyone more qualified than Larry, Randal, and Tom, for example. It would only work for certain books.
The previous edition of CGI Programming for the WWW is available online now, while we work on a new edition, as is MH & xmh and Open Sources. You can read these at http://www.oreilly.com/openbooks/. We'd like to put more of our out of print books online, but it's a matter of man hours. Our Web team is organizing a new effort around this now, so look for more books to appear on this page.
And in fact, an awful lot of Programming Perl *is* available for free online, as part of the Perl man page or other perl documentation. It's not available in exactly the same form, but it's available. That's one of the big questions for online documentation: does the online version always look like the print version.
But this is a good question, and it's one we have certainly something we can think about. Might be another interesting experiment in understanding the ecology of online publishing.
Not sure how to phrase this, but, well, what is the status of O'Reilley and marketing books to schools and colleges for use as textbooks. Our textbooks suck, and if there textbook versions of ya'lls books it would rock.
We actually do quite a bit of marketing to schools and colleges, and they are used as textbooks in a number of places. If you know of a professor who ought to be adopting an O'Reilly book, please send mail to our manager of college and library sales, Kerri Bonasch, at firstname.lastname@example.org. We also have a Web site to support this effort at http://www.oreilly.com/sales/edu/.
Are there any specific things that you see as obstacles to use of the books as textbooks? What topics would you especially like to see as textbooks?
Are there any plans to improve the binding on your future books? Many of us use O'Reilly books to death and the binding is the first to go. I know I certainly wouldn't mind pay slightly more for a stronger version of some of the most heavily used titles.
Hmmm. We use a special high-cost binding, which allows the books to lay flat. It's quite a bit more expensive than the normal perfect binding used by most publishers, and we think it's worth it. I have heard lots of compliments on how great this binding is. I haven't heard complaints about it breaking down--at least not without use that would break down a normal perfect-bound book as well. I don't know of any way to make it more durable.
Maybe hardcover? It would be great to have a slashdot poll on how many people share your problem and would like to see O'Reilly books in hardcover. (One caveat: We tried an experiment once (for our Phigs Programming Manuals--real behemoths) to offer books in both hardcover and softcover, so people could choose. Despite polls that said people would pay more for a more durable hardcover, everyone bought the softcover to save the difference in price.) So, if there is a poll, how much would you pay for a more durable book?
Given some of the recent discussion surrounding the Linux Documentation Project (LDP), I began to wonder about its long-term direction and viability.
I "grew up" with Linux by reading *many* of the HOWTOs and other documents that were part of the LDP. In many ways, I'd have been lost without the LDP. But with the growth of Linux mind-share and increased demand for texts that help newcomers get acquainted with the various aspects of running their own Linux systems, there seems to have been a stagnation in much of the free documentation. I can't help but to wonder if many of the folks who would be working on LDP-type material have opted to write books for publishers instead.
Where do you see free documentation projects like the LDP going? What advice can you offer to the LDP and those who write documents for inclusion in the project? Might we see electronic versions of O'Reilly books (or parts of them) included in free documentation projects?
I don't think that the slowdown of the LDP is because of authors deserting it to write commercial books. In fact, I think you're going to see a reinvigoration of free documentation efforts, as publishers try to contribute to these projects. I think that the right answer is for those who are writing books to figure out some useful subset of their work that will be distributed online as part of the free documentation, and for there to be some added value only available in books. I think that this has worked pretty well for the core perl documentation, where an update to the camel and an update to the online docs are really seen as part of the same project.
When O'Reilly is directly involved in an Open Source project, this is fairly typical of what we do. For example, O'Reilly was one of the original drivers behind the development of the docbook DTD, which is now used by the LDP. (We started the Davenport Group, which developed Docbook, back in the late 80's.)
We're releasing a book about Docbook, by Norm Walsh and Len Muellner, called DocBook: the Definitive Guide." It will be out in October. Norm and Len's book will be also available for free online through the Oasis web site as the official documentation of the DocBook DTD. This is our contribution to users of DocBook; without our signing and creating this book, good documentation for DocBook wouldn't exist. (This is in addition to our historical support of the creation of DocBook.)
Our goal here, though, is evangelical. We want more people to use docbook (and xml in general), and we think that making the documentation free will help that goal.
CmdrTaco asks (on behalf of a friend):
I understand from a very reliable source that O'Reilly is moving their website from a single Sun and an inside developed webserver to an NT cluster and some barely functioning proprietary software. Their bread and butter has been Unix. They have been taking a more and more vocal position within the OSS community. Why are they switching to NT?
Well, your very reliable source has only part of the story right, and that's because it's a long and involved story. It started about 18 months ago, when the people on our web team wanted to replace what had become a fairly obsolete setup whose original developers no longer work for the company.
This system--which was about five years old--involves a lot of convoluted perl scripts that take data in a pseudo-sgml format, and generate a bunch of internal documents (marketing reports, sales sheets, copy for catalogs etc) as well as web pages. We wanted to do something more up to date, and didn't have internal resources to devote to a complete rework.
So we went out to a number of web design firms for bids. The winning firm does work on both NT and UNIX, but they showed us all kinds of nifty things that they said they had already developed on NT that we could use. These were tools for surveys, content management, etc. There was also stuff around integration with the spreadsheets and databases and reports used by our financial and customer service people. To recreate these tools on their UNIX side would cost several hundred thousand dollars.
So I said: "We can either walk the talk, or talk the walk. I don't care which, as long as what we do and what we say line up. If you can do it better and cheaper on NT, go ahead and do it, and I'll go out there and tell the world why the NT solution was better."
I was prepared to have to tell a story about interoperability--after all, despite all our efforts to champion open source, we realize that our customers use many, many different technologies, and we try to use them all ourselves as well. We were looking at doing some things on NT--the stuff our vendor said they already had working--while incorporating other elements on UNIX, Mac, Linux, and Pick (yes, we run a Pick system too!). The whole thing was going to be a demonstration of ways that you can choose from and integrate tools from many different platforms.
Instead, I have to tell the story that is so familiar to Slashdot readers, of promises of easy-to-use tools that, unfortunately, don't work as advertised. As your source suggests, the NT parts of the system haven't been delivered on time or on budget, and what we've seen doesn't appear to work, and we're considering scrapping that project and going back to the safe choice. To put a new spin on an old saw: No one ever got fired for using open source.
I say that tongue-in-cheek of course, because unlike a lot of open source partisans, I don't think that all good things come from the open source community. We like to bash Microsoft with the idea that "no matter how big you are, all the smart people don't work for you" but it's just as true that they don't all work for the open source community either. There are great ideas coming from companies like Sun and Microsoft, and (most of) the people who work there are just like us. They care about doing a good job. They want to solve interesting problems and make the world a better place. And sometimes they do.
I consider it my job to give them a fair shake at convincing me, and if they do, to give you a fair shake at learning what they've done right as well as what they've done wrong. I'll keep you posted.