$25K in book sales, and I'm almost ready to publish

I started writing my first book almost two years ago. At the beginning of the project, I set an ambitious goal: Write a 90-page introductory-level technical book on some relatively new software, and sell 200 copies.

As a developer and dabbling entrepreneur, I calculated that if I sold the book for around $10-20, and wrote the book based on real-world scenarios I'd already encountered (meaning very little extra research/discovery required), I could make enough money to keep things interesting while helping a few hundred developers pick up the new software more quickly.

Almost two years later, Ansible for DevOps is almost 400 pages long and has sold over 2,000 copies—and I haven't yet published the book.

What follows is an analysis of what led to this success, and some cautions for those considering writing a book.

Also, as you'll likely find is a theme running through every "how to do x" post on HN, Reddit, and blog, this blog post serves to shamelessly plug Ansible for DevOps[1].

The right place and the right time

One of the largest factors in my book's sales, and in fact in pretty much every project I've seen that's way more successful than originally planned, is luck. In this case, it was a matter of publishing the right book at the right time.

Ansible was created in 2012, and for the first year or so, it wasn't clear if it would rise to the adoption of heavyweight CM tools like CFEngine, Puppet, and Chef. It was also created with many of the same ideas as Salt (now SaltStack), another fledgling YAML-based CM tool. However, Ansible had three major advantages over the incumbents:

• It uses SSH for transport (instead of a proprietary protocol), so you don't have to install stuff on all your managed servers/systems.
• It uses YAML for configuration, which means serious work can be done with it without learning a custom DSL or parts of a programming language.
• It was promoted as an infrastructure management tool, not a configuration management tool, during the (ongoing) explosion of microservices and container-based infrastructure, where orchestration is sometimes more important than configuration.

Ansible was in the right place at the right time, and my book was one of the first two books available to help people learn Ansible.

Being involved in the Ansible community helped me to build a small network of contacts who helped spread the world (a little here, a little there, and it adds up), and it also helped me to get some amazing early reviews and suggestions that guided the rest of the book in the right direction.

My book had one other huge advantage over the other existing book, and over all the other Ansible-focused books that have since been published—it was published not once, but hundreds of times. I've published updates to the book while Ansible has evolved. When I started writing the book, Ansible 1.2 was the latest version. At the time of this writing, Ansible 2.0 is just around the corner, and the book is 100% current with the latest best practices and newest functionality. Which leads me to...

The right process

Two years is an eternity in the tech world. Infrastructure has evolved so rapidly, with Ansible alongside. The traditional publishing model doesn't offer the agility necessary to publish and maintain a technical book that responds to rapid change.

Some publishers are making massive strides in this regard, but the traditional publication process works against many authors:

1. After a hot new technology gets out of the early adopter stage, all the major publishing houses decide it's time to publish an introductory book on the technology.
2. High-profile early adopters or technical writers are contracted to write the book.
3. A compact 3-to-6-month cycle of writing, editing, reviewing, and finally publishing the first (and often only) edition of the book takes place.
4. The book is finished, and within a few months to a year, half the examples fail on the latest version of the software, and developers the world over toss the book into a waste bin, or set it on the shelf to collect dust.

I know about this process because I spent a lot of time considering the traditional publishing workflow. I talked to representatives at all the major technical book publishing companies, and was considering quitting LeanPub for a quick first-time-author advance (something like $5K to $10K max), and a promise of a tiny percentage of all book sales.

I'm glad I didn't go that route, because Ansible for DevOps has netted me over $25,000 in sales (so far).

LeanPub is a publishing platform that allows authors to publish in-progress books, and allows readers to purchase the book once, then download DRM-free copies of every update, ever.

I found out about LeanPub because I bought The Node Beginner Book a couple years ago, and loved how the book was updated as the author gained more knowledge, as Node.js grew, and as readers submitted corrections. It was one of the best and most cost-effective technical book purchases I've ever made, even at a meager 54 pages.

Some of Leanpub's most attractive traits include:

1. All sales are 100% refundable for 45 days. Did you judge the book by its cover then read the first chapter and realize it's not for you? No problem, just return it and nobody bats an eye.
2. All downloads are DRM-free. This needs no explaining, I hope.
3. LeanPub books are written in Markdown (the idea of laying out or editing a book in Word makes me shiver), and LeanPub has some great and customizable formatting defaults so your text looks great in ePub, .mobi, PDF, and (optional) HTML formats.
4. LeanPub takes a very small slice of the sale (~10%) for what I get out of it.

Some authors, and pretty much all the publishers, shudder when they hear about 45-day refund policies, especially in tandem with DRM-free downloads. What's to prevent someone from downloading the book and making infinite copies? In the old publishing world, where there's one and only one edition (at least for a long while), I see how that can be devestating.

But with LeanPub, the first person who purchased my book for $9.99 almost two years ago (and only received a preface, and two short intro chapters) has had access to almost every bit of knowledge I've gained in those two years, and that's the value. Once my book hits '1.0' and I publish a static '1.0' edition on Amazon, iBooks, and elsewhere (platforms about which I'm less excited), I'll still be updating it on LeanPub.

Caution

Word count over time. This graph took way too long to make[2].

You may be thinking to yourself, "I know technology xyz pretty well, and I could use $25K, so I'll write my own book!" More power to you, and by all means, pursue your passion... but be warned:

• Don't do it (only) for the money. I spent around 1,000 hours writing Ansible for DevOps. With no deduction for the (meager) marketing I've done (about $500 total), this equates to about $25/hour. Almost any other job or contract work I've done has paid two to four (or more!) times that rate, so most of the time I spend writing the book I cut out of other time—time with family, time relaxing, time I could be working on other opportunities.
• Book sales requires some skill and a lot of luck. I picked the right topic at the right time, and I had a (small but effective) network of relationships to promote the book. Had I started my book today, I would have far fewer sales in the more saturated Ansible book market. If you're writing a book on Java, it better be the best Java book in history, or you shouldn't expect a huge number of sales.
• Self-publishing requires more effort than the traditional route. I had to find my own editors, design my own cover, find reviewers, do all the marketing. On the flip side, I have full control over the entire process, which can be a benefit.
• Finding time to focus on writing is a constant battle. Early on, I had a lot of passion for the book, and I would wake up an hour early every day to write. That initial burst of energy died out, and there were a couple dry periods where a word wasn't written for a few weeks. Without the pressure of a publication deadline, your writing can fizzle. Find a routine and stick to it.
• Writing is work. Even tutorial/cookbook-based writing can be a huge drain, and writers' block applies to technical writing as much as any other style. I've been writing documentation and posts for many blogs for over 10 years, with some regularity (at least a few thousand words per week), so writing the book was not an entirely new endeavor—just different.
• Choose an audience, and be ruthless in writing for only that audience. I have a large list of topics I considered writing about, but in the end left out since they weren't the core problems my audience wanted to solve. I might add a few of those topics to version 1.2, 1.3, etc., but if you ever want to finish your book, cut out anything that's not directly relevant to your audience.

If you want to write a book, but all means do so. But don't expect to toss some words on the screen and get rich quickly.

I'll be publishing Ansible for DevOps on other bookstores soon (there will be a printed edition available, too!), but you can get it now (and always have the latest version, DRM-free) from LeanPub.

I hope to write a few more posts about the publication process and book sales as I get time in the coming months, but please excuse me for now as I work on finishing up the last few changes!

Footnotes:

1. At least I don't have a distracting newsletter popover like other authors!
2. Seriously. For anyone interested, here's a bash script to count all the words inside .txt files in each commit in a git repository:
   
   #!/bin/bash
# Count all lines in .txt files in a repository for each commit.
for commit in `git rev-list --all`; do
    git log -n 1 --pretty=%ad --date=short $commit
    git archive $commit *.txt | tar -x -O | wc -w
done

Purchase Ansible for DevOps on LeanPub, Amazon, or iTunes.