Should you self-publish? Should anybody?

Many colleagues have asked us about the experience of self-publishing our textbook. In a previous post I talked about the DIY technology I harnessed to produce the actual artifacts (both the printed book and the ebook). In this post I’ll talk about being self-sufficient and doing the other things publishers presumably do for you.

cheapest generic levitra

Advice: have a plan for proofreading and errata. I’ve never had a publisher, and I’m a stickler for writing, so proofreading with a fine tooth comb is something I do anyway. But if it’s not something you do, you won’t have a publisher to help with that. Dozens of minor errata were reported by readers; we used a Google Form (HTML form backed up by a Google Docs spreadsheet) to collect them.

xenical canadian pharmacy This has been challenging, because Amazon has their own mechanism that allows readers of Kindle books to report errors. However, the information reported through that mechanism is relayed sporadically and not sanity-checked; factually incorrect “corrections” from readers are passed straight through, as are complaints from readers who aren’t sophisticated enough to operate their ebook reader devices. However, those people are Amazon’s customers (and as an author, you are not), so we just have to learn to deal with this.

Advice: set your expectations for “service”. One thing a publisher normally handles is distribution. Amazon’s Kindle Direct Publishing handles that for the Kindle book, but until recently, their service & support for publishers was terrible. (Note that I don’t call it “customer service”. People who buy books are Amazon’s customers. Authors are not.) Recently, though, because of the highly visible success of our MOOC, which uses both the Kindle book and Amazon Web Services infrastructure, Amazon has become much more interested in speaking about strategic things with us, and has given us the level of support usually given to real publishers. We just made our book available on the Nook store and expect to sell it via Google Books starting next month; I’ll report back on whether they are any more responsive to indie authors.

Advice: tell your purchasers to follow you or otherwise let you notify them of updates. A key reason we wanted to do an ebook was the ability to get bug fixes and new content into readers’ hands quickly. Each release of the book has a version number, starting from 0.8.0 in January 2012 up to 0.8.5 in May 2012. We applied the errata fixes ourselves, using GitHub to track all book content and tagging the releases as we would with code, and every erratum has a corresponding version number. Amazon initially told us they’d notify purchasers and allow them to re-download updated versions of the ebook, but they waffled. (This is now fixed, but only by Amazon’s decision to give us special treatment.) Without that support, I’m not sure we’d be able to get updates into readers’ hands. Even so, while readers can now re-download updated versions of our book, it’s up to us (not Amazon) to notify readers when new versions are available. We can use the MOOC registration email lists to hit many of those people, but others will have to find out for themselves. We’re now encouraging readers to follow us on Twitter, and we’ll put that text into the next release of the book.

Advice: have a plan for spreading the word via professional forums. We had already been spreading the word about our course—we had presented posters or talks at CSEET, SIGCSE and ICSE, wrote an espousing the teaching of software engineering using SaaS+Agile, and so on. We’d been collecting names of people who might be interested in trying out our ideas, so naturally we told them about the book too, and offered most of them complimentary copies. (Unlike with a publisher, the cost of the comp copies comes out of pocket for us, though the print-on-demand house we use, CreateSpace, allows authors to purchase author copies at a price lower than list.)

Advice: be prepared to do your own feet-on-the-ground marketing and publicity. My marketing experience as a nonprofit theater Board member came in handy. Following the pattern I’ve used in that world, we designed a postcard and had it printed and direct-mailed by PSPrint to a mailing list we purchased (~600 software engineering professors). The list was ad hoc and included few top-tier departments; in retrospect I’m not sure it was worth the roughly $500 we paid. Successful practice in arts marketing is to follow the postcard with an email reminder a week or two later, but the firm that sold us the list wouldn’t sell us the corresponding email list, so we paid people to scrape the Web to get them manually (I know, we could’ve Turked it). Then we found out we couldn’t import those addresses into an email list manager such as the excellent MailChimp or ConstantContact, since due to CAN-SPAM laws you may only import email addresses of people who have directly opted in via your own website. (There’s now an area on our book’s website where you can express interest in the beta program that uses the book.) So we sent one-on-one emails to just about all those people (600 or so in all). We also personally reached out to colleagues in top-25 departments with whom we had good personal relationships. It wasn’t a huge amount of work but it was time not spent on writing.