No further work on Kobo

This article is part of an extended series on Kobo development and investigation

I've stopped work on the Kobo software and dev env.

The Kobo is a fun platform but there isn't much point developing addons and plugins, because only a tiny proportion of Kobo owners will even realize it's a computer, let alone one they can enhance.

Most of the things I want to improve about the Kobo require access to the source code for the Nickel eReader application that runs on it. Kobo are not releasing this code - not even under NDA or other restrictive terms that permit fixes to be sent back to them without permitting distribution of the code to others.

The rest of the things I'd like to do need the QWS (Qt Window System) driver that's currently distributed only as a statically linked component of nickel. Without this I can't write my own interactive Kobo apps unless I hijack nickel's startup with a qt plugin hook. Doing it that way is ugly, inefficient, and prone to breakage, plus it renders the device useless as an eReader.

Given this, working on Kobo isn't going to be a productive use of my time. I learned a bit about ARM embedded systems and cross compiling, but I think I'll be leaving it at that.

---

Update to address Dan C's comments:

I'm not giving up on Kobo at all... just on developing fixes and enhancements for it.

As for the company's loss/missed opportunity: it's really not that simple.

Kobo's product isn't the hardware

Kobo's product isn't really the hardware, it's their software, brand, publisher relationships, website, and bookseller relationships. Their hardware is really generic - it's the same, or very nearly the same, as several other eReader devices and is made by a 3rd party.

The original Kobo was a netronix device, and I think the wifi is too. The Linux port and platform software on it was developed by Netronix, too, using an ARM SDK produced by CodeSourcery.

What makes the Kobo different is the Qt-based user interface Kobo inc built - "Nickel" - and its helpers. This software is the main differentiator they have. If they release it under a full OSS license, they enable competitors (other booksellers, other hardware makers, etc) to easily rebrand it and bundle it on their own generic eReader devices. Kobo is already fighting two juggernauts - Amazon and Apple - in this market, and will probably be up against Google soon too. They can't afford to enable small clone-competititors to use their stuff without contributing back.

GPLv3 isn't enough, either, because a rebrand could contribute and publish all their code but still direct sales to a different book store. There go the revenues Kobo relies on.

What they'd need to do is a "source available" release rather than an "open source" release as we know it these days. One where you can obtain the source, edit it, rebuild the app, etc, but cannot distribute it on your own devices, change the target bookstore, etc.

They've chosen not to do that. There may be good reasons why. Auditing sources for release to the public is expensive, even if it'll be released only under a restrictive license or even under an NDA. They'd also have to potentially fight enforcement actions against competitors who infringed despite the terms. Then there's the issue of DRM and Adobe Digital Editions, which quite likely has its own restrictive terms, probably including restrictions on release of sources for apps that use it.

Taking patches and dealing with random "developers" can be lots of work

Even if it were easy to release the sources, it's not clear that they'd see all that much benefit for the work. How much contribution would they really get? I speak from experience when I say that vetting and reviewing submitted patches is often harder than writing the code yourself. That's especially the case in environments people are less familiar with (like embedded linux developed using Linux desktops/workstations), projects with smaller communities, C++ projects using particular toolkits like Qt, etc.

Now add the inevitable group of enthusiastic-but-incompetent newbie developers who want you to hold their hand all the way. Mix in a few abrasive personalities who know they're always right, a few angry self-righteous demanders with a severe attitude of entitlement, and a couple of right idiots. You get the potential for a huge time sink that takes devs away from real work or requires dedicated people to pay to take care of it.

The plugin API was a non-starter

The alternative, of a plugin API, was pretty much a waste of time.

Writing a good plugin API is way harder than just opening up the code... which is plenty hard enough. You have to document the API, maintain compatibility across releases, keep the build system and SDK up to date, handle the additional tech support issues created by buggy plugins, etc etc. An app not originally designed for plugins requires *massive* work for plugins to be useful - I learned that one the hard way while working on Scribus.

Given that the Kobo is very much a consumer device where the vast majority of its users won't realize it is an embedded computer at all, let alone a hackable Linux-based one, and you get a whole lot of work for nearly zero return. Anyway, anyone likely to be building plugins is more likely to be writing smartphone or tablet apps.

So it's really not that simple

In their position, I would've wanted to release the code under NDA or a restrictive source-available license to interested devs who could show they already had a handle on the SDK and the platform. I'm not them, though, and I'm not in possession of all the info. They may've had good reasons for staying completely closed. Alternately, it's quite possible that the tech types wanted to open up but the lawyers/PHBs vetoed because of fear or misunderstanding. We'll never know.

At least if they'd opened up Nickel under a restrictive source-available license they'd get bug fixes contributed back. A plugin API would just be a time sink for them, to no benefit.