Starting late in 2020 and wrapping things up today, I streamed a new 10-episode series, Kubernetes 101 (the first episode is embedded below).
Five years, 834 commits, and 24 major revisions later, I've just published the 2nd edition of Ansible for DevOps, a book which has now sold over 60,000 copies and spawned a popular free Ansible 101 video series on YouTube.
Making good on my promise to make the ebook updates free, forever, I've published a new revision of the book at least once a quarter since I published the first revision (version
0.42) on LeanPub in 2014, and the second edition begins the
2.x series of book revisions.
The book covers the basics of managing Linux servers, then dives deeper into continuous integration, application deployments, container image management, and even Kubernetes cluster management with Ansible.
In March, I made my DevOps books free to help anyone who wanted to learn new skills during the global pandemic lockdown. In April, Device42 generously extended that offer for another month.
I originally had the idea to give the books away on a whim on a Sunday night, thinking I'd give up a fair chunk of revenue, but nothing too substantial. The response I did get was overwhelming, to say the least!
Five years ago, I set out to write a book. For a topic, I picked Ansible, since I was familiar with the software, and noticed there weren't any other books about it. I struck gold with Ansible for DevOps, and have since sold over 22,000 copies between eBook and paperback copies.
I've written about self-publishing before, and my opinion about publishing technical works is stronger than ever:
- Don't write for a publisher (usually)
- Use the Lean Publishing process
I wrote an entire article (Self-Publish, don't write for a Publisher) on the first topic. Regarding the second topic, I see writing a technical book on the same plane as building a software project:
I'm not a writer. I'm a software developer who communicates well. Because I'm a developer and software architect, I spend time evaluating solutions to find the best one. There are often multiple good options, but I try to pick the best among them.
When I chose to write a book two years ago, I evaluated whether to self-publish or seek out a publisher. I spent a lot of time evaluating my options, and chose the self-publishing route.
Because I'm asked about this a lot, I decided to summarize my reasons in a blog post, both to posit why self-publishing is almost always the right option for a beginning author, and to challenge publishers to convince me I'm wrong.
Ansible is a simple, but powerful, server and configuration management tool. Ansible for Devops is a book I wrote to teach you to use Ansible effectively, whether you manage one server—or thousands.
I've spent a lot of time working with Ansible and Drupal over the past couple years, culminating in projects like Drupal VM (a VM for local Drupal development) and the Raspberry Pi Dramble (a cluster of Raspberry Pi computers running Drupal 8, powering http://www.pidramble.com/). I've also given multiple presentations on Ansible and Drupal, like a session at DrupalCon Austin, a session at MidCamp earlier this year, and a BoF at DrupalCon LA.
Ansible for DevOps, my first book, is finally available for sale on Amazon and iTunes (in addition to LeanPub, where it's been available as an in-progress work since last February!).
I've written quite a bit about the my writing process, book sales pre-publication, and motivation in previous blog posts, linked here:
After almost two years of writing, editing, and rewriting my book, I've finally completed the first edition of Ansible for DevOps, and it's available for sale on Amazon, LeanPub, and iTunes!
The book is 400 pages long, just shy of 80,000 words, and was a huge effort. It's such a relief to finally have it 'out the door', though publishing-as-I-write has been a great experience. Pre-first-edition, I've already sold over 2,200 copies of Ansible for DevOps on LeanPub!
Here are a few blog posts from Server Check.in where I describe more of the publication process:
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.
I've been blogging for 10 years, and I've written over 800,000 words in posts. As time progresses, I try to clearly convey more information with fewer words. It's been hard to quantify the value derived from those words, however, since the only measurements I could make (e.g. a small amount of ad revenue) have been subjective at best.
For almost seven months, I've been writing Ansible for DevOps, publishing on LeanPub as I write. In that time, I've written ~41,600 words (with roughly 60% of the book complete), and have had ~800 readers purchase the book (either standalone, or in a bundle).