Yesterday, I wrote a post on ebook silos and missed opportunities.
Some people seem to be missing the core criticism in the post. The problem, as I see it, is in the infrastructure and in the market we have in place. This is not a lament for how lazy people must be or how stupid existing developers are for not implementing these things already.
Existing ebook reading apps are bland out of necessity. The ones implemented by silo owners need to appeal to and be useful to everybody. They can’t not be generic. Specialisation is not an option when you need to appeal to the lowest common denominator.
The independents have a different problem. They need to both implement detailed support overly complex file formats and they need to target one of the silos (generally Adobe’s playground, which is a fraction of the overall market).
Because the market involved is so small and the end result is that their apps have to have broad appeal. A specialised app targeting a fraction of a fraction of a market is not economically viable when you are employing a team of developers.
The solution to this conundrum is both simple and difficult (like so many simple things are).
Generally speaking, the way to promote variety in any given software genre is to make sure that it’s possible for a solo developer or a small team of developers to create and maintain an app in the genre. Only a solo developer (maybe a duo) can hope to make a living by addressing a fraction of a fraction of a market.
I’m convinced that, if a solo developer found a way to implement one a specialised ereader that was useful and valuable to readers, they’d be able to make a decent living from said app.
One such example is Marvin. It’s an ereading app that focuses on configurability, text analysis, Dropbox support, proper annotations export, and a lot lot more. It is quite different from most other ebook reading apps in the market and is quite excellent. It’s not for everybody, but it is unique enough for there to be a large group of people who both have been waiting for an app like this and are eager enough to use it that they are willing to break the DRM on their existing library to use it.
Anybody who is in any way dissatisfied with their current ebook reading app owes it to themselves to try it out.
Which brings me to the compromises needed to make the byzantine mess that are ebook file formats manageable by a small team. Marvin offers a few pointers in that direction:
-
No DRM support.
-
Only EPUB 2.0 support to begin with.
-
Limited support for ebook design and styling, which is okay for a small app because all of its users opt in to no styling. They know what they are getting.
-
No support for video or audio.
-
No FXL support.
-
No PDF support.
-
No attempt to achieve full spec coverage but instead a laser-like focus on implementing features that crop up in customer feedback.
Now, Marvin owes a bit of its success to luck, but I still think it offers us hope for how things could go in the future. Solo developers and small teams will experiment with apps. Some will fail. Some will succeed.
—Couldn’t Readium SDK help?
Possibly, but that’s not what it’s for. As I see it, the primary goal of the Readium SDK is to get large corporations who are competitors to collaborate on improving their support for the various incredibly complex flavours of EPUB (2, 3, FXL). This is hard enough without trying to address the needs of solo developers as well.
The cost of acquiring a license usable in a commercial product bears this out. After September you need to pay $60 000 to join and get a license or you need to contribute work and source code. Both are going to be way beyond the means of a solo developer attempting the already difficult and risky task of a specialised ebook reading app.
And that’s okay. Readium SDK has an already unenviable goal (achieve full format support in all major big-corp generic readers). Maybe once that’s achieved and all major apps have shipped with full EPUB3 support, maybe then the foundation will reassess the licensing terms. Before then they are more than justified in focusing on trying to solve the problem they set out to solve.
—What would really help?
More publishers going DRM-free would help a lot, especially those catering to less price-sensitive specialist subjects. That would open up the market for a developer to enter with a specialised app catering to those readers.
In fact, O’Reilly’s pioneering work with DRM-free might well be an opportunity for a developer-oriented ebook reading app, one with built in REPLs and consoles for various languages. Imagine being able to run and play with example code in a variety of common languages from a dev ebook just with a tap. Imagine having access to each platform’s documentation as you read a book on a specific problem area; having access to the official documentation for a method with just a tap.
More comics publishers following the example of Image Comics (they sell DRM-free comics direct, not enough of them yet, but it’s a start) or Thrillbent might open up the field for a specialised comics-oriented ebook reader, one that only supports FXL ebooks and PDFs. They might even be justified in only supporting PDFs and CBRs.
I’m convinced you don’t need full EPUB3 or DRM support to create an excellent app that is sufficiently useful to enough people to be a viable business for a tiny team.
The app would have to be specialised and solve very specific problems for very specific group of people with very specific needs. Just making an ebook reader with cool and unusual features isn’t going to work again, even if it did work for Marvin. You need to both delight and remove pain. Delight alone will not do.
I’m not saying it would be easy. It’s clearly a difficult problem. But it would be interesting.