Ryan Bigg

Everyone loves a good success story. Here’s mine. I’ll cover my experience going through a traditional publisher with Rails 3 in Action and have that fail, and then discovering joy and happiness through the path of self- publishing my own books through Leanpub.

Rails 3 in Action

I was approached in 2010 to write a book called Rails 3 in Action. I was so very excited to join that project and write a book. Excited because up until that point, the longest thing that I had written was a few of the Rails guides and my own blog posts. A book would be an excellent way to share my knowledge about Rails with the worldwide Rails community. So I signed up.

Then it didn’t go so well. I wrote about that in a couple of other blog posts, mainly “Don’t Print Hard Copies”, “The Writing Process” and “No more writing for Manning”. The long and short of it is that I found Manning incredibly hard to work with due to their tooling and my tendency to want to control everything from how the book looks to when I push updates to its content.

So I quit that project because it was causing me a lot of stress to have to deal with the tooling and to not be in control of things.

Then I rejoined it again in November last year because Steve Klabnik burned out from the tooling and writing process, and also because I wanted to not have Steve’s work go to waste. I brought on Rebecca Skinner as a co-author at that time too. We set about updating the content for Rails 4.2.

Then I quit again in April of this year due to the same reasons I quit the first time and let Rebecca finish off the book. It’s currently going through proofing through Manning’s processes. And by “currently” I mean it’s been in there since April. 3 months to proof and print a book seems a bit long in my opinion, but what can you do about it?

Multitenancy with Rails

After I quit Rails 3 in Action I was burned out quite heavily. I took time off from writing and at the end of 2011 I moved from Sydney to Melbourne. Then when I got to Melbourne, I had the itch to write something again: a book about building a multitenanted Rails application. I talked with my friends Phil Arndt, Josh Adams and Rob Yurkowski about this project, and somehow Leanpub came up.

Leanpub lets you write books in Markdown and upload that Markdown to a Dropbox folder. To push new updates, you go into your account’s dashboard and hit the “Publish” button. This was a welcome change from writing in XML and uploading books to an SVN server and then using a website built in the late-90s or early ’00s!

(Alternatively, you can generate your own files and upload them to Leanpub too if you don’t want to write in Markdown. This is what I’ve been doing for Deep Dive Rails and it’s working wonders. More on that in probably a different blog post.)

The switch to Leanpub was… it was life-changing. Publishing a book didn’t have to be hard! I could just push a button whenever I felt like it and the readers could be reading what I wrote in a matter of minutes. Leanpub made everything so much easier compared with Manning.

I wrote Multitenancy with Rails over about a year and all the while during that time, something interesting was happening: people were buying the book and I was getting money for it each month. I originally sold the book for $10 and then raised the price $5 for every chapter that I completed. This way, it gave people the incentive to get on board (Rails pun!) with reading the book before it was complete.

This had two awesome effects:

1. I would get money each month as more people bought it.
2. I would get feedback on the early drafts from readers.

Royalties

Here’s the royalties chart for all of my income from Leanpub since Feb 2012 to the current day.

Contrast it with the royalties I get from Manning from June 2010 to the current day:

To be fair, the dry-spell since January 2012 is partly because Manning overpaid my royalties by $3.8k. Just a small clerical error, I’m sure. But since then, Rails 4 in Action has been earning money I haven’t seen anything for our work on it.

The monthly income is a great motivator to the writing process because it’s a monthly reminder that people think it’s worthwhile buying and (probably) reading the books that I publish on Leanpub.

Secondly, the royalty split between Leanpub is much nicer: they take a 10% slice of the royalties, + 50 cents. This means that when I sell a book for $20, I make $17.50 from that, and Leanpub makes $2.50. Roughly 35% of that $17.50 ($6.125) goes to tax, but the rest ($11.35) is mine to keep. I might get some of that tax back in the form of a tax return, but it’s not something that I expect.

Here’s a pie chart:

For Manning, it’s harder to break this down because the royalty rates vary between 12.5% for print books, and 50% for ebooks. I get a royalty statement from Manning every quarter for Rails 3 in Action which has the numbers so I can attempt to break it down. I don’t yet get a royalty statement for Rails 4 in Action because it has not been published.

Rails 3 in Action has sold 2,003 print books and 2,371 ebooks. I had expected these numbers to be more skewed towards ebooks, but there you go. The price has been the same forever: $50 for the print book with a free ebook (counted as a print book sale) or $40 for just the ebook. So with those numbers in mind, the total made for Rails 3 in Action over all time has been $100,150 for the print books and $94,480 for the ebooks, which is a grand total of $194,630.

Using the royalty split above, we can work that out that the authors get 12.5% of $100,150, which is $12,518.75 for print books and 50% of $94,480 which is $47,240. A grand total of $59,758.75.

The rest of the money, 87.5% of $100,150 ($87,631.25) and 50% of $94,480 ($47,240) goes to Manning. A grand total of $134,871.25.

Using those figures, I can generate a pie chart similar to the Leanpub one above:

(Tax isn’t shown on this chart because the “Authors” royalties are split between Yehuda and myself and we pay different tax rates. While I know my tax rate, I don’t know Yehuda’s!)

Manning receives over two-thirds of the money earned for Rails 3 in Action and will earn the same split for Rails 4 in Action. This is a personal sore point for me, because I’m a greedy bastard and for plenty of other reasons. For instance, it makes sense that the royalties earned for a print book are low, because producing print books takes effort, time and money. So that’s logical. But a 50/50 cut for ebooks seems a bit, well, unbalanced.

Clearly though, publishing my books through Leanpub is the better option if what I’m optimising for is money. Leanpub gets 10% + 50c of whatever book I sell. Manning gets between 50-87.5%, which is almost 4-7 times as much as Leanpub.

However, I don’t optimise for money. If your intention is to write a book for the sole purpose of earning extra dollar dollar bills, then I have some advice for you: you’re damn crazy and you shouldn’t write it because the probability of you earning enough money to be happy is extremely low. Books don’t earn even close to a sustainable level of income.

What I optimise for is (selfishly) my own happiness first, then reader happiness a very close second. My reasoning for that is that if I don’t enjoy writing a book, then the book won’t be very fun to read. My own happiness comes first to make sure that a good book comes out at the end.

That’s a nice segue into our next topic: writing tools and feedback cycles.

Writing tools and feedback cycles

I want to talk about two things here: feedback cycles and writing tools.

Feedback cycles

When publishing a book, you kinda want to know immediately if anyone’s reading it. Peoeple buying the book is different to people reading the book. A good indicator for this is the feedback that comes through in the form of, mostly, errata reporting. Errata reporting means that people found errors in the book, and that means that they read the book! That’s great!

Fixing those errata reports quickly is essential to producing a high-quality book. The faster you can kick out a new edition of the book and solve the error, the sooner it’ll be that nobody will ever come across that particular error again.

With Manning, the process was this:

1. Find mistake in book and fix it.
2. Commit the fix to SVN.
3. Get rejected for the commit because some other author has pushed their book to SVN since the last time you did.
4. Checkout from SVN.
5. Commit the fix to SVN for real.
6. Go to Manning’s author-only site and login.
7. Find your book in the list of books.
8. Click the gear icon.
9. Find the chapter that you updated.
10. Scroll down the list of revisions for that chapter.
11. Click the radio button to select “Latest” (which uses the latest version of that chapter) and then click “Update”. This flags this particular revision to be ready for Manning’s system.
12. Wait for someone from Manning to publish a new MEAP copy, which can take weeks.

12 steps and it takes a couple of weeks (usually) until the book is updated. Oh, and at step #11 you might be told that somewhere in your 2,000+ line XML file, something is invalid.

With Leanpub, the process is this:

1. Find mistake in book and fix it.
2. Commit change to GitHub.
3. Copy file to Dropbox folder. (can be optional if you get Leanpub to read from GitHub!)
4. Go to Leanpub’s author-only area for the book.
5. Click “Publish”, “Publish New Version”
6. Hit the big blue button “Publish new version”.

6 steps and the book is available instantly for readers! Markdown doesn’t fail to compile when it’s invalid, it just looks weird and the weirdness is generally quite obvious (everything is plus-sized after a certain point, for instance) and so it’s easy enough to fix.

During the publishing process you can enter release notes as well. On Leanpub, the choice to release a new version of a book is in the hands of the author, and not the publishing company. This is the way it should be: the author typically has one book on the go, whereas a publishing company has many. This 6-step process is the kind of process I could only dream about when writing Rails 3 in Action.

For readers to send feedback to a Manning book they have to submit new topics to a forum. This makes it really hard to track which topics have been addressed and which haven’t. For the update of Rails 4 in Action, we created a repository on GitHub at rubysherpas/r4ia and asked readers to file issues there. That way, when we fixed an issue on the book properly, we could close it with a simple commit message like “Fixes rubysherpas/r4ia#10”.

If I was collaborating on a book again, I would definitely go down the GitHub repo-for-errata path again because it makes that aspect of the writing process so much simpler.

For Multitenancy with Rails, I’ve gone with more of a personal approach: I’ve included my email in the foreword to the book and asked if people encounter errors that they email me directly. This system works really well as I use the unarchived emails as an indication of what book bugs haven’t been fixed yet.

I also built a review tool called Twist, originally for Manning’s DocBook format but then ported that across to Leanpub’s Markdown format. The README there has a great image showing you what it looks like. The purpose of this was for people to leave comments on particular elements (paragraphs, code blocks, images) of the book and then I could see specifically what element they were commenting on. That worked really well for Rails 3 in Action and both editions for Multitenancy with Rails too.

Conclusion

I wrote this post to answer questions that I get from people who ask what the writing process was like. The two main things that I tell people that bugged me about writing for a publisher were the writing tools and the royalty split.

Bad writing tools definitely hampered my ability to write, especially when I spent a lot of my time fighting SVN to accept my files, or tracking down where the XML files were invalid. Using Markdown, GitHub, and Leanpub’s Dropbox integration is one of the winning combinations for writing a book, and it’s what I use for Multitenancy with Rails.

I use Asciidoc and GitHub for writing Deep Dive Rails. It took a little while to learn how the asciidoctor gem worked and then a little more time to figure out the PDF configuration, but it’s looking really great now and I can tweak it very easily. I have control of what my book looks like! As an author, that’s a pretty exciting thing because a book is a personal thing.

Yeah, I’ve spent a lot of time messing around with the asciidoctor gem but it’s been way more fun than bashing my head against SVN or XML. It’s way more understandable, for starters!

There’s nothing that can be done about the royalty split for Rails 3/4 in Action. To be frank about it, I signed a contract that allows Manning to take full ownership of Rails 3/4 in Action and to pay me what they pay me. It means that even if I ask them super-nicely (and not-so-super-nicely), they still won’t give me the rights to the book. It’s absolutely my fault, and I have learned my lesson from that. I’ve fulfiled my end of the bargain, and here’s hoping that they (again) fulfil theirs by paying us authors the royalties we get.

What I can do in the future is avoid publishers altogether and just continue self-publishing. It’s what I advise anyone who’s considering writing a book these days. Self-publishing allows you to get your book out there faster than through a traditional publisher and you get to have complete control of it.

So if you’re considering writing a book, check out Leanpub’s offering and see if it suits you.