An optimistic view

A few weeks ago, the W3C and IDPF announced “mutual interest in combining their respective organizations to more quickly advance publishing technologies on the Open Web Platform.” Those of us at the IDPF’s Digicon heard it live. Everyone else got the press release. Since then, many people have written many articles, emails, and tweets about whether this a good thing, a bad thing, or perhaps even a sign that both ebooks and the Web are dead, for real this time. Much of what I’ve read seems to have been based on misconceptions about the way that the two organizations operate and the way that standards are developed. I have been involved in both organizations, first as a member, then as co-chair. I have not been around for as long as some others, but perhaps I’ve been around for long enough to share some observations and dispel some myths.

Myth #1 Technologists will squash publishers

I have been involved in the W3C’s Digital Publishing Interest Group since its inception at a workshop in 2012 (I think it was 2012). At first I was a little overwhelmed to be in the presence of these people who build the Web. The awe wore off quickly as friendships and mutual respect formed. The Web is an astonishing place of connectedness and shiny objects. Publishing is also an astonishing place with thousands of years of history, tradition, and art. We were eager to learn about each other’s work and perhaps pick up some tips along the way.

Some people wonder why those who spend their days working on the latest and greatest for Web.next would be interested in in publishing. First of all, this says a lot about the people asking the question. I think it shows limited perspective about what publishing is. I am not talking about enhanced ebooks, the next “Netflix for books”, or Killing Amazon. I’m talking about improving a tool chain that was developed before the bar code had been imagined, using structured markup for reusable learning objects, establishing peer review via web annotations, figuring out how to sync supply chain metadata and library metadata, and creating books that are usable by all people, no matter what their level of ability. That’s a short list of issues that came to me as I typed. So many problems to solve.

Most technologists enjoy a challenge. In my experience with the W3C’s developers and architects, once they’ve been exposed to the technical challenges of publishing, they are hooked. We have new challenges, twists on old problems, unchartered territorry, and fun people. Most care about books, journals, and magazines, and are intrigued by the prospect of something a little different on the Web. In fact, some of the ideas publishing proposes hearken back to some of the very early ideas of hypertext and linked information. In short, publishing is a little sexy.

So, why should the publishers be involved if Team Tech will solve all the problems? Traditional Web developers need context. Without information and solid examples and use cases from publishers, they do not have enough information to help publishing with its challenges. Furthermore, one person from one publisher saying “I have this problem. Help me solve it.” is not sufficient. My individual voice might get drowned out, but if several publishers talk about the same challenge, then we are heard.

It is nice if there is someone from the publishing world who has at least a little technical knowledge (and let’s acknowledge the vast technical knowledge that some publishers do have). It’s more important for the publisher to provide perspective, use cases, and the ability to write and edit. In the W3C, decisions about what working groups do next, and how much time to devote to specific issues are made by the members of the group. Even if a group decides that it is really important to work on Feature X, it will only happen if there are volunteers to do so. If publishers (or others) are concerned about getting lost in the technical shuffle, then the most important thing to do is show up and participate.

We also need to remove the labels of “technologist” and “publisher”. This presents an us versus them mentality that helps no one. Every publisher has people with a technological bent, or even technological gurus. Every website publishes in some way or another. We are talking about working together, not winning a battle.

Myth #2 The Browsers won’t care

We often think that the only test of a Web feature is browser implementation. It is really nice when browsers pick up a feature immedately, but we need to keep perspective. There are many W3C features and specifications that can be utilized in other ways or are just waiting for their day in the sun. I don’t really know what drives browsers to decide to implement specific features. What I do know is that being silent will help no one. Further, whether the work toward digital publications is done in the IDPF or the W3C, most reading systems rely on browsers. Working in the same room as the browsers is likely to get us further. It wasn’t until I joined the W3C and became an active participant that a developer from a major browser stopped me in the hall during a meeting break and asked me for my wish list for that browser.

There is a lot of confusion about what the W3C publishes. The W3C groups create notes, best practices, primers, and what we call “specifications” and “standards”. There seems to be some belief that “Big Technology” sits in a room and crafts a plan about what happens next on the Web. I recommend reading “Establishing Web Standards” by Oliver Lindberg. This article gives a short overview of how these documents are developed. One point that I’ll add is that every working group member has equal say. Like most things in life, participation is what you make of it.

A little history

There seems to be a great deal of concern about the risk a merger poses. I have almost no business background, but even I realize that a merger is a risky proposition. I don’t know how much money each organization has or how much this merger will cost. I am going to discuss this from the perspective of technology and as a person who has been straddling the two organizations.

For a bit of perspective, it’s important to realize that EPUB is older than you may realize. The Open eBook Publication Structure was established by some of the current members of the IDPF in 1999. Back in 1999, most of use weren’t using the Web for that much yet. This format went through some updates, and, in 2007, it became EPUB. The evolution to EPUB 2, EPUB 3, and beyond has been happening ever since. Over time, EPUB has been inching closer and closer to Web standards. At the same time, the Web has evolved significantly. With the shift to HTML 5 in EPUB 3, people started to describe the format as a website in a box and become somewhat frustrated with the constraints of the format. When the IDPF began work on EPUB 3.1 in 2015, there was great interest in creating a version of EPUB that “just worked” in a browser.

At the same time, the W3C Digital Publishing Intererst Group was forming its vision for the future in the form of a Portable Web Publication. Many of the discussions happening in the EPUB Working Group and the DPUB IG were the same. And there was great overlap in the membership. In almost every standards group, there are a lot of members, and a core group that end up doing the heavy lifting. What happened with DPUB and EPUB is that the two core groups overlapped heavily, and we were doing much of the same work in two places. Picture a double Venn diagram with circles for the work being done by the IDPF EPUB WG, work being done by the W3C DPUB IG, and circles representing the people doing the work in each group. You will see significant overlap of all four circles with fewer than 10 people doing the work.

Where do we go from here?

You could say that the W3C should stop working on publishing, but it doesn’t seem like that would help much. We still want to solve issues that are fundamentally problems of the Web, even if they manifest themselves primarily in long-form publications. And, once again, most reading systems are based on browsers.

The IDPF and W3C could continue to create parallel and potentially competing specs. As one of the people in the middle of that Venn diagram, my opinion is that this is not sustainable from a resources perspective. This might be called a risk of diminishing returns. We will burn out. From a technical perspective, creating more than one standard is counter-productive. The logical conclusion then is for the two organizations to work together.

That sounds like a lot of change

That is a lot of change, and changes are full of risk and unkowns. I have no idea how this will turn out. I do know that sitting back and forecasting the worst is helping no one. The IDPF have been in a quasi-partnership with the W3C for about 4 years. The workhorses of the IDPF have become the workhorses of the W3C’s DPUB IG and several Working Groups. If we don’t have more workhorses, then this experiment will surely fail. If you bring your experience, your expertise, your use cases, your technology to the table, then I am optimistic that this will be a successful partnership.