My last word on DRM

Trying to change a major publisher’s mind on DRM is a lost cause. That’s why even though I disagree with IDPF’s DRM efforts, I can only hope that their work will result in the wholesale adoption of a completely ineffective and useless DRM technique and bring us into a de facto DRM-free world.

(You could argue DRM isn’t a problem for existing consumers. That’s true, but only because we just buy from Amazon.)

What I hadn’t expected but has become abundantly obvious over the past year is that the publishing industry has a pathological preoccupation with controlling the reader’s actions. I had originally expected publishers to respond to reason, logic, and ruthless capitalistic ROI calculations (all of which weigh against DRM). But those who favour DRM do not respond to logic. When nailed on one argument they slip over to another:

No no no, piracy isn’t a problem, it’s uncontrolled sharing

Po-tay-to po-tah-to. When it becomes hard to find evidence that piracy affects revenue the response is to rebrand it and claim that it’s still a problem.

I don’t quite know how to deal with an irrational obsession on that scale. Obviously, if piracy is cutting your revenue, that is a bad thing. But so much of the concerns around piracy are indistinct and vague—piracy worriers can’t articulate specific business consequences beyond ‘lost sales’ hand-waving with no data to back it up.

My own views on piracy, as a result of having worked in the software industry for a few years, is that, insofar that it’s an actual revenue drain, fighting it is largely a lost cause. As games developer and publisher Jeff Vogel has been fond of pointing out: if you’re selling a digital product, by definition everybody who decides to give you money is an honest person. The dishonest people will just pirate your product without a care or worry. Heavy-duty, iron-clad DRM can’t force the dishonest to buy and imposing it would have massive detrimental results both for the honest reader, the author, and the publisher (but not the dishonest reader). The dishonest would rather simply go without than pay. And even if you could force them, they’d be the customer from hell, overloading support channels and public forums with Olympic level whining.

So why worry about them? ‘Pirates’, even if you can prove they exist and affect revenue, which most publishers discover is hard, are a non-factor from a business perspective, about as relevant to your sales as Mac users are to a Windows developer. They simply aren’t a part of our market. This fact is also a big part of the reason why measuring piracy and the impact of piracy is so difficult. It’s like trying to measure the GDP impact of a Buddhist chanting. Non-participation isn’t measurable. Estimating the loss from non-participation is little more than science-fiction.

I wouldn’t mind talking about piracy to publishers if they discussed the issue in the same logical, matter-of-fact, manner that most indie software developers discuss it. But they don’t. What publishers mean when they say ‘piracy’ is more of a general worry about change and new technology and so most of them are extremely reluctant to discuss the details of what they believe and fear.

In publishing, the piracy concern is a superstition, magical thinking driven by a hope that the digital space is fundamentally inhospitable and the old times will be proven to be fundamentally superior to the new. The believers resist all attempts to empirically verify whether there is or isn’t a problem. Arguing with them is like arguing with a creationist. They don’t want proof, even if it is in their favour, because what they want is blind faith. What is worse is that many are using the fear of piracy as an excuse for not entering interesting new markets, which is a loss of opportunity, money, and revenue more certain than any threat that stems from piracy.


The real problem publishers have

Tracing the problem right down to its roots, it’s clear that the publishing industry’s behaviour towards readers (not their readers since we’re talking about the author’s readers not the publisher’s) comes from the same source as their behaviour towards authors.

Just as with authors, who they saddle with fundamentally unfair and insulting contracts, publishers simply have a disdain and fear for readers, preferring to let proxies like bookstores take care of all direct contact with them.

I see no other way to explain their behaviour. You just don’t do these things to people you like (readers or authors).

DRM is an extension of that disdain and fear. It is intrinsically hostile to the reader. It’s value isn’t supported by any evidence of substance. Publishers are willing to harm their authors’ readers just on the possibility that they might be doing something they disapprove of. There is no evidence of harm to the author or the publisher.

The question whether sharing or piracy actually takes place or whether it will affect publisher revenue is clearly irrelevant, otherwise they would have abandoned DRM years ago.


DRM will never be harmless even if it’s useless at preventing piracy or sharing

Welp.


ETA:

Outside of the fundamental disrespect for the reader it represents, there is one major business reason why DRM is a very bad idea for publishers:

It involves inflicting a recurring technical, infrastructural, and administrative cost on all of their sales in perpetuity to solve a problem they can’t prove exists. By tying their entire catalogue, in perpetuity, to the fate and competence of a single external service provider (whoever provides the DRM solution) publishers are taking a business risk of unfathomable proportions. These are the kinds of risks that sink large companies.

That anybody would make this sort of decision without hard evidence to back it up is utterly mind-boggling.

Just say no to ebook CSS and JS

You think I’m joking?

One of the biggest issue publishers face with ebook production is the somewhat adversarial attitude ereader and app vendors have taken towards publisher stylesheets.

Publisher styles are largely overridden by default at Kobo, B&N, and in Aldiko. Even iBooks requires you to slot in a set of proprietary meta tags before it respects your font and image decisions.

Problems with vendor stylesheet overrides:

  • They are inconsistent from platform to platform, vendor to vendor, and device to device.
  • They are partial and only cover a portion of the meanings and structures you can express in even basic HTML.
  • Some of them are only applied when the ebook is loaded through the vendor’s service, not when opened directly by an app (I’m looking at you Kobo).
  • They make regular CSS unpredictable. CSS is a complex language so mixing regular CSS in with a set of aggressive overrides can have unforeseen results, like low-contrast element colours, invisible text, badly sized or even indecipherable images, and more.

Vendor overrides are one of the biggest time sinks in ebook development. Because they are only partial, we have to include our own styles, but the mix is often unpredictable. The number of basic things that break, seemingly randomly, in Kobo, iBooks, or whatever random RMSDK-based ereader you have this week is too high to be disregarded. So, we test, and fix, and test, and fix.

(The simpler your stylesheet is, the less you have to test, obviously. Which is a decent motivation to make your styles as minimal as you can. Unfortunately, too many publishers and authors are dead set on forcing ebooks to mimic the styles of their print edition, filling it with all sorts of stylistic crap that’s patently inappropriate to digital. I draw the line at drop caps, which just can’t be done properly in an accessible way in digital. They are a trite Victorian affectation that compromises readability.)

To make matters worse, a lot of the ebooks publishers are releasing are full of insane crap that even the worst hack web developer wouldn’t dream of trying to pull off. Like making every element of a book either a P or a SPAN.

Which is a practice that makes the noise people at the IDPF make about non-xml HTML5 being tag soup pretty ridiculous, XHTML is just as capable of non-semantic tag soup as HTML. Oh, and it also makes any claim of EPUB3’s superior accessibility rather silly as there’s no way for screen readers to tell which P is supposed to be a heading and which is actually a paragraph. Complex accessibility features are meaningless if all the publisher gives you is a indistinct blob of tags.

Then there’s the tendency of some systems to output ebooks where the only styles come in the form of style attributes on every single element, making any attempt to work with the styles of the ebook impossible.

The biggest problem with these ebooks is that everybody thinks they are okay because they look okay when opened. Headings are bold and large, because that’s a bit of CSS most vendors respect. Quotes are indented. Italics are italicised. The basic structure of the ebook looks preserved and the stupid crap in the ebook is ignored. Vendor overrides basically work for crap ebooks. From both the publisher’s and the vendor’s perspective this is a success. The vendor is happy because an atrocious ebook file is made readable and a large portion of their inventory remains sellable. The publisher is happy because they are short-sighted fucks who just got away with not giving a flying toss about ebooks and feel fine about making zero investment in the biggest growth area in publishing since the introduction of the paperback (yes, they are morons).

But, they are both wrong. That ebook is broken and needs to be fixed. It’s inaccessible to screen readers. It’s an opaque blob to text analysis like Amazon’s X-Ray. It’s an indecipherable mess to search engines (which are going to be damn important in the future). An ebook that doesn’t have structure is broken and unacceptable.


I propose a conditional surrender

The more I discover about existing publisher ebook production processes, the more I talk to people ‘on the inside’, the clearer it becomes that a substantial portion of existing ebook inventory is quite simply rubbish. No structure. Crap stylesheet. Broken markup.

So I propose that ereader vendors simply turn all publisher styles off and never even consider enabling javascript. Considering how much of a mess these clowns are making of basic markup and CSS, how likely do you think it is that they can do javascript safely?

Not bloody likely at all.

In exchange, what we need you to do is to improve your built-in stylesheets. We need you to support common markup practices like figures and captions, headings and subheadings, horizontal rules that don’t look like a 90s flashback and so on. Best if you support them both in markup patterns and as class-based microformats.

WordPress’s classes for captions and images with .alignleft .alignright and the like are a good start. As are common microformats such as hAtom and hNews.

And if you can support basic HTML5 structures such as:

<header>
    <h1>Heading</h1>
    <h2>Subheading</h2>
    <p>Tag line</p>
</header>

Or:

<figure>
    <img blablabla />
    <figcaption>The image's caption</figcaption>
<figure>

If you manage to render every bit of those patterns appropriately (e.g. subheadings, tag lines, captions, etc.), that would be nice as well.

Oh, and don’t forget some nice styles for tables. Standard syntax highlighting for CODE elements would be a bonus.


–You aren’t serious?

I absolutely am. The key here is a full-featured built-in stylesheet that correctly styles all major structural elements of the book. This would mean that the only thing you need to do to make sure an ebook is okay is to load it and see. If it looks like a heading it will be a heading, etc.. Everything will be what it looks like. Books with crap, inaccessible, structure will have crap inaccessible styles and so be exposed immediately. Books that are properly structured will look as great as the vendor and reader (with their chosen settings) intended.

It would do to ebooks what RSS and SEO did to websites.

(In case you weren’t around in the web industry over a decade or so ago: the structural quality of web development tools and CMSes didn’t begin to improve until client apps that required structural quality began to be important, namely RSS/Atom readers and search engine crawlers. Before that most tools generated markup that was an atrocious mess of tables and font tags. Any publisher who thinks search engines won’t be important to ebooks is very mistaken.)

Ebook production would be dramatically cheaper and simpler, largely consisting of making sure that the structure of the ebook is preserved throughout the editorial process. Little to no testing required and people can focus on bikeshedding the cover design instead.

—You can do this already by just not including any styles in your book.

That only solves my problem (production costs) and it only solves it if my book is only plain text with a few headings, italics, bold, and maybe some quotes. Existing built-in stylesheets are inadequate to the job.

It doesn’t solve the problem of how to motivate publishers to improve their ebooks without making them unreadable. By robbing the faux-headings and the like of their styles you surface the blobby soupy nature of the book without destroying it. And knowing how crap the ebook in general will be, it’d probably still look a lot nicer than if you enabled all styles and let the publisher’s incompetence shine through.

The built-in stylesheets provided by vendors cover too little of what an ebook needs. Add in figures, captions, table styles, code highlighting, some structural awareness—headers, footers, article, and the like—a few microformats, and some nice horizontal rules and we’d be mostly sorted.

Then, once you got your built-in stylesheet in order, just turn off all publisher CSS completely and tell everybody to go and fix their fucking ebooks.