An Interview with Taylor Otwell, Author of Laravel: From Apprentice To Artisan

Published Sep 19, 2013 by Len Epp

Taylor Otwell is the author of the Leanpub book Laravel: From Apprentice To Artisan.

Taylor is the creator of the Laravel PHP framework, one of the most popular open-source PHP projects in the world. He is also a Software Engineer at UserScape.

This interview was recorded on September 3, 2013.

The full audio for the interview is here. You can subscribe to this podcast in iTunes or add the following podcast URL directly: https://leanpub.com/blog/podcast.xml.

Len Epp: I’m here with Taylor Otwell, creator of the Laravel PHP framework, and a Software Engineer at UserScape. Since it was created in 2011, Laravel has become one of the most popular open-source PHP projects in the world. The framework has a large, growing, and devoted community, with thousands of developers using it to build web applications.

Taylor is the author of the Leanpub book, Laravel: From Apprentice To Artisan: Advanced Architecture With Laravel 4. In this interview, we’re going to talk about Taylor’s career, and the creation and development of the Laravel framework. We’ll also talk about his book, his experiences using Leanpub, and ways we can improve Leanpub for him and other technical authors.

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

Taylor Otwell: Thanks for having me. I’m excited to be here.

E: Thanks! I’d like to start by asking you for a brief introduction to your career — how did you get interested in programming, and what led you up to the point where you created the Laravel framework?

O: I’ve been interested in computers ever since I was a kid, like probably many of us were. I went to Arkansas Tech University here in Arkansas, in the United States, and majored in Information Technology. In college, I learned kind of the basics, C++, you know, but I wasn’t really familiar with open-source programming or programming as a hobby, or hacking, you know, and when I graduated from college, I went to work for a large trucking company here in the US called ABF Freight. There, I started doing mainframe COBOL and .net at the same time, which was kind of an odd mix. They actually had a six-month training program, taught me .net. One of the great things about working with ABF, was I worked with a very good group of programmers. They taught me a lot about programming, a lot about software design, and started to introduce me to open-source software. So now, I was doing .net at work, but in my free time I had ideas for side business, or whatever, things I thought I’d like to start. I knew from my college experience that PHP was a popular web language, that was cheap to host, and so I thought, Hey, why not? I’ll learn some PHP and hack on some of these ideas at night. It’s cheap to host, I can just throw the files up on a server, and I’m good to go. So, that’s how I started hacking and working on PHP.

Now as far as the Laravel framework, I was using another framework called CodeIgniter, I was continually hacking the core of that to make it behave more how I thought it should behave, from my experience with ASP.NET. I wanted things like dependency injection, and a better templating system, a better ORM, and so I started hacking on Laravel in my free time at night, and released it after about five or six months of working on it. It was a very small framework at first, but of course now it’s grown to be quite popular, and a full stack framework.

E: Did you work on it independently, or did you have people helping you along the way for the first release?

O: I worked on it totally independently. I did all the coding, and of course drew inspiration from other projects, so indirectly, there was lots of help from projects that were built before mine. But yeah, I was the only one doing the coding.

E: Was there a particular type of developer that you had in mind when you were building it? Is there a particular type of person that it clicks with?

O: It seems to click a lot with people who want to build something very rapidly. People who like lots of great documentation. From the very first day that I released Laravel, I had total and complete documentation over the project, because I knew that documentation was king for new open-source projects. If a project was thrown out there with not very thorough documentation, like a lot of projects are, it’s a lot harder for it to gain steam. So I knew that even if the framework wasn’t the best PHP framework out there on the first day of its release, if it had good documentation, that I could build a solid community around that, because people would be a lot more inclined to use it if they could learn more about it from the docs.

E: It must have been very exciting to see the community develop around it. Did that happen quickly, or did that take some time, and did you have to do a lot of encouraging?

O: It took a little bit of time. Building a community nowadays is a little bit easier, thanks to things like Hacker News and reddit — you can gain some early adopters pretty fast. So, early on we probably had a few dozen people that were regularly using it, and that quickly ballooned, and a lot of that because I was very persistent in doing screencasts, new features. Laravel at first was kind of half-framework, half-marketing effort by me, so I was constantly trying to put new information out there, advertise new features on various PHP websites, and keep getting the word out, even after the initial launch.

E: You’ve recently, just earlier this year, released version four. Can you tell me a little about what’s new in this version?

O: With version four, we wanted to make a big architectural change under the hood, because versions one through three were kind of, we were still feeling our way toward how the framework should behave, and how we wanted it to look. With version four, we knew we needed to improve on a few things. One was testability, we needed the framework to be very testable out of the box. We wanted good PHPUnit support out of the box. So that was a big focus. We also wanted to start playing nicely with Composer, and we adopted Composer, which is a PHP package, kind of installation system, sory of like Bundler for Ruby. We adopted that as our primary way of distributing packages. So that opened up a whole ecosystem of packages that are easily installable and integrate really well with Laravel. I think that’s going to be very beneficial for years to come.

E: Were your decisions about new functionality and features driven by signals you were getting from your community?

O: Yeah, they were. I’ve always been really involved with the community personally. Early on, in the forums, and now more with IRC and Twitter, but I’m always listening to community feedback and seeing how things are trending. Plus I work on a large Laravel application day-to-day myself. So, I tend to identify the awkward spots in the framework fairly quickly too, because I’m using it so much, in a real world setting. The community drives the development in a lot of ways, and I add my own insights here and there too.

E: I’ve seen people refer to the community as a “family” online, it seems very friendly and supportive.

O: That was one of the goals from the start: to have a very inclusive community, but at the same time not a stagnant community. We want to be very welcoming of newcomers, so to speak, but we don’t want to dumb things down too much. We want to encourage people to grow, and that’s one of the things people tell about Laravel, is it sort of grows with you, in the sense that, when you first start using it, it’s very easy to build out an application, and to get some basic routes going, to log people in, to put some stuff in the database. That’s all very quick and easy. But at the same time, it grows with you, and as your architectural skills grow, you have access to more powerful features, like the IoC container, like background queueing, like doing some Redis caching, and more powerful features. So the framework sort of evolves as you evolve as a developer, which is kind of nice.

E: That’s fantastic. I know you’ve just returned from Laracon 2013, which was a two-day Laravel conference based in Amsterdam. I think that was the second Laravel conference that’s happened, and the second this year. Can you tell me a little bit about how it went, and what the highlights were for you?

O: Yeah. So, like you mentioned, this was the second Laracon. We’ve having an annual Laracon US, and an annual Laracon EU right now. The first one was in Washington, DC, and the second was in Amsterdam. I think it went really well. We actually had Fabien Potencier — I’m sure I’m not pronouncing that right! — he is kind of the maintainer of the Symfony framework, which we use, so we consume about seven or eight of their components. We also had Jordi from the Composer, kind of co-maintainer, so that was really great, because we had some prominent members of the PHP community that don’t necessarily even use Laravel on a day-to-day basis, but have had a big impact on Laravel. I think people enjoyed meeting them, and talking to them, and bouncing ideas off them. It was just a fun time of hanging out. You know, conferences are always kind of like, half-learning, half-social, or maybe even like 60% or 70% social, 30% learning. So yeah, it was fun to hang out with everybody, meet people you’ve talked to online, and stuff like that.

E: I was going to say, it’s must be very interesting, I mean it’s probably been a roller coaster couple of years to go from just launching something you built on your own, and now you’re going to a conference in Europe and meeting, I would imagine, a few hundred people who are using it.

O: Yeah, it’s really crazy. It’s just kind of wild. It’s weird, to go somewhere, and have people say they’re using Laravel. It seems like not too long ago I was sitting in my office building it. It was fun to meet people that I’ve known for a couple years now.

E: You mentioned your day-to-day work at UserScape. Can you explain a little bit about what UserScape is doing?

O: Yeah. At UserScape we have two products, we have HelpSpot, which is an on-premise help desk solution. It’s very powerful, very flexible. And you actually can download it and install it on your own servers, which is nice, a lot of companies really like that. Our second product is Snappy, which is also a help desk solution, but it’s a little lighter-weight. It’s a SaaS application, so you actually just log right in, over the internet, you don’t need to download or install anything. It’s working out really great, and it’s got a great interface, live-updating with your emails, and you can assign stuff to other people, using @ tags. You can hashtag emails to categorize them, so it’s a really cool app — it’s besnappy.com if you want to check it out.

E: I’m sure some of our listeners would be interested to know how you manage being the architect of Laravel, with your work at UserScape, day to day.

O: I have kind of a routing schedule, where 8:00–5:00 I work from home, I work on UserScape stuff, that’s primarily Snappy, which is built on Laravel. And then, after work, from like 5:00 to 9:30 or 10:00, I just hang out with my family, and then after my wife goes to bed, I work on Laravel for a few hours, from say 10:00 to midnight, or 10:00 to 1:00. And then get up the next morning and repeat. Sometimes I’m too tired to stay up and work on Laravel, but usually a few days a week I get to work on it at night. And Ian, my boss at UserScape, also gives me the last week of every month to work on Laravel, when I usually go on a pull request rampage, and close like hundreds of issues. So that’s really nice.

E: That’s great to have that kind of support. I know you just released version four, but can you give me some indications about what you see in the future for Laravel, say next year, or even the year after that?

O: One of the complaints we had about Laravel early on was that we released versions really quickly. At first, that wasn’t really am issue, because we were all hacker, early-adopter types, so it was like, we don’t care if you break backwards compatibility, just give us cool new stuff. But as the framework has grown, and more businesses are using it, we had to kind of play it a little more mature, in terms of our releases. So we’ve adopted a six month release cycle, which started in this May. So that means Laravel 4.1 will be in November, and Laravel 4.2 will be in May of 2014. Right now, there’s no really backward-breaking being planned for those releases, but we are releasing some exciting new features. We’ve got some new components in the framework to let you make deployments easier. We’ve got some new debugging capabilities coming out for the release in November. So, we’‘ll have two point-releases, they’ll be incremental releases, adding new stuff but no major rearchitecting or anything.

E: I’ve heard you speak in a couple of podcasts at Laravel.io about the development of PHP in the last few years and how a lot of people who may make negative comments about PHP in forums often don’t even know where PHP has gone. Can you say a little bit about that, about how PHP has changed in the last couple of years?

O: Yeah. I tell people that when I first started writing Laravel, and using PHP a few years ago, I almost felt guilty for not using something else. You know what I mean? I almost felt guilty for not using Rails, I felt like less of a programmer. But now that PHP has grown so much, like 5.3, we’ve got like namespaces and closures, and now with 5.4 and 5.5 — I’ve talked to a lot of other people, and they felt the same way, you know, they felt like, Argh, I really shouldn’t be using PHP, I should be using Ruby or Python, or something like that.

But now I think with these new tools, they feel comfortable with PHP, and they don’t feel bad for using it. I never think anymore, personally, like, Oh, I should go try Rails, because everything that I need is pretty much available in PHP, and Laravel, feature for feature-wise, is really getting to the point of being on par with Rails. Especially with Laravel version 4. I think it’s a really exciting time for PHP, and tools like Composer, and this emphasis on growing this package ecosystem for PHP is really nice. Because, when I do look at Ruby and Rails, one thing that I do envy is the sheer amount of cool gems and stuff they have. As Composer grows in popularity, and more and more people build these packages, hopefully we can catch up to that. That is one area they’ve been whooping up on PHP. But I think we’re heading in the right direction for sure.

E: I’m curious, you say when you were first launching it was really important to build community and have documentation and screencasts and things like that. I’m wondering, if media attention is something that you’re interested in, or it something that just kind of drops out of all the other activities you do? Or is it something you completely ignore?

O: I try to do, still market the framework in a sense. I try to tell people I view the framework as a product. I don’t look at it as just a side project anymore. I want Laravel to be — I want it to have a certain personality and presentation, and so I spend a lot of time thinking about that, thinking about how the docs look, how they read, how the framework feels, in terms of its API — just very, almost obsessive in terms of how the framework comes across, and just the way that it presents itself — I want it to present itself as kind of a light, accessible tool, that’s out of your way, that’s easy to use, and helps you build a lot of great stuff really rapidly.

I don’t know if that made sense!

E: It does, and it meshes with what you said earlier about being friendly to new users, and generally having an inviting atmosphere.

O: Definitely. And a lot of this, I mean, everyone’s inspired by what Apple has done, in the sense that they’ve made technology very accessible and usable, things like the iPhone. And I kind of think of Laravel as a product, obviously nowhere near the scale that Apple operates on, but I wanted to have that same kind of accessibility.

E: I know you get asked this question a lot, but I have to ask it on this podcast, because some people might not know — can you briefly explain where the name “Laravel” comes from and how you chose it, or made it up?

O: The name actually has no meaning. I was struggling to come up with a name, and I just started thinking of words that sounded cool in my head. It does rhyme with a word that has meaning. In the kids’ books, The Chronicles of Narnia, there’s a place called Cair Paravel, which is where all the kings and queens live, and so it kind of rhymed with that, Laravel and Paravel, so it just kind of stuck. So, it has no meaning, it just kind of stuck in my head. I was having a hard time coming up with names, so I just kind of gave up coming up with meaningful names!

E: I was just struck by how good it is, on all sorts of levels — naming is something people talk about a lot on the web, and finding something with seven letters, that was, I’m sure, available, and is spellable, is really important, and that name captures all of those things.

If you don’t mind, I’d like to move on, to asking you some questions about your experience with Leanpub and the Lean Publishing process. Can you tell me how you found out about us, and why you chose us for your publishing platform?

O: Yeah. Actually I found out about Leanpub from Dayle Rees, who’s like, maybe the all-time highest grossing author on Leanpub. He also wrote a Laravel book, kind of a more introductory book, and he really enjoyed Leanpub, and recommended that I try it out.

E: It’s been an extraordinary thing for us — I’m just checking our bestsellers right now, our all-time earnings, and Dayle’s “Code Bright” is on top, and yours is number three, and Dayle’s first book is number seven. And then, Jeffrey Way’s book, Laravel Testing Decoded, is the tenth, so of our top ten, three of them are Laravel books.

O: Yeah, it’s wild. It’s really crazy. But yeah, he’s the one that turned me on to Leanpub as a platform.

E: And how long has Dayle been involved with the project?

O: Gosh, let’s see. It’s probably been a year and a half now, I’d say. He’s been around for quite a while. But, with the latest version of Laravel, he really came on board and started helping me manage the pull requests, because we get quite a few every day, and has been really helpful on IRC, answering questions and stuff.

E: I have just a general question. How would you describe your experience using Leanpub to write and publish this book?

O: Leanpub is really awesome, because I kind of feel like I don’t notice Leanpub, and I mean that in a good way. I just write my Markdown, and go to Leanpub and hit publish, and you know, you all handle everything. I never have any Leanpub headaches. It’s just really nice because Markdown is such an easy way to write, and because all the Laravel documentation is already in Markdown, I’m kind of used to writing Markdown. It’s just such a simple little markup for writing. And just the way that Leanpub lets you manage everything very easily, it’s just so straightforward, and I could get started really fast. Even now, with multiple translations of the book, it’s very easy for me to set up a new book, and get a coauthor set up, and divide out the royalties, you know, it’s just really straightforward.

E: Thanks! Unless I’m mistaken, you didn’t publish your book in progress, you published it when it was finished.

O: Yeah. I guess it was like a discipline thing for me, just so I would finish it first, and not put it out, and then get distracted with other things and never come back to it. So I decided to finish the whole book, and I think I do have a few chapters in my head now, that I’ve gotten some community feedback on the book. Kind of what people are wanting, or thought was missing, that I probably will go back and add a few chapters now. But essentially the book was published with all the material that I had originally conceived.

E: That relates to my next question — I guess you’ve answered it — but, is engaging with people directly important to you, and is there more we could do to help you do that? Or is that something you’re happy to manage on your own?

O: Right now, that’s been pretty easy enough to manage on my own, since I communicate with the community a lot through Twitter. I marketed the book mainly through Twitter. So people have been getting back to me on Twitter with feedback, and ideas for what they’d like to see, or what they’d like to see expanded on. It’s always hard to tell, you know, when you’ve written the framework, you have so many blind spots to what might be hard for other people to understand. It might make reasonable sense to you, but it could be clear as mud to everyone else. And so, it’s nice to get the feedback, because it’s very hard for me to ascertain what needs to be worked on.

E: OK, so you don’t find yourself wishing there was something more systematic, say, like what O’Reilly has, a kind of reporting system which is line-by-line, people submit errata and suggestions. Buy you’re happy, just using Twitter to interact with people that way, and I suppose keep your own list of things you’d like to change?

O: Hmm. It would be — you’re kind of putting ideas in my head now! — it would be cool to have almost a GitHub-style interface, where people who have bought the book can submit pull requests to fix stuff, that would be nice. But I’m sure that would be a lot of work!

E: Well, right now we have a very simple solution, which is Disqus comments that you can turn on. So there’s no, sort of, finishing them off when they’ve been completed, but it is a simple way to sort of focus things in one place.

O: That’s pretty cool. But mainly I’ve been managing it through Twitter, and people have been emailing me stuff to fix, and I just go ahead and fix it in the Markdown, hit publish, and you know, the update just goes out to everybody nice and smooth, so -

E: Do you watch Google Analytics for your book pages, or anything like that?

O: No, I don’t. I’m really bad about analytics! I don’t do a lot of analytics on Laravel’s downloads, or on the book, or anything, but that would be interesting to know — you know, who’s my primary buyers on the book.

E: Yeah, it’s a very interesting thing — given that your book is our third-biggest seller of all time, it might be a comment perhaps about, at least in the early months after publishing a book, what’s most important to focus on. Which is, getting out there to people, and maybe not watching obsessively one’s analytics every day.

O: Yeah, definitely. As a creator of a framework, I found it was easier for me to publish the book, because I had a fairly large Twitter following already. But yeah, it would be interesting to know, coming into Leanpub as a new author, that may not be well known, although you could have great things to say in your book, what the best ways to get the word out on the book would be. I’d be interested to learn more about that.

E: Can you tell me a little bit about what the book is about? I know it’s about 63 pages long, and I can see that it’s meant to be directed at people who are past the beginner stage.

O: Yeah, so, Dayle’s book was kind of the introductory, and I wanted to write a, “Here’s where you go next”, after you’ve read Dayle’s book, and got the basic grasp of the concepts of the framework, and now you’re ready to go deeper, and see what else the framework has to offer, in terms of building a more complex application. Something like Snappy, like we do at UserScape, where you have lots of classes, lots of stuff going on — how do you structure that, in PHP? PHP’s not really well-known for being, like, this well-structured and thought-out area of development. So we’re trying to change that, and give people some ideas for how to structure a complex PHP application, and particularly a Laravel application. But there’s lots of good info, I think, even if you’re not using the framework. We have five chapters, one on each letter in the SOLID acronym, which is a pattern of good software development -

E: Uncle Bob, right?

O: Yeah. From Uncle Bob. And then we have a few other chapters that are Laravel-specific — where to put your files, and how to organize everything.

E: I see that the book is very well-produced, including the cover. I’m wondering, did you go through a process whereby you had technical reviewers before you launched it, and did you hire say, editors, or something like that?

O: I didn’t hire anyone. I did have more prominent, or key members of the community review the book. I sent it to Jeffrey Way, who wrote the Laravel testing book, and of course I sent it to Dayle, who wrote the introductory book. And a few other people I communicate with a lot — I let them read it over, and give their feedback, and correct typos and stuff like that, or tell me I need to expand in certain areas. So that was kind of nice, to have a few members of the community that I could rely on there. I kept the book straight and to the point, which is why it’s fairly short, really. But I think the quality of the information is really good, even if the quantity is pretty short. And at the same time, I personally don’t like to read 200-, 300-page books, so I wanted to keep it fairly readable, where a person could buy the book, and actually finish the whole book, word for word, fairly easily.

E: Did you consider at any point going down the traditional publishing route?

O: Yeah, I did, actually. I got a few offers from other publishing companies before I settled on Leanpub. It just doesn’t make sense anymore, for me. With the framework being established, and with having a fairly large community, I decided it would be silly for me not to use Leanpub, because I would just be throwing away tons of money to write for a traditional publishing company. It just didn’t make any sense at all. It was harder to write, the platform was not as good — I couldn’t just write in Markdown, which was a killer for me. That was like a deal-breaker: I have to be able to write this in a simple Markdown syntax, because I can’t do some legacy Word crap, and just take forever — it would just suck.

Leanpub was an obvious choice, even though I had offers from, I think, Manning was my main offering, so…

E: Was timing an issue at all in that as well? With traditional publishing, well, I know that Manning has an early access program, but the traditional publishing process really does, can take quite a long time.

O: Yeah, I forgot about that. I was nervous about that, you know, like committing to the publisher, and being pressured to finish the book by a certain day. You know, I have a family, and I’m working on Laravel, and I have a day job — being able to write at my own pace was another big factor in that decision. There was almost no cons to using Leanpub, you know what I mean? It was more money, it was more time, it was no one telling me what to do, or what to write one, it was an awesome platform, you know, with Markdown, so it was like a no-brainer. There was really no question.

E: That’s really great to hear. That’s interesting, that one of the positive aspects, was the freedom to take more time than you needed to, because when we speak with authors, often they’re, especially when they’re people who are successful in one way or another, like you are, they’re often, they feel hamstrung by the amount of time that it takes with a traditional publisher. They feel that it’s a delay.

O: Yeah, for sure. I could just tell it was going to suck. I didn’t want to commit to a timetable because stuff comes up, I might have to work — something comes up in the framework, and I might have to spend like days on that, you know, don’t get to work on the book, and now I’m behind…. It was just going to be too much stress and too much pressure, I thought.

E: Have you been updating the book when you receive, say, typo suggestions and things like that?

O: Yeah, I have been. I’ve released a few updates. I’ve got a couple of emails of typos I need to go ahead and push out here soon. Yeah, I’ve made several updates to the book, to correct things, and fix any wording mistakes or example mistakes. It’s been nice, people have been nice to kind of report them, and stay on top of that.

E: Have you used the feature that allows you to email readers when you update the book? Or has it just been silent updates?

O: I think I’ve emailed on every update, and mentioned, Hey, this just fixes a few typos. It’s also a way to say Thanks for buying the book, and if there’s anything you see that’s missing, let me know. I use it was a way to communicate, at the same time, and not just to talk about the update. So I always remind people — if there’s anything you want to expand on, tell me, because that’s how I’m basing what any further chapters will be. So that’s been nice.

E: I see that you set your minimum price at $29.99 and your suggested price at $34.99. Was there any reasoning behind that?

O: Yeah. I priced it the same as Dayle’s book, and I also priced it a little higher, because the framework is free, obviously, it’s open source. And I felt like with the framework, I had made relatively little money off the framework, I mean, before I wrote for Leanpub, I may have made, I don’t know, let’s say one or two thousand dollars. I mean, not tens of thousands of dollars. And so, I kind of looked at the book as a half-donation, half-product so to speak. So when you look at the book, it is priced a little higher, but I think people have been really receptive to the idea of, Hey, I’m making money building apps for clients on this framework, and this is kind of a way to give back, and get something at the same time. It’s kind of a donation that has a reward to it. People have been really understanding of that, I think, even though it’s a short book, you know it is priced a little higher, but it is kind of a nice gesture toward the framework, and it will help us do some things down the road, actually, that we have planned, that might cost a little money.

E: Excellent. And have you used any of our features, like say the coupon feature, or anything like that? Or one-day discounts?

O: Yeah. I’ve used the coupon dozens of times. When I did release the book, I let people know there if there was a financial hardship, to email me and I’d give them a copy of the book, so, we’ve had various people, college students, things like that, that are kind of strapped for cash, but they want to learn about the framework. So we’ve given copies of the book to them. Also, at Laracon EU, we actually gave away 180 use coupons, so everyone at the conference got a free copy of the book.

E: Oh, fantastic!

O: Yeah, so coupons have come in very handy, I’ve used them quite a bit.

E: Do you have any specific feature requests? Something that you’d love to see, that occurred to you, when you were using Leanpub?

O: The only one that’s come up recently was bulk-creating a lot of different coupons. So like, with Laracon I needed to make 180 coupons, so what I did was make one coupon with 180 uses, but, if I could somehow create like 100 coupons at once, and just get a list of all the new ones, that would be great.

E: I see.

O: It wasn’t too hard for us to work around, I think it worked just fine. I don’t think anyone tweeted the coupon code to the outside world!

E: On that note, is that something you have a strong opinion about? Leanpub books are DRM-free, and people can actually, with two clicks, get a refund, within 45 days of buying. Did you think about those things at all, or are they — ?

O: No, I didn’t really. If people don’t like the book, I want them to have the refund, and if someone gets a refund because they just want their money back, I felt like that would be the minority. It’s not the way the community operates, in a sense. It’s kind of a very, I don’t know — like I said it’s a friendly community, I didn’t expect that to be a huge problem, people just buying the book and then say, I’m getting a refund and keeping the book. I didn’t think that’s the way it would be, so I didn’t worry about it.

E: And piracy isn’t a preoccupation of yours?

O: Not that I know of, we haven’t had any problems with it. No, I’m not really too concerned about it. I think people respect the framework enough, and what it’s done for them and their business. Really, thirty bucks is a drop in the bucket, I think, compared to what they’re getting out of it on a day-to-day basis, at least the people I’ve talked to.

E: Well, that’s great. A lot of the things you’re saying, are a lot of the reasons we built Leanpub, so it’s great to get the validation, knowing that it’s working.

O: Yeah, it’s a great platform, I totally love it, and if I ever write any more books, it will definitely be using Leanpub.

E: I guess that was going to be my second-last question: do you have any plans to write another book? You mentioned that you’ve got future chapters, probably to add to this one.

O: Yeah, I think I’ll stick with this book, for a while, and add some further chapters. I don’t want to — when I released this book I was kind of wary of, like, pimping the framework, so to speak — I don’t want people to think I’m trying to profiteer on the framework, so, I don’t have any ideas for releasing a second book, or really want to right now. I’m just going to continue to expand the book I have. And everyone gets updates for free, which is nice, so, yeah, I’ll stick with this one for a little while, and just expand on it.

E: Great. Well, I guess our time might be about up. Is there anything you’d like to add, or any comment you’d like to make?

O: No, it’s been great. It’s been great using Leanpub, I love it, and, you know, I think it’s really changed tech publishing in a way, in that, all these authors have access to a great publishing platform, and they get rewarded fairly for their work, and it’s just, I think it’s awesome — it’s awesome for the whole tech community, and I really commend you guys on the platform, it’s a really great platform.

E: Thank you very much, for your positive comments, and for being on the Lean Publishing podcast, and for being a Leanpub author!

O: Yeah, thanks for having me, it’s been great.


Originally published at leanpub.com.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.