A Few Notes On Minstrel

So, ReadBeyond published the source code of Minstrel, our Android/iOS hybrid reading app.

For the sake of clarity and transparency: ReadBeyond (more precisely, myself) will continue to maintain an official, stable version of the app under the original name Menestrello ("Minstrel", in Italian), available on the App Store and on Google Play. Apart from the app identifier string, the source code is the same.

The official Web page of Minstrel describes some motivations behind the publication of the source code. In this post, I want to dot some i's.

The Winter Of My Discontent

First of all, as I wrote elsewhere, let me note that I am not happy with the current status of the project, especially because of the lack of documentation and the long list of shortcuts taken, but let me state it this way:

you got more than what you paid for

(Personal note: I feel more sorry about the lack of documentation, which I would like to be a distinctive, positive feature of Minstrel as a FLOSS project, than the "somewhat hacked together" source code, as I have never considered myself an app/Web developer. May others improve what I started.)

Time and resource permitting, I am very interested in keeping working on Minstrel (for a host of reasons I described earlier), but right now I simply cannot afford it. We publicly asked for sponsorship, mostly to write documentation and to fix the worst shortcuts in the code, but we got nothing beyond a few pats on the shoulder. Clearly it is my fault for not being convincing enough.

Anyway, let's move to the meat of this post. Let me introduce the elephant in the room:

Why Minstrel If We Have Readium (SDK)?

I got asked this question a lot, so it is time to provide a written public answer to it.

Since I know this post will exercise the sensibility of many people, I need to disclaim that I think that the developers working on Readium are smart and meaning well, just to rule out the false impression that the arguments below are about people, instead of ideas and management/strategic choices. As always, feel free to disagree and please let me know if you think I misunderstood something.

The Readium Foundation umbrella include several different projects, but essentially they boil down to two major products: Readium SDK and ReadiumJS. Readium SDK is "A C++ ePub renderer SDK of similar capability to Adobe's RMSDK". ReadiumJS is a JS-based GUI for building EPUB reading applications, that can also be packed as a Chrome extension or used to build the app GUI on top of Readium SDK.

In what follows, when comparing it to Minstrel "as an app", I will write "Readium stack" to indicate Readium SDK + ReadiumJS (or any other JS-based UI on top of Readium SDK). Most of my arguments apply to Readium "at large", though.

I want to highlight three differences between the Readium (SDK/stack) and Minstrel, which I believe are fundamental and justify the existence of Minstrel:

1. Readium SDK is a library, Minstrel is a key-in-hand app;
2. Readium stack focuses on EPUB only, Minstrel can support any (open) format;
3. Readium SDK is dual-licensed (AGPL or "pay-to-use-it-in-closed-source-sw"), Minstrel is MIT-licensed.

Let me briefly examine each point separately.

Library vs Full App

If you want to build an app for a tablet or a smartphone, you first need to get the Readium SDK, and then decide how you are going to build the GUI for your app. Either you expand on the native launchers provided by Readium SDK, or you need to code your own GUI, natively or using ReadiumJS or other JS GUIs. I personally think this is too complex for many potentially interested developers.

Thus, I chose to develop Minstrel using a popular framework for creating hybrid apps. (Cordova, to be precise, but the actual choice is irrelevant, any other hybrid framework would do the job; Cordova has its own quirks, but overall is maturing well. BTW, I would love to get feedback on this choice.)

More importantly, Minstrel is a "batteries included" project: you can use it as a launchpad to create your own app, by starting from the existing code, tweak it, create new viewers (I am designing a Spritz-like interface for Audio-eBooks!), or add support for different file formats, etc.

To get a working APK or an Xcode project, you just need three steps:

1. install Cordova
2. clone the GitHub repo
3. run two Bash scripts to create the Cordova project directory

Clean and easy, even for an (inexperienced (app)) developer like me.

Moreover, the native code structure does not forbid using external libraries, possibly even Readium SDK, although this is not the current strategy. I acknowledge that a better separation between the native plugins and the GUI might be beneficial to the Minstrel project. Again, more seasoned developers might want to speak on this point. In any case, I believe my point for a "batteries included" solution still makes sense.

In both approaches there are advantages and disadvantages: for instance, Readium SDK maintains just one cross-platform main library with tiny wrappers/adapters for each destination platform, while Minstrel needs (slightly) more complex native plugins for each platform. Being better engineered, Readium SDK is surely more efficient and snappier than Minstrel.

On the other hand, I would say that overall feature development is much easier in Minstrel: if you just need to touch something at UI-level, you can do it in pure JS, without changing a line in the native code. Even if you need to touch the native code, you probably just need to copy-and-paste already existing code. (And, hey, I agree: the whole process can be improved!)

EPUB Is Not Enough

Observation #2 should be self explanatory. In fact, one of the coolest features of Minstrel is the ability of reusing common functions, including those involving low-level native calls (like unzipping), directly in JS-land, which allows the developer to quickly add support for new formats. Ideally, code an HTML viewer and the JS logic, and you are done. If you need to zip/unzip stuff, save settings, and other similar tasks, you are already covered by the existing, common code. This makes the project future proof and it avoids involuntary echo-chamber/self-referencing effects.

For example, the code currently on GitHub supports CBZ (ZIP of images) and ABZ (ZIP of audio tracks) archives, beyond EPUB files. I have an experimental branch where I display PDF files using Mozilla PDF.js and another branch which features a Markdown viewer/editor. Someone suggested supporting the Baker Framework format. Et cetera, et cetera. Ad libitum.

Licensing

The third point is more subtle. As a developer who contributed to several FLOSS projects, especially making my own code available under MIT/GPL/AGPL license, the signal that Readium Foundation sends by dual-licensing Readium SDK as AGPL and as "pay-to-use-it-in-closed-source-sw" is discouraging me from contributing code to the project. It does not surprise me that the code contributions mostly come from staff of the Readium Foundation or their members, while the issue tracker sees more external activity.

Let me explain. I am not really upset by the fact that the commercially-friendly license that allows the licensee to use the Readium SDK code in closed-source applications has a street price of 30,000 USD ("base contribution") and a mandatory 3,000 US annual fee, while I could have contributed some of said code for free. After all, nobody forces me to contribute.

(Well, that is true for the moment. If Readium SDK becomes the new Adobe RMSDK, that is, it becomes the only library to "power" all the relevant apps out there, and my business will be in desperate need for feature X, I will be probably "forced" to contribute feature X myself. But this is a general problem of monocultures. More on that later.)

My main concern is about the rationale behind asking a fee for a basic library which should be given out for free even for commercial purposes, without the constraints of the AGPL. For a big publisher or a software vendor or a VC-backed startup, 30,000 USD are peanuts. For a bootstrapped startup or an independent developer that price is simply impossible. (The alternative "contribute substantial code for a discount on the fee" may be equally unfeasible in those two cases.) If the goal of the Readium Foundation/IDPF is to promote the use of the EPUB format, then this licensing scheme does not make any sense. I do not think that most of the members of the Readium Foundation will go bankrupt by directly funding the development team behind the Readium projects while releasing the code under MIT, Apache, or any similar license...

Anyway, everybody is entitled with her or his own opinion on the matter.

In ReadBeyond we chose to release the source code of Minstrel under the very liberal MIT license. This essentially means that anyone can use our code, for free, even in closed source apps.

More importantly, our licensing choice should also suggest the idea that we do not care at all about controlling the code or the project. We care about producing the best code possible, and making it available to the end users.

I know some people will take Minstrel and produce single-book-apps with it, which is something that I have always refused to do, because I think it is a short-sighted, harmful decision. But I am willing to undertake the risk, thinking about how beneficial to the entire project code and ideas from external contributors might be.

Diversity Is Desirable

Finally, no one asks "why there are so many browsers, can't we have just one?".

Even if you are not paranoid like me about your digital freedom and privacy, we all agree that diversity of (correct) implementations of (agreed) standards is a desirable property for a digital ecosystem, especially a fragile one like learning/publishing. Hence, even if you do not agree with the arguments described above, I see no harm in having one more (hopefully, decent) choice, when it comes to the app you can use to read ebooks and learn stuff.

If you can provide counterarguments, explaining why Minstrel is bad idea, my mind is open to listen to them.

Until then, please spread the word about Minstrel and, if you feel like it, contribute to the project. Everyone is welcome.