Here are some reasons they might have done these conversions.
- They believed that ebooks would be profitable, especially if low-quality conversion was done, making their fixed costs negligible.
- They were skeptical that ebooks would be profitable, but low-quality conversion was so cheap that it was worth hedging their bets.
- They feared Amazon's reprisal against their paper sales if they failed to get on board with Kindle.
I used to rail against low-quality conversion, to whoever would listen: mostly my poor wife, since she's more or less a captive audience.
Then I had a humbling realization: publishers did exactly the right thing, in opting for low-quality conversion.
But I haven't become too humble: I think they did the right thing for the wrong reason.
They think they converted cheaply and now they're done.
I think they did the right thing to convert cheaply, but they should just view those conversions as version 1.0.
Another way of putting this is that publishers need to start treating ebooks as software, since ebooks are software.
- Software has bugs that need to be fixed.
- Software needs to evolve as its environment changes.
To be fair, nothing in their previous, paper-based business would have prepared publishers to understand the dynamics of software.
Heck, software is such a young, changing field, that half of the software companies out there don't understand the dynamics of software. So why would I expect publishers to do better?
Then again, as Kohelet reminds us Jews every Sukkot, there is nothing new under the sun.
Publishers have, over the last four centuries or so, developed quality control processes that
- result in low initial defect rates and
- allow for fixing the few defects that do creep in.
So, publishers don't know anything about the particulars of software, but they do know something about quality control of initial releases and managing bug fixes in subsequent releases.
In paper publishing, a release is analogous to a printing.
Quality control of an initial release, in publishing, includes processes such as proofreading, possibly done multiple times on proofs of increasing finality. Managing bug fixes in subsequent releases includes processes such as receiving reported typos and fixing those that merit fixing.
One might think that publishers' quality process savvy would have ported well to the world of ebooks.
Sadly, this could hardly be farther from the truth.
As far as I can tell, these quality control processes almost never happen to ebooks. This is especially puzzling in the case of bug fixes, since the ebook medium drastically lowers the cost of reporting and fixing typos.
Paper books don't have a button allowing a reader to report a typo to the publisher. But, Kindle books might as well not have such a button, since, in my experience, publishers hardly ever act on such reports. I made hundreds of such reports before realizing that it is virtually pointless to do so.
To fix a typo in a paper book, a publisher has to not only fix the typo but wait for the next printing, which may never happen if the book's popularity falls off. In contrast, for an ebook, there is no such thing as a printing, only releases. A new release can be made at whatever frequency the publisher deems appropriate. Too bad virtually none of them seem to take advantage of this capability.
But, let's get back to my major theme here: low quality conversion.
If the initial conversions of ebooks had not been of such low quality, the typo correction process would not be so important.
But, as I must calmly remind myself when I start foaming at the mouth, I'm now trying to give publishers the benefit of the doubt, admitting that an initial low quality conversion was the right thing to do.
Low quality conversion allowed publishers to quickly enter a new market with low initial investment. What's not to love about that?
So, is all I'm advocating that publishers take reported typos seriously and start releasing 1.1 versions?
I'd like to advocate for something more radical.
Yes, start taking typos more seriously, but, even more importantly:
It's time for version 2.0. In other words, it is time to re-convert, the right way. Or at least a better way.
It may be painful for publishers to hear this, since most are still in the middle of, or have just completed, the conversion of their back catalog. (Luckily, I don't think publishers or anyone else reads my blog, so these painful words will not be heard.)
In software, it is not at all painful to hear that what you do when you complete version 1.0 is you get to work on the next version. In fact, there is often a pipelined development process where work on 2.0 is already well underway when version 1.0 is released!
These 2.0 versions should
- Be high quality, e.g. avoid OCR if possible
- Be modern, i.e. avoid concessions to the limitations of early e-readers
"Be modern" means no more concessions to the limitations of early e-readers. Publishers need to make the same hard calls that software companies make, with respect to leaving certain users behind who do not (or cannot) upgrade their hardware or software. Perhaps Amazon and other vendors could ease those users' pain by still making the old version available, but I know of no current mechanism for this. In the big picture, I'm sorry to say it but publishers can't let a few users cause their books to be stranded in a format that was the right thing for one particular time but is not the right thing, going forward.
Here I'm going out on a limb, but I think ebooks are where books are heading. I'm not saying that paper books will die. They will probably always have a place. But I think that in the future, the roles of paper books and ebooks will flip: the ebook will be viewed as the canonical version of the book, and the paper book will be viewed as a convenient alternate form of this canonical version. If I'm right about this, the initial, quick-and-dirty conversions that publishers have done are not appropriate for a lasting, canonical encoding of a book.
Some of the concessions to the limitations of early e-readers that are my pet peeves are as follows.
- Images used instead of Unicode.
- Raster images (e.g. JPEGs) used instead of vector images (e.g. SVG).
- Failure to take advantage of various EPUB 3 features.
I guess this is sort of an abrupt ending, but that's it for now.