Recent Posts

Reader Testimonials and Book Editing Page Update

by Len Epp

published Aug 26, 2015

Today we’re releasing some improvements for Leanpub authors. Please let us know if you have any questions or suggestions by emailing us at!

Reader Testimonials

One common method for marketing books is through reader testimonials and reviewer comments. In print books, these are the blurbs you see on the back cover or inside of the book jacket saying positive things about the book and the author.

We’re now adding a section to Leanpub book landing pages where you can include testimonials from readers and reviewers of your books. Of course, it’s up to you to attribute the quotation correctly, and to ask permission from someone if you’re going to post a comment they made to you privately, over email for example.

If you have an image of the person, you can upload it so your customers can see their smiling face or avatar. Circle faces for the win!

To add testimonials, click on the new “Community” section in the menu on the left when you’re editing your book’s settings on Leanpub.

Reorganized Book Editing Page

We’ve reorganized the book editing page on Leanpub. All the same features are there, but the next time you go to work on your book, you’ll notice that things have moved around a bit. We did this to make it easier to find what you’re looking for under more relevant headings, and to divide up the process into three main categories of activity: writing, publishing and selling.

The coolest new improvement here is our overhaul of the book “Overview” page. Now you’ll have quick links to make important changes to your book and your book’s Leanpub web page, and you’ll even see a couple of charts showing you some relevant analytics.

The new Leanpub book overview page

We hope you find these changes helpful! Listening to our authors is a very important part of our process, and we’d love to hear your feedback.


How To Self-Publish An Ebook On Leanpub

by Len Epp

published Aug 22, 2015

This short article will introduce you to the basic things you need to know to write, publish and sell an ebook on Leanpub. For more information, we have an FAQ for authors and a searchable manual. If you have any questions or suggestions, please feel free to email the Leanpub team at any time.

A Brief Introduction To Leanpub

Leanpub is building the best way in the world to write, publish and sell an ebook. We specialize in providing authors with the opportunity to publish their books serially or in-progress, which is why it comes naturally to us to provide tools for writing, publishing and selling your ebook all in one platform. With our in-progress publishing workflow, you can publish a novel or a non-fiction book chapter-by-chapter, as you write it, finding an audience and gathering feedback before your book is finished.

Leanpub is free to use. You can use our writing tools to make your ebook and then sell it elsewhere if you like. If you do sell your book through our bookstore, we pay a royalty of 90% minus 50 cents per transaction. When you sell your book on our bookstore, you set a suggested price and a minimum price, and the reader chooses what to pay. Combined with our 100% Happiness Guarantee, this means that through Leanpub you establish a relationship with your readers based on trust and support.


When you create a new book on Leanpub, you can choose from among five different ways to write your book:

  • In a Dropbox folder on your computer
  • In your Internet browser on Leanpub
  • “Bring Your Own Book”, which lets you upload a book you have made yourself
  • Using Git and GitHub
  • Using Git and Bitbucket

We provide all these options because we know how seriously writers take their writing processes. Some people will enjoy writing in a browser-based writing tool like the one we have provided (which means you can write your book on our website), while others will prefer writing in their preferred plain text editor on their computer, and syncing with Leanpub through a service like Dropbox (if you’ve never done this, it’s really simple!). Still others will have an entirely closed writing process, and will just want to upload their finished book onto our bookstore.

Please note that we also have a process for importing from Microsoft Word and a few other sources, such as blogs. We know that many people still use Microsoft Word to write, though we hope that within a few years no one will be using it to write books anymore. If you have already written a long book in Word, you can import it to Leanpub, but you will have some conversion work to do.

If you do choose to write your book using Leanpub (rather than uploading a book you have made your own way), then you will be writing in plain text. This is as simple as it sounds, and we believe it is how all books should be written. When you write this way, you type the formatting right into your text. For example, if you want some words to be in italics, you *surround those words in asterisks*. Then, with one click of the “Preview” button, you can turn your manuscript into three ebook formats: PDF (for computers), EPUB (for iPad etc.) and MOBI (for Kindle), and the words inside the asterisks will appear in italics. You can think of this like punctuation for writing in the digital age: just like quotation marks enclose words we are meant to read as speech, so do these asterisks enclose words meant to be produced with emphasis.

Writing your book using Leanpub lets you easily produce ebooks in multiple formats from a single source text. This is because writing in plain text on your computer or in the browser really is the best way to write an ebook. For those interested in making a print book, we also provide you with print-ready versions of your book. You can even export your book in HTML to make it into a web page.

Leanpub books can be written in any language, and if you find our support for your language is lacking, we will quickly improve things for you.

DRM-Free Books

Leanpub books are DRM-free. “DRM” stands for “Digital Rights Management”, which is a euphemism for limiting people’s access to ebooks and other digital things. A DRM-bound ebook is the digital equivalent of a paper book printed in ink you can only read under an approved brand of light bulb; in other words, it is a perverse absurdity and an affront to the role books ought to play in a good society. Some DRM services even add self-destruct mechanisms to books, which means you can only read them a certain number of times. In effect, these are self-burning books. In case it’s not clear, at Leanpub we are strongly against DRM, primarily for ethical and intellectual but also for what ought to be very obvious practical reasons. We have more to say about this here.


Publishing your book on Leanpub is as easy as clicking a button. If you’ve used Leanpub to write your book, it will be available for sale instantly in PDF, EPUB and MOBI formats on a great-looking webpage you can customize. At any time, you can update your book with an entirely new chapter, or just a single typo fix, and hit the publish button again, making the new version available to all your current and future readers.

The ability to update your book instantly, and make the new version available to all your readers around the world, means you can publish your Leanpub book serially or in-progress. Publishing your book before it’s finished strikes some people as a radical idea, while for others it just seems like the obvious thing to do. Those familiar with the history of fiction usually fall into the latter category, since they are already familiar with the idea of serial publishing, where you publish your novel a chapter at a time (many great novels have been published this way, particularly nineteenth-century English and Russian novels). For non-fiction books, in-progress publishing lets you test your ideas and start building an audience when your contributions are still fresh, without the conventional delay imposed on authors by the standard twentieth-century publishing model.

There’s a lot more to the idea of in-progress or “lean” publishing. For the whole story, check out our manifesto.

Publishing Your Book Elsewhere

If you publish your book on Leanpub, we don’t have any rules to prevent you from publishing your book elsewhere at the same time (though other companies may place restrictions like this on you). In fact, we encourage you to sell your book on multiple platorms. If your book gets picked up by a conventional publisher, you can easily “retire” it from Leanpub. And if you do take your book to an exclusive online publishing service, and then decide you want to come back to Leanpub, getting your book re-published is easy.


Our bookstore doesn’t have the same reach as Amazon (yet), but we do offer some big advantages over selling your book on other publishing platforms:

  • You earn a royalty of 90% minus 50 cents per sale
  • You can sell supplementary material with your book (like videos)
  • You can sell your book as part of a bundle of books
  • You set your price using our powerful “variable pricing” model, and you can change it any time
  • Since customers choose what they pay, you can make a book available for free, and still give people the option to pay if they want to
  • Our 100% Happiness Guarantee means readers can get a refund with two clicks, which makes buying a Leanpub book risk-free and encourages more sales
  • We encourage feedback and the development of a community around your book

We are working on a number of new features to improve the reader and author community experience around Leanpub books. If you are publishing your book serially or in-progress, then writing, publishing and selling are all parts of a continuous process. Right now, readers can share their email addresses with you, get email notifications when you publish new versions, and even email you directly. In the future we’re going to be releasing robust and fun review and feedback features, which let readers tell you what they’re thinking, and even report small errors so you can fix them instantly.

Leanpub Podcast Interview #18: Ryan Bigg

by Len Epp

published Aug 05, 2015

Ryan Bigg is a Melbourne, Australia based software developer, writer and blogger. He is the author of the Leanpub book, Multitenancy with Rails, which helps you build a multi-tenanted forum application. Ryan’s next Leanpub book, Debugging Ruby, examines examples of common debugging pitfalls with Ruby code and Rails applications

This interview was recorded on June 5, 2015.

The full audio for the interview is here. You can subscribe to this podcast in iTunes or add the following podcast URL directly:

Ryan Bigg

Len Epp: Hi, I’m Len Epp from Leanpub, and in this Lean Publishing Podcast, I’ll be interviewing Ryan Bigg.

Ryan is a Melbourne, Australia based software developer, writer and blogger. He currently works as a Ruby and Go programmer for Marketplacer, a leading technology and business platform that makes it easier for people to create successful marketplaces. He was named a Ruby Hero in 2011 for his work on the Rails Guides and his contributions to the Ruby on Rails Community. Ryan is also well known on Stack Overflow for his answers to Ruby on Rails questions.

Ryan is the author of the Leanpub book, Multitenancy with Rails, which helps you build a multi-tenanted forum application. He is also the co-author of two Manning books, Rails 3 in Action and Rails 4 in Action. He’s currently working on a new Leanpub book, Debugging Ruby, examining examples of common debugging pitfalls with Ruby code and Rails applications, using cases he’s seen in his day to day work.

In this interview, we’re going to talk about Ryan’s professional interests, his books, his experiences using Leanpub, and ways we can improve Leanpub for him and other authors.

So, thank you Ryan for being on the Lean Publishing Podcast.

Ryan Bigg: No worries, it’s good to be here.

E: Thanks. I usually like to start these interviews by asking people for their origin story. Could you tell me a little bit about how you first became interested in software development and how you became a developer?

B: Yeah sure. I’ve always been interested in computers as far back as I can remember. The first computer that I accurately remember I think was a Commodore 64, we played Paperboy on it. You had to insert the cartridge and type “run” or “load,” whatever it was, and then play the game that way. So I’ve always been around computers. And then dad was doing this kind of invoicing system for his work as a photocopier technician, building it in a language called Clipper. And he found this function of Clipper that listed music. So he came to me with this manual, this big binded manual thing, and said, “Look, this lets you play music.” And he showed me if you type “play 70,” it would pay a note. And then you type ”play 75,” and it would play a higher note. And so we just made music. I was into music at the time and made music using Clipper, and that was my first experience with programming. And then I did HTML and CSS probably when I was 9 and 10, and I’ve been doing web really ever since, and I enjoy it. It’s interesting, you’re always learning new things, there’s always new technologies. Like you’ve got Go coming to the fore now, Elixir. Ruby was the cool kid back before, and now it’s kind of getting to the enterprise-y, “Yeah, everyone’s done Ruby,” kind of level. So yeah, that’s my origin story in a nutshell.

E: And how did you come to be so interested in Ruby on Rails?

B: Between doing HTML and CSS, I went and did a Network Engineering degree. And while I was doing that, to pay for all my little extra purchases around the outside of that - like my parents wouldn’t give me pocket money, I had to work for my living - I was working at a supermarket which paid close to minimum wage, which isn’t so bad in Australia admittedly. But I was doing PHP work on the side of that as well. And I was doing all this contracting stuff, getting paid a lot better than what I was getting paid at the supermarket. So I wound back my supermarket hours and started doing more PHP contracting. And then a friend of mine said to me, “Hey, you should check out this Ruby on Rails framework.” And I watched the initial video with DHH, where it goes, “Whoops” a lot, “and look at all the things I’m not doing.”

E: Yeah I’ve seen that too.

B: Oh, it was just fascinating, because I loved it. And I was like, “This is so much better than PHP.” There’s little containers that you can put your things in, whereas PHP was - you’re just going to chuck all the database logic in the file, all your view logic in the file, all your controller logic in the one file. And Rails gives you these little boxes. And there’s a video by Gregg Pollack and - what’ his mate’s name? Jason something. And they did it, they did it exactly like they had little jars of things. And they’re like, “These are your controllers, and these are your models and these are your views.” That just resonated so strongly with me. Over the next couple of months, I stopped being a PHP programmer and became a Ruby on Rails programmer.

E: That’s great. And you’ve spoken at a number of conferences as well?

B: Yeah, I’ve been around the world, speaking at probably too many conferences. I love the Ruby on Ales conference, which just happened in March this year, and the 4 years before that. It’s a fantastic little conference. And I’ve spoken at Spree Conf, Red Dot Ruby Conference. Trying to think all the conferences. A few, yeah.

E: That’s great. You write on your blog at about how much you value the community and how good people are generally that you encounter within it.

B: Yeah. The first kind of speaking gig I did was at the Adelaide Ruby Users Group, and talked about creating models and Rails, I think it was - I’m very glad it wasn’t recorded, it would be very embarrassing right now. But since then I’ve talked at - we have these events in Australia called “Rails Camps.” And what we do is we get like 100 nerds, and I think this one is going to be 170 nerds, and we go out to some remote location. There was one in New Zealand a couple of years ago where we went to the top of a mountain which had no radio, no TV, and one phone line. There was no phone, no internet, nothing - just completely disconnected from the world. And so we mirrored Ruby Gems, took it up to the top of the mountain and coded Ruby, Haskell, Javascript, whatever for 4 days.

E: Wow.

B: And so we have those little events, and that’s the kind of community that I really enjoy - going out to these events and spending time with people who are doing very similar work to what I’m doing, and seeing what they’re doing. And seeing how they’re doing it, and learning from that.

E: For people who aren’t maybe familiar with it, what’s the tech community like in Melbourne where you are?

B: Oh it’s very, very - it’s busy, is a good word for it. There’s JavaScript meetups, there’s Ruby meetups, there’s Go meetups, there’s Elixir meetups, there’s Haskell meetups, Functional Programming meetups, PHP web dev. If you’re a web dev in Melbourne and you don’t have work, there is something wrong with you.

E: So there’s a vibrant startup ecosystem happening there?

B: Yeah, yeah. There’s a huge startup ecosystem here. We’ve got AngelCube, which is run by Nathan Semp– I can never say his name right, let’s just call him Nathan S [it’s Nathan Sampimon - Ed.]. And he runs a startup place, I guess you could call it an accelerator. They all have a bunch of startups in a place called Inspire9, it’s a nice office space that I worked out of, two years ago now.

E: I wanted to ask, you have a great post called “Congratulations” where you you tell a story that seems like there might be some biographical elements to it, about how you got into test driven development and behavior driven development. I was just wondering if you could maybe tell us a little story about how that became so important to you.

B: Oh it’s based on a true story. In 2008, I was working for a company and we developed this learning platform. Before learning platforms were cool for people really, that was the original. You know the classroom students, that everyone builds eventually? Those kinds of applications. We were building one of those, and I changed this part of the application, which had a count of - I think it was maths classes. And the count was wrong, so I changed it. And then the client called my boss, and my boss said, “Hey you changed the count, why did you change the count?” I said it was wrong. And he’s like, “No, no, no. It was right, that’s the way the client wanted it.” And without the tests, we had no way of proving that. We had no way for certain that change was exactly correct or wrong or whatever. And there was much more serious issues past that. One day I removed the Hpricot Gem, which is a precursor to nokogiri. And that took down production when somebody else deployed production the next day, because there were no tests asserting that our code was actually working. There was parts of the code depending on Hpricot that I didn’t realize, and we had an angry phone call from the client. I actually ended up getting fired from that job because I wanted to do testing, and I was arguing for testing. And the boss was like, “No, we don’t have time for testing.” And then when I would break things, I would say, “Well if these were tested then things wouldn’t be breaking as often.”

E: Right. And I remember the second part of the story was that you went to another place.

B: Yes.

E: And there you successfully convinced them to use testing, or they already were?

B: They were already using testing. That’s when I was working for Dr Nic, and that’s when I saw the light. Dr Nic, the famous Rubyist from years and years ago - one of the original famous Rubyists. I got to work under him, he’s fantastic. I tell the story all the time. I’d take a feature to him and he’d say, “Does it work?” And I’d say, “Yeah it does, let me show you.” And I’d click “login,” fill in the username, fill in the password, ns click “submit.” And he’d be like, “No, no, no, no,” show me the test. Or he’d ask me to run him through the feature again. He’d pretend like he wasn’t watching or wasn’t paying attention. And so he kind of hammered into me that, “If you’re not testing, you’re doing it wrong.” So I’m just testing all the time now, because I guess it’s kind of like a good form of post-traumatic stress.

E: Right.

B: Being hassled by him and heckled by him all the time has actually improved my craft. So, I guess it’s a net positive.

E: Can you explain, what is behavior driven development for someone who might not be familiar with it?

B: So behavior driven development, my understanding of it is that you want to test that part of your application is working in a specific way. Let’s use the login example again. You want a link that says, “login.” Then you want a form that has a username or an email field and a password field and then a “submit” button at the bottom. You want to make sure that when a person enters a valid username and valid password and hits the “submit” button, they can log in. So that’s the behavior that you’re testing. Before you do any work, you write the test, then you make the test pass, you add the login link, you build the form. And you build all the other associated code around that, and then it passes. And that way if that feature breaks in any way, like if the login link goes missing or the field gets changed, or the underlying authentication logic changes, you have a test that can break if that changes. Also, if you’re building another feature and a bug pops up, you can write another test with that existing framework, and that existing framework provides you that way of writing regression testing. And regression testing I think is the big win of behavior driven development and test driven development, absolutely.

E: I imagine there must be a category of developers who also, in addition to clients and bosses, don’t want to do testing?

B: Yeah there are, there are. And I do try and convert them when I come across them.

E: How would you characterize resistance to testing from the developer’s side?

B: If you asked me this question I think three, four years ago, I would have said, “They’re stupid.” And now I’m just like, “Mmm well, there are merits to it.” There are merits to not testing your code. You can develop the code much quicker, and you can build the prototype. But then I wouldn’t go using that prototype without tests around it. So I’d chuck out the prototype, rebuild it with tests, and assert that it’s actually working correctly. And I try and tell people this, and some of them listen. That’s why I built a book around test and development, I think that’s the only proper way to build an application, is to write the tests. All my books that build applications, so Rails 3, Rails 4 in Action, Multitenancy with Rails - build tests first, and then they build the functionality, because I think that’s the right way of doing this.

E: Speaking of your In Action books, they were published with a traditional publisher. And you have a blog post where you talk about your breakup with them, and how you have great respect for the people there, but it was their tools and workflow that drove you away. I was wondering if you could explain a little bit about what that experience was like, and how important the toolchain must have been for you to make that kind of a decision?

B: They’re bloody muppets. I like the people there. They’re well intentioned, they’re technologically illiterate. That’s how to put it lightly. The tool chain was writing in Docbook, which is XML. And so I was handcrafting XML. So to start a paragraph, or to start a book, you’d have a book tag. And then inside that, you’d have a chapter tag, and inside that, you’d have a section tag. Inside the section tag, you’d have a paragraph tag or you’d have a listing block tag, which contains a - there’s like 3 tags you need for a titlized code example. And writing that was exceptionally painful. But then you had to upload it to their SVN server, which might have had conflicts. So you’d need to pull down the SVN server, which everyone else uses. So you’re pulling down everyone else’s changes at the same time. Then you need to click, you need to login to the Manning website, find your book in the list of all the books they’ve ever published, click on the little book icon, click on the chapter, scroll down to the bottom of lists of revisions that have ever been processed for that chapter. Click on the little radio button at the bottom, and then click on “update.” And that would update it for the editor.

So I got upset with that process I think about two months in, and I built my own review system, which I called “Twist,” because every good book has a twist. And so I built Twist, and I built it overnight. I started about 2 pm that day, and at about 11pm I think it was, I was furiously coding. I was actually angry for the first couple of hours, and then I was just like, “This needs to get done, and wouldn’t it be cool if it did this? And wouldn’t it be cool if it did that?” And I went downstairs at about 11pm and thought, “That’s weird, my housemate’s not here.” He was always forever on the couch, or forever on his dining room table. I’m like, “What’s going on? Like he’s usually here, isn’t it dinner time?” And then I finally see the actual time, I didn’t realize it was 11 pm at that time.

E: Oh wow.

B: I look at the microwave and go, “Holy crap, I’ve been coding for 9 hours.”

E: Wow.

B: And I’ve just been in my own little hole for nine hours, and I’ve built this thing and it works. And now I’m bloody hungry. I’m going to have some food and go to bed. So I built that, and people were very happy with it. And that tool is what helped me write Rails 3 in Action. Not Manning’s review tool chain at all. With Twist, I was able to add my own reviewers. They were able to leave Markdown-based comments, and it was just so beautiful to work with that system. I’d never write a book in Docbook ever again because of it.

E: I imagine the reviewers that you brought into Twist responded positively to it as well, probably in comparison to the other - I mean, review systems are kind of primitive, if they exist at all.

B: Yes that’s right. These other reviewers never got to see Manning’s system. Manning wouldn’t let them in, because it gives them access to all the other books. Only authors who are contractually obliged to not share the other books, are allowed access to that system.

E: I’m not sure if there’s necessarily an answer to this question, but why do you think that conventional publishers are so resistant to improving the way that authors write books, and then work with their publishers to produce books? Because we hear this at Leanpub. I’ve had personal experience with it. Leanpub’s co-founders have had personal experience with it. What’s your opinion about why people who ought to be in the business of making books aren’t motivated to make the process of making books better?

B: It’s worked this way forever, and retraining the people to use new systems is going to take too much effort and too much time. Developing the new systems can come with their own pitfalls. There’s always the thing that the grass is greener on the other side. And if you develop a new system, it’s going to be better than the old system. It’s not going to have the problems that the old system - sure that might be true - you’ll learn the lessons from the old system, and you apply them to the new system. The new system’s going to come with problems though. Same as if you rewrite an application, you’re going to learn from the old application. And the new application’s going to come with its own set of issues. I think that they’re resistant to change because it’s a high risk scenario. It involves them having to cut over from the old system to the new system, and they don’t want to invest the time in that at all, because the current system is working okay - they are pushing out books. But they are not pushing out books as quick as they can, and they’re not making the process as painless as they can - and that is mainly what I have the issue with, is that the tool chain gets in the way, makes the authors unhappy, makes them not want to write books. Steve Klabnik, my co-author actually got burnt out on Manning’s tool chain, and that’s why he didn’t finish Rails 4 in Action. And Rebecca Skinner and I had to finish Rails 4 in Action, because Steve couldn’t because of the tool chain.

E: Wow, that’s incredible. I mean, that’s a much less cynical explanation than some people give for why many different companies. One of the more cynical explanations is there’s somebody who sees this new tool chain, and sees that it doesn’t include the type of work that they’ve been doing, maybe for their entire career. That it’s not necessary anymore. And that in addition to the obvious motivation someone might have to block a new technology because it might take their job away - and that’s something to be very sympathetic to - there’s also the aspect of seeing the activity that you’ve based your career on is just now longer necessary, and there’s just something kind of heartbreaking about that.

B: There’s all this typesetting work that Manning does as well. “Rails 4 in Action,” in my opinion, should have been published already. They’re typesetting it so it can be printed. And the issue with the printed book is it’s going to run out very quickly. I think that printed technology books are dead and there should be no need for them anymore. Manning disagrees.

E: That’s interesting. My next question was going to be, how do you see the computer book market evolving in the next 10 years? In addition to what you’ve said about paper technology books kind of going away, for all sorts of reasons, including they don’t match the timelines of technology development, do you see authors making a decision like you did to essentially go independent?

B: Yeah I do, definitely. The big publishers take too much of a cut for the work that they do, in my opinion. And holding back my cynicism on Manning, and I feel it leaking through at the moment, I’m not sure how much I can say on public record, but I was not pleased with them the last time we talked with them.

E: Okay, okay. I mean it’s up to you - that’s why I’d like to talk about the market more generally.

B: Yeah, the market more generally - I think that people are not going to go to the big publishers if they have sense. So I think Leanpub’s going to - Leanpub is amazing for publishing independently, away from publishers. The cut you get is much more reflective of the work you put in. An author, I agree, puts 90% of the work in, and the publisher does 10% of the work - and that’s what the cut should be financially, 90% and 10% plus 50 cents and whatever. I think that’s Leanpub’s cut?

E: Yeah, the author royalty is 90% minus 50 cents.

B: That’s it.

E: And then we’ve got fees and stuff like that, but yeah that’s the royalty rate. We do feel it at least reflects the amount of work that an author puts in, especially if they’re self-publishing and managing all the other processes as well. It’s interesting, I was talking to someone the other day who was saying - he’s an academic, in the sciences, and he went away from academic publishing partly because his academic publisher wouldn’t even do the formatting anymore.

B: What?

E: Yeah, yeah. He was being asked to do the formatting for his own book. I remember I was at this thing called BEA, Book Expo America, a couple of years ago. It’s the big publishing industry jamboree in New York City every year, and Guy Kawasaki was giving a talk. It was this panel on self-publishing that everyone was a little bit trepidatious to go into - not him obviously, and not people who are into self-publishing, but the regular attendees. And he said, “Look, the last time I spoke with a publisher about publishing my book, they said, ‘So how are you going to leverage your Twitter following to maximize sales?’” And he’s like, “Well what, what do you mean? How are you going to market my book should be the question. Not how am I going to market my book.” And then he went off and wrote a book called, “APE,” about self-publishing. So I’m really glad to hear you say that, because I’m also starting to hear that noise coming more - or signal, sorry I should say, coming more from people who aren’t even technical authors, but people who are in sort conventional trade publication kind of stuff, like fiction and biography and things like that. I’m starting to hear that yeah, people are getting more and more frustrated because publishers are reacting to the changes that have been happening in the world - not necessarily in the most productive ways.

B: That’s right.

E: And it’s in that context that I’m just so surprised that every time, even though I know it’s coming, I’m still surprised that a publisher would damage its authors, like the process you’re describing. And even lose them because they just won’t change their system. I mean, there’s just something so deep

B: Yeah it felt like Manning didn’t want to keep me around. Even when I was writing “Rails 3 in Action.” It’s more that they wanted to get a book published. And that they didn’t want future - I don’t know how to put it in words properly. It’s like they just wanted the book published, and that was it. But then the contract beholds me to - If I want to write future books following a similar topic, like if I wanted to write a new, “Introduction to Rails” book, for 3 years after “Rails 4 in Action” is finally published…. So let’s say it’s published next month. I can’t publish a new Rails introduction book until July 2018. So in a way, they want me to write the book and publish a book. But then they don’t want me to write another book. They’re not doing anything to keep me there. Because it’s in their business’s best interest to keep me on board and to keep me publishing books through their platform - in my opinion. Just like it’s in Leanpub’s best interest to not piss off their authors, right?

E: Yeah.

B: Every publishing platform’s business is to make sure they can keep producing - the authors keep producing books, and bringing in the dosh. If you’re doing things to make the authors unhappy and to push them away from your platform, doesn’t that kind of counteract the whole point of the business existing in the first place? Which is to publish books.

E: Yeah you’d think. And we hear this time and time again from people who are like - they don’t go into it vain. They go into it feeling honored or flattered that a publishing company is going to take them on. But by the end of it they feel often like a used product.

B: Yeah.

E: Or a tool themselves, rather than something that’s respected. And anything you make, that you probably care about in your life - there’s something about a book. It’s a long thing that you care about, probably something that you feel you’re very good at and that matters to you. And then probably something that’s going to fit into your life in a certain way, you’ve been telling everybody that you’re working on this book, and you want to fulfill that claim. Afterwards you can put it in your CV, and it can get you speaking engagements and things like that. To the author, it’s just such an extremely important activity. And then to be - I just think people are surprised that suddenly they’re being treated negatively in that context. Like, “Why would this happen?”

B: It’s like, “I’m trying to help you, and you’re not listening to my advice.”

E: Yeah.

B: “My advice is to build a better publishing tool, and you’re not doing it.” But it is a huge honor. I was so excited, I remember going over to the supermarket, and immediately after seeing the Manning email, and almost skipping there out of excitement, I was just so happy and radiant. And then it went downhill from there and just - and now I really don’t like traditional publishers. It sounds counter-intuitive to their business entirely.

E: Hopefully moving onto happier things, how did you find out about Leanpub, and why did you choose it as your publishing platform?

B: I can’t remember exactly how I found out about it. This always happens with things. I find out about things, and I’m like, “This is a really good tool.” And then I don’t remember the origin story. I believe somebody - I was raging about, “Rails 3 in Action” at the time. And somebody recommended Leanpub. They’re like, “Why don’t you publish a new book on Rails through Leanpub?” And I was like, “No, I can’t do that because I’m beholden to Manning because of this contract.” And then I came up with the idea of “Multitenancy with Rails,” and I was like, “Wait, I remember Leanpub, I’ll go to them and see what I can do.” I was like, “You guys write with Markdown,” and I love Markdown, Markdown is fantastic format for books. It’s not the best format, but we’ll get to that in a moment. It’s good enough for what it does, and the royalty split was nice, the site was great - much better than Manning’s site. The checkout process - if you compare Leanpub’s checkout process and Manning’s checkout process– Oh my goodness, there is like 15 years of software development difference between the two. I’m not kidding, that’s quite a long time in web dev, in web dev land. And it’s just nice. It’s like driving an old 1986 bullshit car and then I’m in this brand new Lamborghini off the lot. I’ve never driven a Lamborghini, and I don’t hope to, because I reckon I’d wreck it. But it’s just - it’s so nice, it’s - it was like being freed from prison.

E: I assume you used the Dropbox workflow?

B: That’s right, yes I did.

E: It’s where you write in your own favorite text editor on your computer, and then sync to Dropbox, and then click “preview,” and “publish” on Leanpub.

B: That’s right, yeah, yeah. So I write all my things in Sublime. And I’ve tried a lot as an editor. It’s brilliant. Enough vim bindings that I can use. And yeah, it’s neat. And then yeah, Dropbox and publish on Leanpub. And it’s - if I want to publish today, I can publish today. With Manning I can’t do that.

E: Right.

B: And I have to go, “Look, I’ve got these updates, they’re in SVN.” And they’ll go, “Okay we’ll typeset them and we’ll publish them.” And like I said, “Rails 4 in Action,” has been content complete - I didn’t say that it’s been content complete, I said it could have been published in April, but it’s been content complete since April. And so it could’ve been published in April. It’s now June, and it hasn’t been published. Because they’ve been typesetting and indexing and all the other stuff that no one really cares about in a tech book.

E: Yeah, okay. And you wanted to talk about Markdown?

B: Yes.

E: Indicating it’s not necessarily the best way in your opinion to write a book?

B: Yeah, my wife’s a lawyer, and she has a great saying that, “three lawyers, four opinions.” And Markdown processing is exactly the same way. You have - Markdown is, you’ve got double, like double pound sign and a heading. And the rest of the content - it can be presented in one way if you use this Markdown parser or another way if you use this other Markdown parser. Or in a completely alien way if you use this other Markdown parser. There’s no really - what do they call it, schema, syntax, reference guide. And I know that Jeff Attwood and his crew were trying to work on one. I have no idea how far that’s gotten. But there is a much better format out there that I found called AsciiDoc, and that is like - it’s like if Markdown was designed not by one guy. It’s like - Markdown was designed using the PHP design technique of - one guy released this library and then everyone used it. AsciiDoc was built with this guy - it was like, “Okay, I’m going to take the good bits from Markdown, and I’m going to put my own stuff on there, and we’re going to work collaboratively, and we’re going to build this format called AsciiDoc. And it presents tables well, does images, and presents these beautiful looking previews with this library called Asciidoctor, which is what I’ve been using for my, “Deep Dive Rails” book, which I’m also publishing through Leanpub. And it’s nicer in ways to work with Markdown and not as nice to work with in other ways with Markdown. It’s kind of a tradeoff. Overall, it’s fantastic to work with.

E: Okay, thanks very much for that and for letting us know. Actually Peter is actually working on a new syntax called Markua.

B: Oh yes.

E: Which is meant to solve some of the limitations of Markdown when it comes to writing books. So it’s basically supposed to be a superset of Markdown, but specifically for writing books.

B: Nice.

E: So yeah, hopefully we’ll get your opinion about that at some point and then see what you think. Hopefully it solves some of those problems. But obviously we’re very respectful of the fact that people have different preferences. And we want to accommodate as many reasonable preferences, because writing is such a personal, time consuming thing. That’s why, so for example the first - well one of the most important workflows we have is working in whatever editor you like in Dropbox on your computer. We do have an online editor and we do have a couple of other workflows. But that’s the most important one for us, that people are as happy as they can be. And we want, it’s just like anything else - like, when a carpenter is hammering away with his hammer, he shouldn’t be thinking about the hammer. The hammer should just be an extension of what he’s trying to do - same thing with writing tools and tool chains. On that note, I noticed that in “Multitenancy with Rails,” you include your personal email address in a section at the beginning for feedback, and you invite people into Twist as well if they want to be a part of it. Is that something that you would like - would you like Leanpub to actually facilitate that process?

B: Yeah, I’d love Leanpub to have a review system, that’d be great.

E: Okay.

B: PragProg has this - I think it was designed back in 2007 - they have an errata page. It looks very old school, and it’s

E: I’ve seen it.

B: Yeah, it’s not, it’s not the prettiest thing to look at. What I’d like to see is like, “This thing is wrong with the book.” And you click in, you’re like, “Oh what does this thing mean?” So you click on it, and you’re like - okay. this is the section that it’s commented in. So this is like a paragraph or a code block. And underneath it are all the comments related to it. So it’s like, say that the author’s written a very complex piece of code, and then other people underneath it have commented and said, “No, no, you don’t need to write it like that, you can write it like this or like this.” And then the author can see it like, “Okay, this is the - good way to write it.” And you can have a discussion around how to, how to improve that one little section. And that’s why I built Twist, is that you can have discussions around that little section.

E: Oh okay, so it’s discussions rather than sort of logging errors or something like that?

B: It can be both.

E: Yeah okay, okay.

B: Yeah so, I have these run-on sentences all the time in the book where I have too many commas. And people are like, “Well wouldn’t it sound better if it was written like this?” And then I come back and I say, “Well, this is how I say it out loud.” And I put in the commas where I paused if say - If I pause out loud. And they’re liek, “No, no, no, that’s not good.” And then we talk back and forth and we come up with a proper way of saying whatever it was we were trying to say in the book.

E: Okay, okay.

B: It’s nice that way.

E: What would you think about if we added reviews? Because we currently actually don’t have reviews.

B: Reviews in general, like five star reviews?

E: Well both stars and written reviews, like Amazon-style. If people could actually go - if users could go onto Leanpub and write reviews of books, is that something that you would - if we made it opt-in, is that something you think you might opt into?

B: Yeah, yeah. I’d definitely use that, yeah. Because I think that’s a good marketing technique. And we’ve been talking about this - Marketplace are actually - been talking about having product reviews. And that is, according to my sources, that is how to get people to buy your products. If a product has good reviews from other people - say it has four and a half stars, five star reviews from 30, 50 people, people are like, “Wow this must be good.” Like our microphones, right? We bought our microphones because they had awesome reviews. If it was just like, “Buy this Yeti microphone, it’s $200,” Who would buy that? And then they’re like, “Wow, it’s 5 stars. It’s also all these great features and we love it. It’s crystal clear quality and all that.” The reviews on Leanpub would be a good feature, and I would definitely use it.

E: Okay, okay. Is there anything else about Leanpub that you think we could improve? That’s what we’re here for.

B: Not at this point in time, I’m very happy with it. And all of the new design too.

E: Oh well great, thanks very much, we’re really happy to hear that. That was a long time coming, and we’re very happy that it’s finally out. My last question is that - I see “Debugging Ruby,” your next book, is 40% complete. Do you have a timeline for when it’s going to be finished, or does that matter to you?

B: “Debugging Ruby” is a book that I’m writing really whenever I feel like, or whenever I come across an interesting debugging thing in Ruby.

E: Oh I see, okay.

B: I had a debugging session probably a year and a half ago with a friend of mine, where he was entering a valid username, and a valid password into his login form, and Devise was saying it was invalid. And he would go into the console and he would load up the user. He did like, user find, user authenticate, password’s good. So what was going wrong? Well, if you want to find out, you read, “Debugging Ruby,” that little chapter, “The Devise bug.” And it walks you through exactly what was going wrong in that. And any kind of little interesting debugging stuff and debugging tips. And yeah, so when I think of something to put in the book, I just put it in the book.

E: That’s interesting, we actually had - I was doing a little bit of internationalization yesterday. And we had a really funny thing happen where we got a Norwegian translation so an author can have a Norwegian landing page if they want, if they’re writing their book in Norwegian. And you localize in YAML, right? And the 2 letter code for Norwegian is NO, colon. And so everything was blowing up, and it’s because it was reading it as a Boolean value, rather than a string.

B: Yeah.

E: Like it was NO. My first instinct when it was breaking was that that’s probably the problem. I’m not a developer, I just do like little things here and there. And one of my colleagues was like, “No it can’t be that, it can’t be that dumb.”

B: Yep, NO and YES are reserved things in YAML and they mean true and false.

E: Yeah, yeah.

B: And nobody knows that, except people who have been bitten by the bug.

E: Yeah.

B: Maybe I can chuck that in the book?

E: If you wanted to. Anyways, I just wanted to say thank you very much for participating in the Lean Publishing Podcast, we really appreciate it. And thanks for being a Leanpub author.

B: No worries, happy to talk to you today.

E: Thanks.

B: Thanks Len.

This interview has been edited for conciseness and clarity.

Emailing Leanpub Readers

by Peter Armstrong

published Jul 29, 2015

A few months ago we removed the “Email Your Readers” feature, which let Leanpub authors email their readers separately from the emails they can send when publishing a new version of a book. We built the separate “Email Your Readers” feature in the first place because we know how important email can be for marketing to people who have already shown interest in you and what you’re doing. However, we realized the feature had a structural problem, and in this post we want to explain why we removed it, and why we’ve built a better way to contact your readers by email for marketing purposes.

(tl;dr version: The old feature was opt-out and our new MailChimp integration is opt-in.)

We took a look at all the “Email Your Readers” emails that had been sent in the previous year or so. It turned out most of these emails actually contained information about updates to the book, which really should have been sent using the book updates email feature, since it automatically includes links to the new version and was built for that specific purpose.

The rest of the emails to readers were mostly marketing messages about new books being released by the author or for other products from the author. The majority of these were well-received by readers.

However, a significant minority were seen as spammy and resulted in both angry emails from Leanpub readers and in emails from Leanpub being flagged as spam. The former is bad enough, but the latter is a huge problem for us, as it’s important that Leanpub is able to get emails into your readers’ inboxes to let them know when you’ve updated your books.

We understand the huge value of marketing through email lists, and we believe authors who are serious about promoting their own books should have their own mailing lists. We’re not trying to get between authors and their readers. We just want your marketing mailing list to be opt-in, unlike the book update list, which is basically the only thing we think should be opt-out, since people who buy Leanpub books are assumed to be buying them in part because they can be updated. (To be clear, we never give actual email addresses to authors unless readers have opted in; our email feature hides reader email addresses from authors.)

So, given the importance of marketing email lists and the importance of only using opt-out emails for book updates, what’s the better feature?


To turn on our MailChimp integration, click on “Mailing Lists => Reader List Settings” in the author app sidebar for your book. There will be a blue “Authorize MailChimp” button, which will allow you to connect your MailChimp account to Leanpub. (Of course, you’ll have to sign up for MailChimp first if you don’t have an account.)

Once this is set up, any new readers of your book will be given the option to sign up for your mailing list. You can also import the readers who have already opted in by using “Mailing Lists => Collected Emails”.

In the future we plan to add a lot more community stuff in Leanpub itself, enabling authors to offer coupons for new books to readers of their other books and facilitate discovery of related books, etc. Basically, we want to help authors to promote their books in a way that doesn’t seem like spam from the author or from Leanpub. This will only really work once we have an improved mobile app, better web experience, etc. But the point is that you don’t need to wait until future features are built–you can use our MailChimp integration today.


Peter, Scott & Len

A New Role for Len at Leanpub

by Peter Armstrong

published Jul 13, 2015

Today Len Epp has a new title at Leanpub, one that is long overdue:


Although Len wasn’t at Leanpub on day one, he has been instrumental to its growth since joining in 2012. When Len joined, Leanpub was doing about $1,000 a month in sales; we’re now doing well over $100,000 a month and growing.

Sometimes when we’re arguing about a new feature or direction for Leanpub, and Len thinks I think he’s losing, he likes to troll me with this chart:

Len Joins Leanpub

My troll response is that I’m so good at forecasting that I knew this would happen, and that we’d need to bring him on to help cope with it. More importantly, the next 100x of growth will be harder than the previous 100x was, and it goes without saying Scott and I are thrilled that Len became an integral part of the team early on.

Incidentally, Len has a long history of arguing with me: we met in grade 9, in high school, where we enjoyed doing cool things like designing board games and reading existentialist literature. Eventually, we headed in opposite directions but remained friends: I went west to Victoria, British Columbia to do Computer Science and Psychology at the University of Victoria, and went on to the bay area, where I did an internship at SLAC before spending 8 years as a software developer for Silicon Valley startups. Len went east, doing a D. Phil. in English at Balliol College, Oxford, and then becoming an investment banker in London, before coming back to Canada, co-founding a non-profit in Montreal and then joining Leanpub. Len recently moved from Montreal to Victoria to be with the rest of the team and focus on taking Leanpub to the next stage in its development.

Leanpub is still a bootstrapped startup where everyone does a bit of everything, and Scott, Len and I each manage client projects for Ruboss in addition to our work on Leanpub. As our resident corporate finance and literary type, Len’s interests complement my focus on product and Scott’s focus on tech. Functionally, Scott and I consider Len to be a cofounder, so we’re now making it official.

Congratulations, Len! The next phase of Leanpub is going to be the most exciting yet, and you’re going to be crucial to it.