Publishing’s “open” future

Today's closed models will give way to tomorrow's open platforms

If I had to summarize the future of publishing in just one word, I’d say “open.” We’re living in a very closed publishing world today. Retailers use tools like digital rights management (DRM) to lock content, and DRM also tends to lock customers into a platform. Content itself is still largely developed in a closed model, with authors writing on their word processor of choice and editors typically not seeing the content until it’s almost complete. Then we have all the platforms that are closed from one another; have you ever tried reading a mobi ﬁle from Amazon in an EPUB reader, for example?

Given these examples of our closed industry, why do I think the future will be different? It has to do with some of the early indicators I’m seeing through start-ups and other trends. My TOC colleagues and I are in the enviable position of getting to cross paths with some of the most forward-thinking people in our industry. We share many of these encounters via our website as well as at our in-person events. I’d like to share some of the more interesting ones that are currently on my radar, including a few featured at TOC Frankfurt last week.

Let’s look at what exactly open publishing is. The word “open” is used a lot in the technology world these days. Open source projects are just one example, but open standards are another. So when people talk about open publishing, what do they mean?

It’s helpful to ﬁrst think about what open publishing is not. The old days, when authors worked on their own until they completed a manuscript and then handed it on to an editor, is a good example of publishing that’s not open.

Contrast this scenario with one where the author is able to collaborate with others, including editors, from the beginning. Feedback happens in real time, and everyone on the project operates synchronously. This is open publishing. It might sound chaotic, but with the right tools it can be a wonderful experience. The key word here is “synchronous,” and one of the key shifts is the movement of the editor’s role toward real-time editing.

Open publishing can support a variety of collaborative and iterative development models. There are rapid intense development models like book sprints, where several people write a book in three to ﬁve days, or slower models often referred to as “iterative”or “agile” book development. If you’re not familiar with these phrases, you need to be, as they are part of the new lexicon of book development and open publishing. Each of these models offers the producers the opportunity to engage in rich dialogue with others while producing content. This in turn enriches the text while also speeding up content development and helping alleviate negative motivation factors, which often confront those facing the momentous task of writing a book alone.

Another important part of open publishing is the role the reader plays in the development of a book. Books can be released in a raw early state to readers for feedback, and hence early readers become part of the development cycle. These releases are sometimes referred to as a “minimum viable product,” or MVP, a term borrowed from software development. MVP strategies provide your customers with a glimpse of what you’re creating well before it’s ﬁnished, and give you the opportunity to gather feedback from your readers and make adjustments to better suit their needs. An MVP is the smallest version of your initial product you can use to gauge customer feedback. That might be an outline and a couple of chapters. Or it might be just a summary of what the book will cover. It all depends on what you’re looking to learn from your customers.

Content access via APIs

Developing content in an open manner is great, but how can we ensure the ﬁnished product is also available in an open format? One way is to leverage what are known as APIs, or application programming interfaces. That’s really just a fancy way of saying you’ve made your content available in a fashion where developers can come in and easily gain access to it.

You might be wondering why you’d ever want to enable developer access to your content. We’ve all heard of developers who’ve gone rogue and created viruses and other destructive applications. Exposing your content via APIs doesn’t mean you lose control over it. What it does mean is that you open the door for new methods of content discovery and consumption that you might not have thought about before.

I’m betting that the next phase of content distribution will come from someone outside our industry, not inside it. Those of us who have been in publishing for a while are simply too attached to existing models. We’re resistant to change and therefore not likely to come up with the next big idea. That’s where the API model really shines. If you set your API access up correctly, you’ll empower countless developers to take your content and make it available in new ways. You’ll be able to dictate certain ground rules (e.g., how much content can be given away for free, minimum pricing of products, etc.), but you’ll also want to be careful and not make the rules too restrictive.

An easy way to start down this path is to make your metadata available through APIs. Developers can then start reimagining new methods of discovery for the content your metadata describes, and you can relax, knowing you haven’t exposed all your intellectual property just yet. When that proves successful, though, the next step would be to work with some of those same developers and make available portions of your content.

ValoBox is one of the start-ups doing a lot of work in the content API arena. Thanks to the magic of APIs, they offer a quick and easy way to embed one of their books anywhere on your web site. ReadSocial is another terriﬁc example and one of the most interesting start-ups in the social content space. Although some still say reading is a solitary activity, ReadSocial is showing just how useful an open, sharing reading experience can be. ReadSocial believes so much inthe notion of open standards that the founders built the entire platform on a set of APIs.

Evolution of DRM

DRM is one of those hot-button topics. Most people tend to be either very supportive of it or ﬁercely opposed. There seems to be no fence-sitting on this one. The majority of publishers insisted on DRM before they’d commit their content to ebook format. That was their security blanket and one way to convince skeptical authors that ebooks are worth pursuing. What’s ironic here is that this same DRM has been instrumental in retailers’ ability to create platform lock-in for consumers. Since you can’t move your Kindle e-books to a Nook, for example, every purchase you make from Amazon makes it harder for you to eventually leave its platform.

Most of the big publishers still support DRM, if not insist on it. Macmillan is the lone member of the Big Six American publishers that has opted to test the DRM-free space with its Tor imprint.

Then there’s what’s known as “social DRM,” which is where the ebook can be copied and easily redistributed, but it typically contains sensitive information such as the owner’s name or, worse, credit card number. By inserting this information into the ﬁle the publisher or retailer hopes to discourage the owner from letting the ebook sneak out into the wild.

At the end of the day, though, DRM offers nothing more than a false sense of security to intellectual property owners. Every form of DRM can be hacked, and the unlocked ﬁle can then be shared with friends and strangers alike. Social DRM is even more easily bro-ken, as that sensitive personal information can be very easily removed from the ﬁle.

Some would argue that the only way to prevent piracy is to never release an ebook to begin with. That’s another myth. After all, prior to the launch of the Pottermore site, the Harry Potter series was not available in ebook format, yet each of the titles was among the most oft-pirated books on the planet. Scanning technology means that print-only books won’t remain print-only for very long.

Apps, platforms, formats, and HTML5

One of the biggest opportunities for an open publishing future has to do with both platforms (e.g., iOS, Android, Windows) and formats (e.g., EPUB, mobi, PDF). There are countless horror stories of publishers investing in native apps for iOS devices only to later discover that they’ll have to invest at least as much as they’ve already spent to get the same app onto the Android platform. You also have to deal with the retailer’s cut of any sales of those native apps or the in-app content they serve up. In other words, native apps lead to a very closed model where only the target platform is served and signiﬁcant expense must be incurred to port them elsewhere.

A similar situation exists with formats. PDF is the granddaddy of them all and remains extremely popular with O’Reilly’s customers. EPUB and mobi are quickly gaining momentum, though. And although PDFs can be read on a Kindle and EPUBs can be read on a variety of devices, there’s no one format that seems to solve all the problems of open, cross-platform use. Or is there?

HTML5 is the format that’s often overlooked. It’s the lingua franca of the web, but I believe it’s also the future of an open content model for publishers. HTML5 is, in fact, at the very core of the latest version of EPUB, EPUB 3. HTML5 offers a variety of features that allow publishers to render anything from the simplest text-only novel to the richest, immersive digital product that leverages audio and video as well.

So if HTML5 is so terriﬁc, why hasn’t the industry already fully embraced it? To answer this question you need to keep in mind that ebook retailers don’t feel an open, barrier-free content delivery platform like HTML5 is in their best interest. Remember that today’s retailers have built their market share by locking customers in, not by giving them the choice of reading anyone’s content on their device. (The partial exception here is Apple, where you can easily load many competing ebook apps on an iPhone or iPad, but Apple’s own content from their iBookstore can be read only on an iOS device.) The simple truth is the Kindle gave birth to today’s ebook marketplace, and there’s no way Amazon is going to tear down the walls they’ve carefully constructed around the garden.

That means that either another retailer will pave the way to an HTML5 future or publishers will forge an alliance to do it for themselves. The U.S. Department of Justice has publishers worried about being charged with any sort of collusion these days, so I ﬁgure a retailer will have to intervene. That retailer will either be a start-up or a second-tier player with little to lose by breaking the rules of the walled gardens.

Whoever does it has a bright future, and they’ll be creating a terriﬁc user experience. After all, imagine not being tied to any given device or vendor. DRM goes away in this world too as content is streamed to the user, much the way Netflix does with video, so HTML5 helps on a number of open fronts.

Let’s open this up together

As you can see, this “open” vision won’t happen overnight, and you can bet the entrenched leaders will have something to say about it, especially as it threatens their market positions. I’d like to think this article has helped you see the value in shifting our industry to more of an open model. Being open doesn’t mean we’re carefree about our intellectual property; rather, it means we’re dramatically improving the customers’ user experience and building a future we have more of a stake in than what we see today in our largely closed environment.