Proprietary ebook formats versus DRM

Micah made this here statement on Twitter the other day, articulating neatly what a lot of us have been thinking for a while now:

It is not random that Amazon does not use EPUB. Consumers dislike DRM, but are all right with proprietary formats. > > -- Micah (@micahsb) [August 17, 2013](

Very true.

It’s something that has bothered me for years and years. I spent years arguing against the use of proprietary formats in interactive media academia (they were unnaturally fond of what was then Macromedia Director). Then proprietary ebook formats became my bugaboo. But tilting at windmills hasn’t gotten me anything but heartache and a reputation for being a bit of a jerk. I’ve now accepted the fact that proprietary formats are always going to be with us. If it doesn’t bother the buyer it doesn’t bother the buyer, simple as that. But I’ve often tried to figure out a good framework for discussing and analysing this dynamic between proprietary and standard formats. What’s the best way to think about this and find a way to combat proprietary formats?

One angle is that standardisation lowers cost for producers and lets them make more interesting products, but that’s not likely to sway Amazon who value the flexibility and power of an owned format and don’t bear the costs of production. And customers generally don’t care since they might not even benefit at all from lower production costs (some producers would just use the opportunity to increase their margins).

The other angle is interoperability and modularity, which increases the flexibility and value of the ecosystem as a whole. But that also changes the power dynamic in the ecosystem in less than predictable ways, something that the big dogs in the system won’t like. When you’re the biggest there’s no such thing as good unpredictable change. Amazon’s system is mostly vertically integrated anyway, leaving little room for interop. And many opportunities for really lucrative interoperability have been throttled in the crib by Apple’s stringent iOS policies. (Why ebook vendors aren’t doing more interesting things on Android where they aren’t held back by the platform owner’s policies is beyond me, but that’s a blog post for a different day.)

Then I stumbled upon the super obvious way to look at the problem. So obvious that it’s embarrassing that I haven’t pursued it as a serious argument before. Yeah, I know, I can be thick sometimes.

I didn’t hit upon it directly, but Micah’s above tweet did remind me of something I’d just read. From The Technique of the Novel - A Handbook on the Craft of the Long Narrative by Thomas H. Uzzell:

> > Ask any novelist in trouble with his plot what he intends the effect to be and he will answer something like this: “I intend to show that love between two such people is impossible.” This is material, not effect. Effect would be, say, the pathos or tragedy felt by the reader in a narrative about two people vainly attempting happiness in marriage. Amateurs in any art talk in terms of materials; professionals, in terms of effects. > > > > Effects are subjective experiences; materials are objective experiences. Effect is response; materials are stimulus. Effects are the emotional qualities of things. > >

It’s features versus benefits all over again. In this context the materials the novelist uses are the features and the effects on the reader are the benefits. A writer should not think in terms of the materials (what you write) but in terms of the effects (how the writing affects the reader).

It’s ties into an adage from marketing, features are meaningless to the buyer, they need to be told how they benefit. But if there’s one thing I learned from my friends in marketing back in my software days it’s that this principle applies everywhere. No marketer can gloss up a Frankenstein monster app pieced together out of departmental hobby horses. Most software is a confusing turd made out of disparate components by a bunch of socially inept developers who can’t think in terms of user benefit. Moreover, they don’t really care about the user. Most developers think in terms of abstract beauty of the code and architecture, conceptual integrity of the components, and of ticking of checkboxes in a feature list. They don’t give a toss about the experience unless you can itemise it as a development checklist.

Bringing this back to ebooks…

Those who are trying to shift the market away from proprietary formats can’t try and market their way out of the problem. A tactic used by some is to harangue critics like me for pointing out important flaws in the EPUB ecosystem, but silencing critics won’t address the flaws. It will not change the fact that as a whole, the EPUB ecosystem offers readers fewer benefits than the Kindle ecosystem.

Offering equal benefits will not be enough to sway consumers. To change the status quo you need to outclass Amazon massively in benefits.

And in case you were wondering, Readium SDK is a feature, not a benefit. It’s what you do with it is what’s going to count.

My suggestion is simple: focus on the benefits Amazon can’t replicate.

If a reading app feature turns out to be a competitive advantage, Amazon is likely to copy it with ease.

Rendering or interactivity features aren’t likely to make a difference because sensible publishers will focus on making their titles cross-platform compatible. Amazon’s rendering and interactivity features are going to dominate as the lowest common denominator.

You can’t beat Amazon on selection or price. The Kindle’s ease of use is going to be hard to top. Their customer service is far above what others offer.

The one thing the EPUB ecosystem can offer that Amazon can’t, is tight interoperability between unrelated ebook vendors, services, and reading apps.

That’s it. That’s your only card to play.

Basically, what I want is for the EPUB side of the ebook market to put their money where their mouth is. So far, they only seem to support EPUB because it isn’t Amazon and don’t take any advantage of the biggest benefits of standardisation. Namely, interoperability and modularity.

As I said, the one major advantage of a standard format is interoperability. The obsession ebook vendors have with silos and their antipathy towards easy interop is crippling their only competitive advantage over Amazon, the one big thing they can use to increase the benefit a reader gets from their ecosystem. Being able to easily mix and match reading apps with retail services and have them integrate tightly is something Amazon can’t replicate.

Copying Amazon’s vertically integrated stack when your only sensible strategy is interoperability is, quite frankly, insane.

With the way B&N, Kobo, Google, and Apple have been behaving, it’s a miracle that Amazon still doesn’t own more than 80% of the market.

Then again, what little headway they have made was largely due to illegal collusion.

B&N, Kobo, Google, and Apple separately can never compete with Amazon on price or range.

If I could hook all of their ebook retail services to Readmill so that all of my purchases are automatically added to my library, then I, as a consumer, can begin to treat them as a single market. Not having to worry about whether any given ebookstore is compatible with my chosen reading app makes me less resistant to try them all. Impulse purchases become more likely.

Together they can offer a competitive price and range. A book that isn’t available in Kobo might be available in B&N, Google Play, or the iBookstore. Proper interoperability will convert more readers away from the Kindle and so increase EPUB sales, to everybody’s benefit.

And, as I’ve been saying, the benefit is what counts.