Dynamic Books

This is the third of several posts where I am revisiting CommonsWare, my long-time business and current “hobby with a logo”. I thought it might be useful to some to see how all that came about, the decisions I made, and so on.

The series:

Part of the challenge in explaining where CommonsWare came from is that so much has changed since the mid-2000’s. What was innovative at the time is fairly ordinary today.

Nowadays, online documentation for operating systems, programming languages, libraries, and tools is not merely expected to exist, but to be good. 15 years ago, that would have been unrealistic. We were lucky to have any of that. Instead, most “bulk form” knowledge transfer came in the form of books from traditional publishers: O’Reilly, Apress, Prentice-Hall PTR, and various others.

Traditional publishers, particularly at that time, were far from nimble. It might take 6-18 months for a book to get published. That was a big problem for fast-moving technologies — by the time the book “hit the shelves”, it was already at risk of being out of date. And while e-books existed, if they were published by traditional publishers, they had the same publishing workflow and the same publishing delays. Besides, e-books were fairly new — the Amazon Kindle did not debut until November 2007, around the time that Android was announced.

At that time, I was fairly certain that e-books would do well for programming guides and similar sorts of book subjects. However, since e-books were still nascent, banking a business on them seemed risky. At the same time, my vision for CommonsWare was to provide up-to-date help for programmers, and traditional publishers were far too slow.

Fortunately, I stumbled upon Lightning Source.

Lightning Source offered print-on-demand services, and through Ingram were tied into Amazon. You could self-publish a print book on Amazon without having to have pre-ordered hundreds of copies of the book. Instead, Lightning Source would respond to an Amazon order by printing a single copy of the book (or however many were ordered) and shipping it to the customer directly. This meant I could control my own publishing timelines, simply by listing an updated title on Amazon with fulfillment handled by Lightning Source. Much to my amazement, the quality of the book was very good, more than sufficient for my needs.

Lightning Source for printed books, coupled with e-books, meant that I could offer continuously-updated content:

  • I could sell e-books on a subscription basis, publishing updates as frequently as I wanted, to track changes in a subject or to expand coverage

  • I could sell print editions of that same content via Amazon, updated less frequently than the e-books (say, once per year), but still much more frequently and quickly than any traditional publisher could match

Nowadays, this is all taken somewhat for granted. Selling subscriptions to continuously-updated digital content, even by solo entrepreneurs or on a hobby basis, is commonplace. At the time, very few people were doing this, and I was breaking new ground to an extent.

In terms of the business model, I did not want to charge a lot for the e-book subscriptions — I wanted it to be in line with books, though perhaps on the more expensive end. I settled on $45 per year. Profit margins on self-published and self-sold e-books were tremendous, as I only had to pay credit card processing fees (or the equivalent for services like PayPal). ~95% profit margin is quite a contrast from self-published print books sold through Amazon (~55% profit margin), let alone royalties from traditional print publishers (equivalent of ~10% profit margin). Still, I would need more than “1000 true fans”, but I hoped that I would “make it up in volume”. Plus, I thought that maybe I could offer some professional services to supplement the book publishing, such as consulting or training.

So, I had the the “reason to buy”: get up-to-date programming guides in what was for the time a fairly convenient format (e-books). I still needed to settle on the specific subject matter: Android or iPhone. That not only meant what area I would need to focus in, but also what avenues I would use to “connect with fans”. I will explore that decision in the next post.