Wednesday, July 27, 2011

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.

8 comments:

  1. Sad to hear you're giving up on the Kobo.

    I wonder if the company realises how much enthusiasm they could have built (and mindshare they could have won) by open-sourcing *all* their code and letting people hack on it...

    ReplyDelete
  2. Dan C: Alas, it's really not that simple. I wish it was.

    See the update to the post above because it was too long to include as a comment.

    ReplyDelete
  3. Damn, I was having fun reading your articles!! Thanks though, if you ever change your mind I'll be more than happy :-)

    ReplyDelete
  4. Just one small request that I'm sure you know from the top of your head.

    I have the 1.9 firmware, I'd like the button 'shop' to bring me to this web page:

    http://www.google.com/reader/m/view/

    Is there any easy way to get this change done in a permanent way?

    Thanks!

    ReplyDelete
  5. Completely understand, but very sad. Thank you very much for the contributions to date, though; I now sync wirelessly and reliably. (But my iPhone is the real win in that regard :-) )

    OT, but in the last of a popular Kobo series so work with me: does anyone know where to find the screens at a reasonable price and a way to hack out the driver file, which apparently is hardware-specific to each individual screen? Almost certainly not, but that's where all these e-readers break.

    ReplyDelete
  6. BloGollum: eInk displays are going to be hard to come by in sample quantities at reasonable prices. You may well be better off buying a consumer device and gutting it for the display.

    Note that most eInk displays require a controller board that is specific to the display. They do not use standard display signalling like LVDS.

    As for drivers: Most embedded systems don't seem to have traditional graphics drivers for them. They have a normal framebuffer driver, but with a couple of extra ioctl() calls to allow manual refresh and erase. Theoretically you could write a very simple program to display to them just by writing to the framebuffer using any of the usual methods like SDL, etc, then calling the ioctls to actually push the changes to the screen. For displays that work like that, a QWS or gtk+ driver wouldn't take much more work if your app was willing to be "eInk aware" and know when it had to flush the video output to get the display to actually update.

    I don't know if all eInk displays work this way, what the IOCTL formats are (but check the epson driver in the kernel sources), whether it has other operating modes too, what all the init data that gets sent to the dispay means, etc. Personally I'd recommend using strace to watch what a program does to talk to the display and go from there.

    ReplyDelete
  7. Damn, I hate it when I have to agree with something I don't like. :-(

    You do give good reasons why Kobo wouldn't be more open with their source.

    Though I think what pains me most is, as you say, only a tiny portion of users realize (or refuse to realize, judging by a some members of Mobileread) that an eBook reader is actually a whole computer.

    As "enthusiastic-but-incompetent newbie developer" (somehow I like that phrase), I'd like to add it's not so much WANTING someone to hold your hand, as (too often) needing it. Enthusiasm alone doesn't give knowledge :-(
    (Of course, neither does it give others time and leisure to answer questions ad infinitum. Back to the book, it is :-)

    --

    @Raul: If still relevant, try this link: http://www.mobileread.com/forums/showthread.php?t=113151 . Look for the ".conf" file on the device. Probably isn't permament, though.

    ReplyDelete
  8. Hi Craig!

    You can just recompile kerenel sources with CONFIG_FB_MXC_EINK_AUTO_UPDATE_MODE enabled. That way the screen will be automatically updated :D

    Marek Gibek

    ReplyDelete