On February 21 I got an email from O’Reilly about a new program called Realtime Publishing. (Since I’ve written a couple books about Adobe Flex I was a potential author for the program.)
It turns out this email makes the case for Leanpub in a very compelling way — more so, since it’s from O’Reilly, not us. So, I’m going to quote their official statement in full.
(The reason that I’m just posting this today is that I’m at BCIT giving a talk about Leanpub, and I figured I’d let O’Reilly make my presentation for me!)
Here are some highlights:
If you’ve been following the publishing industry at all, you’ve no doubt heard the screams of pain. … The bloodbath has ended, but the wounds are still oozing.
A 400-page book takes roughly a year to write, particularly for the kind of author O’Reilly usually works with: technical experts who have other jobs. A print book that takes a year to write, and 3 months in production, is bound to be six months out of date by the time it hits the shelves. That’s really not a service for anyone.
O’Reilly is introducing a new model for publishing. We’re calling it “realtime publishing.” It’s enabled by ebooks, which enable us to answer a question we’ve been asking for a few years: why can’t we publish books the way developers release software?
Furthermore, not only are print books out of date as soon as they hit the market, it’s a year or more before they can be updated. There’s retail inventory that has to be sold, or it will be returned and destroyed. It’s not good to tell a retail bookstore manager that the stock he bought two months ago, or even 9 or 12 months ago, is out of date. Ebooks don’t have this problem: they can be updated real-time. Whenever the author fixes a bug, describes a new feature, updates the book for a new release, all she has to do is flip a switch that triggers a new build, pushes the build out to the servers, and notifies customers so they can download a new copy.
Why do we believe in this strategy? There’s no shortage of pundits who will tell you that 2011 is the year of the ebook. But we don’t have to look at pundits. We can look at our own sales: in the past year, O’Reilly has come to expect at least 35% of the dollar sales on new titles to come from ebooks (including Safari), and we expect that percentage to grow.
We’re increasing author royalties to 25% for all ebook products in this real-time program. That holds both for books that are initially planned as ebooks, and ebooks that are extracts from other books. For customers who want print, books will be available through print-on-demand; a 10% royalty applies to POD sales. There will be no advances.
How do the economics work? Let’s say you sell 10,000 units of a $40 print book. Most of those sales are at a 55% wholesale discount, which brings the price down to $18. That results in $180K net sales, $18K royalties, not accounting for returns. That’s what traditional book publishing is doing these years. Now look at ebooks. Assume we sell 5,000 units at an effective price of $10 (after discounts, etc.; same basis as print books). So that’s $50K net sales, which at a 25% royalty works out to a $12,500—but for a much smaller book that was much less work to write.
It was hard to excerpt the statement, since so much of it is fantastic marketing for Leanpub. So, here’s their full official statement about Realtime Publishing:
Realtime Publishing
We just launched this program, and example of what I am referring to can be found here:
http://oreilly.com/catalog/0636920018261/If you’ve been following the publishing industry at all, you’ve no doubt heard the screams of pain. When the tech bubble burst in 2000, book sales went into free fall. And although the rest of the technical industry has recovered and thrived in the past decade, at best publishing has performed only slightly worse than the previous year. The bloodbath has ended, but the wounds are still oozing.
It’s easy to point to reasons, but most of those reasons are at best half-right. It’s easy to look at the shrinking shelf space allocated to computing in the retail chains—but that’s surely an effect, rather than a cause. If readers were buying the books, the bookstores would be selling them. It’s also easy to point to the ease with which information can be discovered on Google—but I’ve found that Google is a great source for technical blogs that are out of date (or just wrong), that never clearly specify what version of the software they discuss, that don’t discuss the configuration issues that prevent otherwise correct code from working correctly. And so on. Retail is indeed declining, and Google is certainly a competitor, but factors like these aren’t the whole story.
Here are the issues that really face publishing, and what O’Reilly is doing to address them—for our good and for our authors’. First, the pace of technical change: if anything it’s gotten faster over the past decade. A 400-page book takes roughly a year to write, particularly for the kind of author O’Reilly usually works with: technical experts who have other jobs. A print book that takes a year to write, and 3 months in production, is bound to be six months out of date by the time it hits the shelves. That’s really not a service for anyone.
Second, in an open source world, technologies tend to fragment. Developers have a host of alternatives—but no alternatives have enough users to make a book profitable. A few years ago, Ian Darwin counted over 80 Java web frameworks. If this was just a peculiarity of the Java world, we could perhaps laugh. But there are many Python frameworks; many Javascript frameworks (I’ve been told “hundreds”, but I haven’t tried to count); over two dozen NoSQL databases; many new programming languages. Books like Head First Java that cover very general topics are still profitable, but it’s hard to justify publishing on Wicket. Or Sinatra. Or Apache Jackrabbit. Publishers either have to pick winners early on, or they have to sign books on everything and benignly neglect the books on technologies that don’t thrive. Neither strategy is a recipe for publishing success.
That’s the real problem: not Google, not retail, but the rate of technical change and the tendency of technologies—particularly open source technologies—to fragment into hundreds of competing implementations. How do we address these issues, so that we and our authors can prosper in the coming years?
O’Reilly is introducing a new model for publishing. We’re calling it “realtime publishing.” It’s enabled by ebooks, which enable us to answer a question we’ve been asking for a few years: why can’t we publish books the way developers release software? First, the demands of a physical book require a certain heft. A print book that’s too small gets lost on bookshelves. With ebooks, size ceases to be an issue. And this has important ramifications. It’s possible to write on smaller, more specific topics: instead of 1200 pages on Javascript, 70 pages on working with Canvas, plus 70 pages on the class system, etc. All of these can be separate publications. By replacing 1200 pages of print with a collection of shorter ebooks, we can drastically reduce the time it takes to bring content to market. Instead of a year or years, we’re talking about a month, a couple of months at the outside.
Furthermore, not only are print books out of date as soon as they hit the market, it’s a year or more before they can be updated. There’s retail inventory that has to be sold, or it will be returned and destroyed. It’s not good to tell a retail bookstore manager that the stock he bought two months ago, or even 9 or 12 months ago, is out of date. Ebooks don’t have this problem: they can be updated real-time. Whenever the author fixes a bug, describes a new feature, updates the book for a new release, all she has to do is flip a switch that triggers a new build, pushes the build out to the servers, and notifies customers so they can download a new copy. O’Reilly is already doing that with our ebook products. Eventually, books will update themselves, the same way mobile apps do: you’ll open your ebook reader to see a message saying “update 3 books now?” I don’t know when that feature will appear in Kindle, iBooks, and Google Reader, but I believe it will be sooner rather than later. The difference between “early access” and “first edition” is disappearing: ebooks can be, and will be, release-early, release-often products.
Realtime publishing also addresses the fragmentation problem. Many factors contribute to the cost of the book: printing is less than most people think, editorial and production much more. There’s also inventory cost, and the risk associated with producing books that don’t sell. Ebooks aren’t necessarily less expensive to publish, but they are certainly less risky. There’s no inventory, and because they can be shorter (books under 200 or so pages “disappear” on bookshelves), they don’t require as big an investment to develop. If producing a 500-page print book costs $40,000, producing a 50-page ebook should cost $4000. That difference directly affects our ability to take risks on new technologies that don’t have large, well-defined audiences. The net result is that we can take publish on many more technologies. We can afford to build a series of short ebooks around technologies that might not otherwise make the cut. That also means that we can start ebooks earlier, without waiting to see whether any given project is a “winner.”
Why do we believe in this strategy? There’s no shortage of pundits who will tell you that 2011 is the year of the ebook. But we don’t have to look at pundits. We can look at our own sales: in the past year, O’Reilly has come to expect at least 35% of the dollar sales on new titles to come from ebooks (including Safari), and we expect that percentage to grow. That growth is driven by the need to get information now: you can click and have the book on your device in seconds, rather than waiting for Amazon to ship it, or for you to take a trip to the local bookstore. And ebooks are available as soon as the book finishes our production process—several weeks before they’ve been printed and percolated out from the printer to the warehouse to the bookstore. So the need for information, for ideas, is already driving the increase in ebook sales, even before we’ve implemented realtime publishing.
So let’s get concrete. What’s the deal? Here are the parameters for real-time publishing:
• While books can grow over time, we’re looking for manuscripts that are roughly 30-70 print pages long (25,000 words is a reasonable target). We’re not rigid about size; ebooks should be as long as they need to be, no shorter and no longer. And we want to make sure these books can be written quickly so that they’re up-to-date when released.
• Authors need to work in DocBook or AsciiDoc. These formats integrate smoothly into our toolchain, and let us pump out new releases without extended production processes.
• We’ll be going light on traditional copyediting and proofreading. As threatening as that sounds, we need to rethink what “quality” means, and what kind of quality our readers want. Do customers want impeccably edited prose? Or do they want accurate information, fast? We believe that our audience wants the story on new technologies from the alpha geeks and early adopters as fast as it can be placed on the table.
• We will be organizing ebooks into libraries. Customers don’t want information in smaller chunks; they want what they need, when they want it, in digestible pieces. So while our ebooks will be much shorter than our print books, we will create libraries that are tuned to satisfy readers’ needs. Thinking about libraries rather than individual publications also means we can have authors working in parallel more effective, getting more of the story to our customers as soon as possible.
• In the past two years, we’ve developed OFPS (Open Feedback Publishing System) for engaging the reading community with early online access. OFPS has been a great tool for collecting community feedback. Our ebook products will also be designed to engage their communities and gather feedback. We are working on product for contributed content, community-written ebooks, and more.
• We’re increasing author royalties to 25% for all ebook products in this real-time program. That holds both for books that are initially planned as ebooks, and ebooks that are extracts from other books. For customers who want print, books will be available through print-on-demand; a 10% royalty applies to POD sales. There will be no advances.
• We expect authors to stick with their ebooks post-publication, as they would with any other project: we want the books kept up-to-date. Releasing an update will be as simple (for you and for us) as committing changes to an SVN or Github archive. We realize that authors don’t want to be wedded to their books for the rest of their careers, but we would like authors to be responsible about finding someone to carry on the work when they move on.
How do the economics work? Let’s say you sell 10,000 units of a $40 print book. Most of those sales are at a 55% wholesale discount, which brings the price down to $18. That results in $180K net sales, $18K royalties, not accounting for returns. That’s what traditional book publishing is doing these years. Now look at ebooks. Assume we sell 5,000 units at an effective price of $10 (after discounts, etc.; same basis as print books). So that’s $50K net sales, which at a 25% royalty works out to a $12,500—but for a much smaller book that was much less work to write.
This is just the beginning of the ebook story. We will see many innovations in the coming year—some from us, and certainly some from other publishers. These are exciting times: we’re re-inventing publishing in terms that are meaningful for the computing industry.
