Thoughts on rechartering and the future of publications on the web

Hi Everyone,


Hachette Book Group is a rather large company, as publishers go. A very
significant fraction of our revenue comes from EPUB, which makes EPUB
really important to us. Of course we’re interested in a future where we can
do more with our digital books than is currently enabled by EPUB. How do we
get there without going broke, alienating our customers, and destroying our
business relationships? That's a tough question for web publications to
answer. But this is what we need to figure out before we change direction,
before we recharter, before we decide whether to move EPUB 3.X to REC
track. What should the future of EPUB be? How does EPUB relate to the web?
Is the “convergence” we dream of possible, or desirable?

>From the point of view of trade publishing, the fundamental thing about an
ebook is that it is a thing, it is a single object that can be bought and
sold and transmitted. That allows us to sell digital books while still
maintaining relationships with our authors. For us, packaging is the major
difference between the web and EPUB. This means that WPUB is of little use
to us unless it’s packaged. For other segments of publishing, the answers
may be different. Scholarly publishing has different needs, as does
education.

We also need to think about what will encourage publishers to move to new
formats. The original EPUB had a fairly compelling message: Use EPUB and
you can stop making all the other incompatible ebook formats that were out
there: Palm, LIT, PDF, Sony, etc. EPUB 3 had a far less compelling message.
My CEO doesn’t care that I can use <aside> rather than <div
class="sidebar">. Almost no one cares that you can put video in an ebook.
And the result is that we are still working on convincing publishers to
move from EPUB 2 to EPUB 3 after seven years.

What will convince publishers to move to web publications? Being a
“first-class citizen of the web” is not an answer. What can WPs do that
EPUB can’t? What new content? What new business models? What new user
experiences? This is the story we need to tell. We also need to tell the
story of what happens to our existing content if everything changes. PRH
has something like 80,000 EPUBs; we’re lucky to only have 30,000.

We also need a story that works for the TAG, the AC, and the browsers. I’ve
heard the word “shit’ used by the TAG to describe EPUB. How can we move
closer to the web without wrecking our businesses? Part of that is being
clear about what we want. Publications on the web are possible today.
Nothing is stopping us. So what are we asking for? What problems are we
trying to solve?

And whose problems are we trying to solve? We spend so much time thinking
about technology and business and the politics of working groups that we
forget who we’re doing all this for: actual human beings who want to read
publications. Readers don’t care about EPUB or WPUB or anything we spend
our days arguing about. Readers care that their books are too often full of
mistakes. Readers care that their books are hard to navigate. Readers care
that their books might just go away.

We also need to figure out what EPUB means. What makes an EPUB an EPUB?
Does an EPUB have to use OPF and OCF? Is a publication with a JSON-LD
manifest and packaged with a bundle of signed exchanges an EPUB? Is there
room for EPUB to evolve? EPUB that uses HTML, that kills off all the things
we tried to get rid of in 3.1. Does anything we call EPUB have to be
strictly backward compatible with EPUB 3.0.1?

And where do audio books fit into this picture? We have a business need
(although not documented as well as I would like), and a certain amount of
urgency.  But do we adapt existing EPUB for audio, or try to build the new
world from scratch with audio books as guinea pigs?

We have lots of questions.

***

What might the answers look like? I think we need a path that starts from
where EPUB is today. I’ve written at length elsewhere about the problems we
have with EPUB.


   1.

   The EPUB specification represents a contract between authors and reading
   systems. Follow the rules when making books, and the books will be rendered
   faithfully. But that contract is being broken far too often today. Reading
   systems don't implement parts of the spec. Implementations are buggy. We
   can describe this as a lack of interoperability, but that hides the actual
   damage: Readers have bad experiences, where content may be hard to
   understand or even missing. Publishers create suboptimal books, avoiding
   features that don't work everywhere. I think this a problem worth solving.
   But to solve it we need information. What features aren’t supported? What
   are the bugs? How can authors work around these problems? To find out, we
   need tests. Tests are little EPUB files that tell us what works and what
   doesn't. And what’s a best practice but a test that passes everywhere? With
   this information, we can encourage reading systems to fix bugs and support
   features. We can discover if the spec itself needs clarifications or
   changes. And we can document what works today for authors. Interestingly
   enough, these are the same actions required to bring EPUB 3.X to REC. I
   think this is a useful, if immensely challenging, step.
   2.

   Publications exist on the web today. We need to be very clear about what
   they are missing, what needs to change to make them viable for our
   industry. Instead of creating something called “Web Publications,” let’s
   look at what pieces are missing from the web platform. We have lots of use
   cases and requirements, but our requirements are very vague. Can these
   requirements be recast into more concrete, actionable statements, so that
   we can evaluate whether today’s web can meet these requirements, and then
   clearly identify the gaps? We need an explainer for our requirements.
   3.

   When we’ve explained what we need, we should document all our proposed
   solutions, whether or not they are currently in the WPUB draft (one
   example: we should document why we rejected WAM). And we should bring
   that to the TAG, and enlist their help in finding architectural
   principles to guide our work.
   4.

   Similarly, we should write an explainer for audio books. What exact
   problems of authoring, distribution, and consumption are we trying to
   solve? What does the industry do today? Who is asking for change? Who will
   be working on solving these problems?
   5.

   Once we have clarity about where we are starting from, what we need from
   the web platform, and how we want to do our work, we are in a good position
   to start writing a new charter that will get the support of the publishing
   industry and the browser community. But I don’t think we can write a
   charter until some of the above questions are answered.



Dave