Readium and other good intentions
Update: It’s clear from updates, both on the Readium website and their forum, that the primary goal is to work on WebKit itself and deliver library-based components. I’ve struck out the passages below that were wrong.
Update 2: I’ve added a comment from Bill McCoy Executive Director – International Digital Publishing Forum (IDPF).
One of the classic acts of a political party in trouble is to announce a tax cut. Percentages, large dollar amounts, and a whole lot of numbers are chanted by the beleaguered politician as if it were a chant that warded off electoral failure.
These numbers, concrete as they sound, are rarely substantiated by fact because they aren’t fact. They might be facts in the future, but they aren’t facts now.
Not yet, at least.
You see, one of the problems with pushing forward with big plans, popular as they may be with the electorate, is that the electorate isn’t the system. The system has needs and a law won’t be passed unless it fulfils those needs.
The politician may be honest in his plan to cut that tax but he has to deal with treasury, lobbyists, other politicians, his friends, his enemies, his political allies. For a law to pass you need the support of so many people and so many organisations.
Before you know it, the tax cut only applies to a minority of people, most of whom happen to belong to a demographic with strong influences among the participants in the political process.
It may be cynical to say this, but it’s very hard to convince participants in an extended process like this not to act merely in their self interest.
Readium – a new open source initiative launched by the IDPF with the support of Adobe, Google, Kobo, and B&N – is like that tax cut; a popular, possibly sensible, good intention that will go only as far as its participants let it.
What is it?
The first impression of Readium is that it will be a foundational engineering project that will build the difficult, but essential, building blocks which will then be reused by the project’s supporters.
This pitch, nice and cuddly as it sounds, is the ‘I will cut your taxes by X’ part of the process. It is what saying ‘increasing implementation consistency’ and being able to embed Readium components in other apps implies. It may not be what the project is intended for, but it is what the website’s copy implies.
This is what a lot of people will interpret the project to be, which in turn will turn into our equivalent of the ‘this is what this tax cut will mean to you’ speculative nonsense that journalists churn out after a politician’s announcement. Extrapolating fantasies from vague declarations is what pundits and journos do best and I doubt they will let us down this time.
Note: Turns out I’m the one wrong about this. Apologies.
Readium, judging from the project’s goals and what the FAQ says and judging from what the proof of concept prototype, is going to be a javascript framework built on top of Webkit.
I don’t see, personally, how they can implement a full-featured ePub engine (with all of the musts and shoulds) in javascript.
That isn’t to say that javascript-based implementations are a bad idea. They aren’t. They are a very good idea as both Ibis and Monocle prove. But they are always going to face limitations based on their execution context which are going to prevent them from implementing every optional feature of the specification.
And if a javascript-based implementation isn’t the plan, then shipping a half-arsed one1 as a proof of concept was a very bad idea.
A technical project needs to be technical
As an open source project, Readium lacks a concrete outline of its specific technical goals. Does it intend to be a low-level ePub rendering engine, in effect be a webkit branch that is extended to deal with ePub? If so, say that.
Use concrete terms. ‘Building on’ can be interpreted in too many ways for it to be useful technically.
Say something like ‘the Readium project aims to deliver a webkit branch that has been extended to deal with the needs and features that are unique to ePub3’. Outline specific technical problems that need to be tackled such as:
- How will a paginated view be implemented natively in webkit’s rendering engine?
- How will webkit’s API be extended to deal with media overlays, content switching and epub:trigger (just to mention a few things)?
- How will the webkit library be modified to handle ePub specific security and code execution issues? And don’t pretend there aren’t any.
- What components will the project deliver? Say so in exact detail.
You don’t have to have answers to any of these questions but you do need to list the questions that need answering. This is an open source project after all and you have to tell the participants exactly what questions they need to be tackling as a part of the project.
Wishy washy, vague and woolly marketing statements are useless when it comes to driving participation. Be technical and tell us, exactly, what the project intends to do.
And, no, you haven’t told us yet. At least I didn’t find anything resembling concrete technical statements on the website.
Remember, webkit first launched with working code, not a ‘proof of concept’.
Assuming the best
If we do take it as a given that they are going to work on implementing proper, rendering engine-level, support for ePub and not just faff around with hacks, then we still run into the participant issue, just like our proverbial tax-cutting politician.
Starting with zero code, since none of the participants seem to be donating parts of their proprietary efforts and the ‘proof of concept’ doesn’t seem to have a single line of engine code, the project will have to navigate the conflicting interests of Adobe, Kobo, B&N, Bluefire, Copia, Google, and others.
And even if it manages to deliver a fully-featured ePub3 rendering engine that doesn’t mean any of the supporters will use that engine in any of their projects.
Why? Because they aren’t limited by what they can engineer.
At least three of the supporting organisations (Samsung, Google, and Adobe) have shipped extensively modified branches of the webkit engine: Samsung in the excellent browser engine that comes with the bada OS; Google, twice, in the Android browser and in the Chrome browser; Adobe in the AIR desktop runtime.
The limits aren’t in what they can engineer but in what they can ship. Apple is unlikely to let an ereader app ship on iOS with full javascript support.
Why? Because an ereader app with full javascript support is an app platform as well as a publishing platform and app platforms threaten the very existence of their App Store.
So, the iOS version would require an entirely different codebase and feature set. That is, it wouldn’t be a full-featured implementation. That’s two codebases, three if you think the Android version won’t share anything with the Chrome extension.
Three codebases that share little aren’t a single project. They are three projects that share management.
The decision to support the entire ePub3 spec is made on the business level and will be governed by the corporations’ existing value network. Some of these decisions will be governed by platform risk, such as with Apple’s App Store, others by cost. Unless these companies have decided on the business level that full-featured, compatible, standard, ePub3 support is a selling point, that support is unlikely to end up in a shipping product.
We’ll see what happens. If they contribute a lot of code, then we can be optimistic.
Other issues
Not choosing a reference platform for the reference implementation is a mistake. ePub3 is extensive enough without having to deal with a mess of cross-platform issues. Pick one, like Android, to be the main target. Develop everything with cross-platform support in mind, but having a single target platform does wonders for focusing development. Leave it up to the participants to maintain ports to other platforms. It’s what kept webkit alive in the early years when it was only used by OS X. Cross-platform support can come when the project has proven its worth.
Implicitly optional features like XMLHTTPRequest are useless if you can’t deliver basic things like full-bleed backgrounds.
Supporting optional CSS modules is pointless if, like Readium supporter B&N, you override the ebook designer’s stylesheet by default.
Implementing full support for ePub3’s multimedia features is meaningless if implementations can’t agree on what codecs to support.
No amount of javascript support can address the needs of hypertext in ePub if the reading system doesn’t support non-linear chapters using linear="no". Without it a whole spectrum of ebook features, widgets, and UIs are ruled out.
And without extensive documentation, any rendering engine, no matter how full-featured, is just going to make the lives of ebook developers more difficult, not less.
Shipping a development platform without public documentation like most ebook reading system vendors do is sheer insanity.
Most of these issues aren’t solved by a reference implementation. Some of them wouldn’t even be solved if everybody shipped the same implementation. Deciding to overrule the designer’s stylesheet isn’t a technical decision but a business decision. An open source engine can’t force vendors to document the features they support. Just look at the varying levels of documentation on the dizzying number of browsers based on webkit.
Don’t be a killjoy
I know I am being too harsh.
Even if Readium ends up being just a reference implementation it would still be useful.
If it delivers a full-featured ePub rendering engine based on webkit, so much the better. A component like that would enable wondrous things in the marketplace. It’d do more to enable new, competitive entrants than it would help the project’s big supporters like B&N, Kobo, or Adobe. But, hey!, how nice of them to help disrupt themselves. Class.
But, let’s not pretend it solves the ePub fragmentation problem. You don’t solve the problem of too many differing implementations by adding a new one. The format fragmentation problem is caused by the value networks that drive product development at the various vendors, not by technical issues or implementation problems.
Support and extensive participation in the Readium project could be a sign of a change in values, but the only true signal is shipping code and published documentation.
This announcement comes with neither.
Comments
Bill McCoy (Executive Director – International Digital Publishing Forum (IDPF)) wrote this here thing:
Baldur, I totally agree with you on two key points:
business considerations not engineering will be the determinant of a number of decisions about EPUB 3 feature support. For example, whether a given ebook distribution channel permits e.g. remote data access from JS (which impacts control over valuable analytics data and direct communication with readers).
eReading app capabilities on iOS is subject to unilateral control by Apple and it would be risky to e.g. count on EPUB 3 JS features that go beyond what iBooks can do being permitted to ship there.
But I think you missed the boat on several other points, perhaps misunderstanding what Readium Project is actually doing:
for companies who have already made the business decision to robustly support EPUB 3, Readium doesn’t change a thing, strategically. It’s just tactics: a way to collaborate to help with the “when” (and, perhaps, the “how much”) while giving publishers a tool to prep and check EPUB 3 content in the meantime. Concretely, its primary aim is to help ensure we get widespread EPUB 3 support in the market this year, with a higher level of initial functionality than would otherwise be the case.
iBooks already has quite a lot of EPUB 3 features including significant JavaScript support. And, not every solution has to run on iOS.
“You don’t solve the problem of too many differing implementations by adding a new one”. Well, sure, no more than with standards: http://xkcd.com/927/! But, we have a situation where a dozen folks recently decided to implement their own EPUB 3 engines via WebKit (a la Apple iBooks). I think it’s a reasonable goal for Readium to coalesce some of these implementations and make the overall result more consistent and capable. And, while Chrome and Safari are quite different, I do think the shared use of WebKit has significantly reduced the problems many of us have personally suffered through of HTML/CSS incompatibility, by creating some sharing and setting a higher bar for other implementations - creating a “race to the top”.
“publishers liberation” is one aspect of this. A fully-featured EPUB 3 implementation can be wrapped in an app shell with PhoneGap, or combined with a publisher skinned browser extension. This can give publishers direct distribution options free of all channel fetters. This option as well as just general availability of robust EPUB 3 support can help set up a “race to the top” among eReading apps & content distributors, as we now see with browsers.
Your post included some criticisms of the proof-of-concept prototype Chrome browser extension. The entire effort is all of 5 weeks old, and “proof-of-concept prototype” is the operative term. And, the suggestion that going public early was a bad idea is contrary both the spirit of open source collaboration and the principles of lean startups. But it’s a fair point that we could have communicated the initial status more emphatically and we’ve tried to address that on the readium.org site.
And it is a half-arsed implementation. Slow as molasses on a rather newish laptop, ugly kitsch skeuomorphic UI obviously done without any input from a ebook designer on what they want, and buggy as hell. It’s an awful first impression. ↩