Editor’s note: this piece originally appeared on Medium; it is cross-posted here with permission. The writer is an O’Reilly employee, but he is expressing his personal views. We love his optimism about the future and wanted to share it with the Radar audience.
â€śTHAT COMPANY is destroying my P&L, the entire book industry, and the fabric of civilized society.â€ť
â€śI really like their free, two-day shipping, though.â€ť
Thereâ€™s a lot of tsoris in the publishing community right now over ebooks. Much of it has something to do with THAT COMPANY WITH THE WEBSITE THAT SELLS ALL THE THINGS, how THAT COMPANY has a stranglehold on the book market, how itâ€™s devaluing our literary canon, how it has publishersÂ right where it wants them.
But weâ€™re not just cranky about THAT COMPANY. Other jeremiads include â€” but are not limited to â€” the painfully slowÂ adoption curve of EPUB 3, the demise of beloved sites likeÂ Readmill, theÂ failure of â€śenhancedâ€ť ebooks to gain traction,Â sundry ereader feculence, stagnating ebook sales, andÂ sideloading.
Iâ€™m a cynic by nature, and count wallowing among my favorite hobbies, but after half a decade as a software engineer in the digital publishing space, even Iâ€™ve had enough and am issuing a moratorium on the negativity! Instead, I want to talk about some of the promising trends Iâ€™ve seen develop over the past year that foretell a bright future for the digital book. Forthwith:Â Five reasons for optimism about the future of ebooks.
#1: Ebook standards development is flourishing
I think thereâ€™s a tendency in publishing circles to look at EPUB 3 as some sort of digital-book endgame (e.g., â€śWhen NOOK finally fully supports EPUB 3, I can upgrade my entire ebook catalogâ€ť), when in reality, itâ€™s merely a precondition for the real cutting-edge work to come.
Hereâ€™s an overview of some of the new EPUB specifications currently being developed by theÂ International Digital Publishing Forum (IDPF), most currently in draft status, to do just that:
Dictionaries/Glossaries and Indexes: Marking up reference sections and indexes in EPUB XHTML content documents is challenging, especially if you care about rich semantics (whichÂ you really should). In an index, how do you tag a page reference when content is reflowable, and there are no set pages? In a dictionary, how do you tag the pronunciation information? TheÂ EPUB Dictionaries and GlossariesÂ and EPUB Indexes 1.0Â specs provide canonical semantic inflection guidelines for dictionary/glossary and index content, respectively, via theÂ epub:typeÂ attribute. The Dictionaries/Glossaries spec also defines a requiredÂ Search Key Map Document: an XML mapping of term keywords to their locations in the dictionary/glossary. Reading-system platforms that add support for these specifications can use them to implement features and behaviors that provide an improved reader experience â€” for example, pop-up definitions for custom glossary terms in a medical textbook, or a navigation panel for the index with separate tabs for each letter-group of alphabetized terms.
Open Annotation: A key value-add of digital over print is its ability to foster social reading, whereby ebook consumers can highlight/annotate text content and share this data with select friends and/or the general public. Most ereader platforms have some degree of â€śsocialâ€ť built into their reading systems (e.g., iBooks has pop-up functionality where you can annotate text, or highlight a quote and post it on Twitter or Facebook), but these mechanisms are generally proprietary and not interoperable with other systems. In other words, if you annotate your EPUB in iBooks, and then move it to your NOOK (assuming DRM doesnâ€™t prohibit you from doing so; seeÂ #4, below), your notes are not coming along for the ride. As its name suggests, theÂ Open Annotation in EPUB spec seeks to address this issue by defining a universal data-interchange format for EPUB annotations, based on the W3Câ€™s Open Annotation Data Model. Annotation metadata (name of annotator, date of annotation, publication being annotated, etc.) is formatted asÂ JSON, and annotation content itself is stored within the JSONÂ charsÂ property as an XHTML5 document fragment. Annotation data can be packaged within an EPUB archive or distributed separately.
Widgets: The EPUB 3.0 spec already makes it possible to add â€świdgetsâ€ť (e.g., a graphing calculator for a math textbook, a slideshow viewer for a photography book) to an ebook, by embedding the necessary XHTML5/CSS/JS for the mini webapp. What theÂ EPUB Widget Packaging and Integration specification offers, however, is a standard mechanism for packaging widgets as standalone EPUB archives (based on theÂ EPUB Publications 3.0 spec) that can be distributed separately from the ebook, and for embedding these independent widget modules back into EPUBs. Itâ€™s the start of a module architecture for ebooks, which will make it possible for developers to share/distribute the widgets they make â€” effectively aÂ rubygemsÂ orÂ npmÂ for EPUB. Very exciting!
EDUPUB (Disclaimer: I am a member of the EDUPUB working group): The mission of EDUPUB is to develop an ebook profile based on EPUB 3 expressly geared for educational (textbook) content. The first draft release of theÂ EPUB 3 EDUPUB Profile introduces an initial set ofÂ structural semanticsÂ tailored for educational content (encompassing theÂ EPUB 3 Structural Semantics Vocabulary, as well as additional terminology for learning objectives, assessments, etc.), content model rules for sectioning, and metadata usage recommendations. Future iterations will tackle requirements for teacher editions and analytics.
In addition to the IDPFâ€™s work on ebook standards, theÂ W3CÂ has also chartered theÂ Digital Publishing Interest Group (DPIG)Â to guide development of HTML5 and CSS features to meet the needs of publishers producing digital content. The DPIG has released aÂ â€ślatinreqâ€ť Working Draft to formalize typesetting requirements for Latin character sets as well as documents/wikis around structural semantics, annotation, and metadata.
#2: A new open-source rendering engine for ereaders is on the way
Standards are great, but on their own, theyâ€™re not enough. To effect meaningful change in the ebook space, publishers need to adopt said standards, and ereader vendors need to support them in their reading systems. The past three years since the EPUB 3 spec was released have seen a protracted chicken-or-egg standoff where both publishers and vendors have been relatively content to let the other side act first. Throughout this time period, thereâ€™s definitely beenÂ someÂ motionÂ onÂ both sides, but a tipping point has yet to be reached.
At present, if anythingâ€™s going to break this impasse, itâ€™s going to be the Readium project. Most people probably know of Readium as the organization behind that Chrome plugin that lets you QA EPUB 3 files in the web browser, but theyâ€™re also developing the Readium SDK, a new,Â open-source rendering engine for EPUB 3Â that can power native ereader applications and serve as a successor to theÂ Adobe RMSDKÂ currently in use in many platforms, including the NOOK.
With Kobo, Google, and Adobe counted among Readiumâ€™s membership, it does not seem unreasonable to be optimistic that the SDK initiative is finally going to catalyze more widespread support of EPUB 3 in ereaders. But even if the majority of commercial platforms continue to stagnate indefinitely at EPUB 2, Readium (along with initiatives likeÂ epub.js) represents a key step toward bringing ebooks to the open web, where I believe they can flourish equally as well (if not moreso) as they do in any digital retailerâ€™s walled garden.
#3: The tools keep coming
AtÂ Books in BrowsersÂ 2012, Adam Witwer gave an insightful talk (embedded below) entitledÂ â€śWeâ€™ve got the tools. Letâ€™s start using them,â€ť arguing that those lamenting the lack of quality tooling upon which to build ebook workflows were too focused on a handful of high-level, proprietary apps, and had failed to take notice and avail themselves of the rich ecosystem of open-source libraries and technologies available to better accomplish the same goals. While I enthusiastically agree, I also think, pragmatically, at the time, it was too soon to expect publishers to take up this particular gauntlet. Thereâ€™s a difference between employing a high-level tool â€śout of the boxâ€ť to accomplish a task versus rolling your own app from lower-level components; the latter is degrees of magnitude more challenging â€” especially for firms that donâ€™t have a deep bench of in-house software engineering talent. Iâ€™m sure to many publishers, the message â€śLet them build their own Rails app!â€ť goes over about as well as â€śLet them eat cake!â€ť
In 2012, the higher-level tooling available to publishers was either too print-centric, treating digital development as an afterthought (e.g.,Â InDesign), or, as Witwer noted, created by ereader vendors and/or digital retailers and tied to their ecosystems (e.g.,Â iBooks Author).
A lot has changed in the past couple of years. My job is now primarily dedicated to filling this high-level tool void. Iâ€™ve been working on a team doing backend development for a commercialÂ B2BÂ book authoring and production platform, as well as maintaining anÂ open-source XHTML5-based single-source publishing toolchainÂ (inspired by theÂ DocBook project).
Due to the nature of my work, several times a week, a colleague will reach out to me with a hyperlink to a piece of digital publishing software and ask, â€śHave you seen this one yet?â€ť In the past year, Iâ€™ve explored dozens of platforms targeting different niches in the publishing industry. There areÂ commercial platformsÂ andÂ open-source platforms;Â platforms for scientific journals;Â platforms for making childrenâ€™s books on a tablet;Â platforms for people who like LaTeX;Â platforms for people who like Markdown;Â more platforms for people who like Markdown;Â even more platforms for people who like Markdown. (IsÂ MarkdownÂ the new Word? Or should we stop trying to make Markdown happen? Discuss.)
Point being, in 2014, the tools keep coming, theyâ€™re high-level, and while theyâ€™re not perfect, they keep getting better.Â Let us eat cake!
#4: Might the tide be turning against DRM?
When Tom Doherty, publisher ofÂ Tor Books,Â announced atÂ IDPF Digital Book 2014 that Tor had eliminated DRM from its ebooks andÂ had seen no significant detrimental impact on sales, the audience erupted in a loud cheer.
I took this as a hopeful sign that publishers are perhaps becoming more receptive to the notion that DRM is maybe not so much the solution to safeguarding ebook sales, but in fact the problem. In his 2011 dispatch,Â â€śCutting their own throats,â€ťÂ authorÂ Charlie StrossÂ put it thusly:
“As ebook sales mushroom, the Big Sixâ€™s insistence on DRM has proven to be a hideous mistake. Rather than reducing piracy…it has locked customers inÂ [THAT COMPANY WITH THE WEBSITE THAT SELLS ALL THE THINGSâ€™s]Â walled garden, which in turn increasesÂ [THAT COMPANYâ€™s]Â leverage over publishers…If the Big Six began selling ebooks without DRM, readers would at least be able to buy from other retailers and read their ebooks on whatever platform they wanted, thus eroding [THAT COMPANYâ€™s]Â monopoly position.
In addition to fostering a more competitive ebook retail landscape, I believe dropping DRM from ebooks will help lead to more competition, and thus innovation, in ereader software. When the ebook point of sale is decoupled from the platform on which the product is consumed, customers have the freedom to choose retailer independent of ereader, and vice versa. Regardless of where they purchase their ebooks, they can choose the reading system that has the features they like best â€” e.g., best CSS3 support, best open annotation functionality (seeÂ #1, above), or bestÂ accessibility for those with visual disabilities.
I hope more and more publishers will be swayed by the case against DRM and follow Torâ€™s lead, or at least consider that the benefits DRM affords in terms of theÂ illusion of piracy preventionÂ might be outweighed by unfavorable market effects and diminished customer satisfaction.
#5: Books matter
Yes, books are a commodity. Yes, itâ€™s hypocritical to assert otherwise, to proclaim â€śNo, books are special. THAT COMPANY WITH THE WEBSITE THAT SELLS ALL THE THINGS canâ€™t just treat them like theyâ€™re bags of corn chips,â€ť when youâ€™re the one likening them to corn chips in the first place by slapping anÂ ISBNÂ and a retail price on them.
But no, none of that changes the fact thatÂ books are indeed special. Most of us love books in a deeper, more profound way than we love corn chips. They are our cultural legacy; they endure. (If I survive theÂ zombie apocalypse, Iâ€™m most looking forward to all theÂ spare time to dig in to the huge stack of booksÂ in my queue.)
As publishers, typographers, editors, proofreaders, designers, and now software developers, we help act as stewards of the future of the written word. Nearly everyone Iâ€™ve ever met in the book industry or the publishing-tech start-up space takes this mission seriously, believes it is bigger than the free market. As long as there are people passionate about ebooks (however they manifest in digital form â€” EPUB, app, website, whatever), I have no doubt they will survive even the most nefarious corporate machinations, including radically driving prices down to make books more affordable toÂ people all over the world.