In this Episode
In this interview, Leanpub co-founder Len Epp talks with Taylor about changes to Laravel and developments in the Laravel community since their original interview nearly five years ago, in September 2013. They also discuss Taylor's unique and successful approach to using Patreon, and the importance of working on the hard things first in new software projects, amongst other things, including Star Trek.
This interview was recorded on August 24, 2018.
This interview has been edited for conciseness and clarity.
Len: Hi, I'm Len Epp from Leanpub, and in this Leanpub Frontmatter Podcast, I'll be interviewing Taylor Otwell.
Based in Little Rock, Arkansas, Taylor is a web developer who is best known as the founder and maintainer of the Laravel PHP framework.
With the upcoming Laracon EU conference happening soon in Amsterdam, we thought it would be a good idea to catch up with Taylor and see how the last half decade has treated him and Laravel, which has grown into a very popular framework with a thriving community around it, and around the world.
So, thank you Taylor for being on the Frontmatter Podcast.
Taylor: Thanks for having me back.
Len: I always like to start these interviews by asking people for their origin story. But we already covered that in our original interview in 2013, and I'll make sure to link to that in the transcript for this episode.
So, I was wondering if, instead of giving us your origin story, you could give us some of the highlights of what you've been up to professionally since 2013?
Taylor: Yes. In 2013, around the time I launched my first book, that was the first time I ever made any money at all on, based on my work on Laravel.
Since then, there's been a series of things, both open source things and commercial things, that I've done.
Some of the bigger highlights are: in 2014, I launched Laravel Forge, which was my first software-as-a-service product, based around provisioning PHP servers, and specifically tailored for Laravel applications.
And then, about six months later, January 1st, 2015 was my first day working full time on Laravel. I left UserScape, which was the company I was at for a few years, and then worked full time on Laravel.
And then in February of 2015, just a few months later - I launched my second software as a service product, which was Envoyer.io, which was a deployment product.
And then, I don't think I launched another commercial product for a few more years. But Laravel continued to grow, especially as I was working on it full time and had a lot more time to devote to maintaining it and adding features and stuff like that.
I think in 2015, I launched Laravel Spark - it may have been 2015 or 2016 - which was my third commercial Laravel product, which helps people build their own SaaS businesses - sort of a starting point template built on top of Laravel, to build services like Forge or Envoyer, that charge people monthly or yearly. I just took all the lessons I learned building Forge and Envoyer and tried to build it into a good starting point for myself and for other people.
And then I launched quite a few Laravel features - Laravel Horizon, which is our queue monitoring package - a lot of features into the core of the framework.
And then, I think in about 2017, I hired the first employee for Laravel. That was a big milestone. Up until that point, it was just me doing basically everything, from developing to customer support, and so on. I hired Mohamed Said, who's based in Egypt. He had contributed to Laravel before I hired him, a few times. So I already knew that he was pretty talented, and I brought him on board and he helps with everything, really - Forge, Envoyer, and the open source side of the business.
Len: I've got some questions about all of those things, I think, but I'd like to ask, when did you decide to go full time? I think when I originally interviewed you, Laravel was still a side project.
Taylor: I was pretty cautious. Laravel Forge, I launched it around May of 2014, and it grew pretty quickly actually. I surpassed my salary at UserScape pretty quickly. But then I also had to factor in additional costs of going out on my own; I get health insurance expenses and other things like that. It occurred to me that it was big enough to go full time on Laravel. So it helped encourage me in that direction.
And then there was actually a little transition period where I did work part-time for UserScape at the end of 2014, where every other week, I was working at UserScape, and then every other week I was working on Laravel. That was sort of a transition. And then finally in January, I went full time. But it was scary at first. I just let it to grow enough, to where it felt like it was a pretty safe decision.
Len: You mentioned already, another big decision you made was to hire your first employee, which is another commitment of your own revenue. But also, you have responsibilities towards the employee as well. In preparation for this interview, I watched an interview with you where you - or I think it might have been a blog post that you wrote on Medium, where you talk about how you waited a little bit too long. I was wondering if we could talk a little bit about that?
Taylor: Yeah, I think I did. I think for a lot of open source developers, the open source project is their baby, so to speak, and they nurture it and watch over it with this careful eye, and don't want, or are hesitant to let other people jump in. I think that's kind of how I was. For those first few years, I was a little too protective over everything, and even though I needed extra help, because it was just becoming overwhelming to manage.
I mean the open source side alone, it really can be a full time job for someone. But then adding on top of that three commercial products to support and maintain, I really needed to bring another employee on - and probably need to bring a second employee on here soon.
But I think it's common, and other developers I've talked to that start businesses, they're scared to hire someone. They don't want to mess up their business or hire the wrong person or whatever. For me it worked out pretty well I think, and I wish I would've done it sooner.
Len: One of the things you've had to handle, and I suppose enjoy handling over the last few years, has been the incredible growth of the popularity of Laravel. There's quite a large ecosystem now, including the SaaS products that you've developed, the new versions that have come out. And there's also the Laracons, including the online Laracon and the US Laracon and the EU Laracon, and the Australian Laracon.
What was that like for you, to now be the person at the center of all this growing attention? I imagine you started traveling more, you started giving keynote presentations to growing audiences. Did you talk to other people who've had that kind of experience about how they handled it?
Taylor: No, I really didn't talk to anyone. It was kind of a surreal experience at first, and I didn't know what to expect. At the first Laracon, which was in 2012, we had about 90 people. And then it jumped to a couple of hundred people. And then in 2015 and '16 and '17, it was right around 500. And then this year was up to 850. So it's really ballooned up.
It's a pretty unique experience for me, because where I live here, in Little Rock, Arkansas, I'm not any center of attention at all, and actually don't even know many other developers in person. So I go from a very kind of normal, quiet life, to a big conference where people want to shake your hand or get an autograph or talk to you - and they're so excited. It is a pretty night and day experience from my daily routine. But it's always fun to meet everyone, and I like hearing their stories of how Laravel helped them get a better job, or helped them support their family and stuff like that. That's always sort of the best part for me.
Len: I wanted to ask you something about strategy and the responsibilities that you have, being at the center of this web. For example, do you have a kind of succession plan for what will happen if - let's say, to put it in the nicest way, you decide to do something else?
Taylor: Yes, there is sort of a succession plan, and there's actually several people that have admin access over the Laravel open source projects, and also know how to manage the commercial projects as well, or how to sort of take over the reins for them, if there was any kind of sudden tragedy. So that's all sort of accounted for and planned for.
I hope it would be a group effort between some of the key Laravel figures over the years, like Jeffrey Way and Matt Stauffer and Adam Wathan. I think all sort of share admin access to the Laravel GitHub organization. That was something kind of important over the last couple of years, to get solidified and put in place. Because it would sort of be mayhem if something like that happened. But yeah, just making sure that's all taken care of - especially when large companies depend on the framework, and something will have to be done with commercial businesses and stuff like that.
Len: For those who might not know really anything about open source or running a framework, or being at the center of this - can you just describe a little bit about how it works?
Taylor: So, Laravel specifically is a starting point for building websites. Because a lot of web applications have the very same features, like logging in and storing things in a database, like customer information, and doing all those things every time you build a new web application from scratch, takes a lot of time, Laravel jump starts that process and gives you a lot of those features out of the box.
And now, open source means anyone can contribute to the source code of Laravel - the code that makes it operate. People do that via GitHub. Anyone can contribute on github.com by sending over the code that they want to change, or the modifications they want to make. And then I either can approve or reject it, or ask for maybe some modifications.
It's a pretty interesting concept. People contribute from all over the world. There's thousands of contributors at this point. You meet a lot of people and interact with a lot of people, and interact with a lot of businesses.
The tough part for the open source maintainer is always deciding what direction the project should take, because everyone has their idea of what should be inside of Laravel and what should not be inside of Laravel, and things like that. So I sort of serve as curator, so to speak, at this point.
I still contribute features of my own, but a lot of my time is actually spent curating which pull request, or which modifications I want to accept, and which ones I want to reject. That's actually a pretty tough job, because people spend time thinking about these modifications, or making them. And then they send them over and sometimes they get rejected. That's honestly one of the worst parts of being an open source maintainer. But I think it's a pretty positive experience usually for most people.
Len: It's just such a fascinating model - I mean, for people who are into it, it's all very familiar, but for those who aren't familiar with it, the idea of a project that has one person at the center of it, who's getting all these suggestions - not just suggestions, but actual work that people have done, and then has to be the gatekeeper, to decide what to let in and what to keep out - is just such a fascinating model.
You've spoken before about trying to handle that process by introducing a primary step, where people can propose something. But that comes with its own problems, because it's not just a proposal for a feature - the feature or code has to be written. And then that introduces another dimension to the decision that you have to make, partly because you might be the one who has to fix it, if the person who made the contribution goes away. I was wondering if you could a little bit about how that worked out?
Taylor: Yeah, we do have a Laravel idea board, where people can contribute ideas. And like you said, it sounds good in theory, but it can still be difficult, because I'm always weighing two things. An idea can look really good on paper, but it depends on how much overhead, how much code that comes with the idea.
So, say someone proposes an idea: a lot of times my response will be, "It depends on what the code looks like. How much code there is. And how many modifications we have to make to the framework."
Because every modification we make comes with this risk of breaking something else, or causing some new, unexpected behavior for people that relied on the old behavior. And so a lot of times it's - people need to find a good balance of their feature - does it bring value with very minimal overhead. The more value they can bring with the least amount of overhead, those are the most valuable pull requests you can make.
When the pendulum starts to swing to a low value idea that doesn't really improve many people's experience with the framework, but also comes with a lot of extra code to maintain - those are sort of the pull requests that I would probably reject. So it's always weighing those two things on a scale, and seeing how it comes out.
Len: And what do you do when people get mad, when you reject them?
Taylor: Yeah, I don't know? A lot of times, to be honest, once I reject them, I'm onto the next thing, and that's sort of the end of the interaction. So a lot of times I don't [13:46 audio distorted] - sometimes I probably miss mean messages that people may have left me, because I simply just don't go back to the thread and read them. But probably for the best, really, I don't.
Len: That sounds like the right thing. Actually, you've written a blog post where you talk about how your day goes. I really liked the description of how you start your day by clearing out your inbox, of both emails and pull requests. I was wondering if you could talk a little bit about that routine?
Taylor: Usually what I do first is just hop on our help desk and answer any of the customer support emails that came in overnight, first. Usually, Mohamed has made a dent in those, because he's six hours ahead of me, so he's already gotten up and answered a few of those emails. Some of them will be left for me either if he can't handle them, or they require something only I have access to - then I'll take care of those.
Then I'll jump over to GitHub, and I usually try to keep the total open pull requests for Laravel around 10 to 15 pull requests. I don't like it to go much over that, because it can start to pile up really quickly. So usually, that means I need to manage about five to ten pull requests a day. Just to sort of maintain that number. Otherwise it's going to start growing out of control.
So once I sort of get that taken care of and move past both of those things, then I can hack on whatever code I'm working on that day. It could be Laravel Forge, or some totally new idea - fixing a bug or whatever else.
Len: It's interesting, when I was reading about that, it reminded me of - back, in a former life, I would grade first year English papers in university. And it was always - whenever you opened a new one, you had no idea what to expect, because anybody could be at any level - and also at any level of commitment, I suppose, to doing well. Do you have that kind of experience whenever you open up a new pull request? Is it readily identifiable that, "Oh, this is someone who's totally new, and this is their first attempt at things?"
Taylor: Yeah, sometimes. I do have a pretty good idea. Sometimes it's people I've seen before, so I sort of know what to expect. Actually most of the time, it's people I haven't seen, and it's usually new people. So every one is kind of different. And also, with an open source framework, there's a lot of documentation, there's a lot of sort of internal [?] code documenting.
Many of the contributors are not native English speakers. So, that's usually one thing I do have to kind of polish up - I'll just kind of go in, and I don't actually reject their pool request, I can just pull it down onto my computer and massage it a little bit and clean up some of the syntax and grammar, and then push it back up and merge it. So they still get sort of a credit, so to speak, for contributing that code, but I'm able to just polish it up a little bit before it goes into the framework.
That's what I do usually, if they're close, but they're not quite perfect, rather than just rejecting it and making them try again. I'll just try to finish it out for them. Usually it only takes a few minutes, and then get it merged in.
Len: One of the really interesting things about this structure and process is that Laravel is constantly changing. I believe that you are on a six month schedule for releases of new versions. I think if there was someone from kind of the old school, maybe someone who isn't all that familiar with how software works, they might be hearing this - like lets say a CEO - and thinking, "Oh my God, I would never let that into my company, because it's changing so quickly." This is a world where the VA in the United States is still using calendaring software from the 1980s.
I know that Laravel moved at a certain point to long term support, which actually has a technical meaning. I was wondering if you could talk a little bit about how the timing of that decision worked for you, and what long term support means in this context?
Taylor: That was a growing demand we heard from people. Was that - usually it's their boss, it's not them. But their boss is not comfortable with open source software as an entire concept, or they're not comfortable with something moving that fast, like you said. So they'll ask for something called a "long term support guarantee," which means that - typically we would only fix bugs in a Laravel release for the six months that that release is active, and then we would move on to the next release and everyone is sort of expected to upgrade. But with a long term support release, which we do every two years, instead of every six months, we actually fix bugs on that release for two years. And we fix security related bugs for three years.
So you're actually "safe" using that code for three years. And then you would have to upgrade to the next version, or just sort of accept the responsibility of maintaining it yourself from that point forward.
I had firsthand experience with that, because I worked in a large organization at my first programming job. Not only was long term support something they would've been interested in, but there was skepticism of open source really in general. So it can be an uphill battle in some environments. We had to add that a few years ago to help developers in those situations make a better pitch to their bosses on why they should go with Laravel, or why they should be comfortable using Laravel.
Len: What would you say is the most common product that Laravel is used to make?
Taylor: I've seen such a wide variety of things. I've heard of Laravel being used in airliners. I've heard of everything from that to Laravel being used to build simple invoice software that freelancers use to bill their clients after they build a website for them - all the way to Bitcoin mining applications. So the variety is really vast, and the types of companies using it are really varied.
Some of the larger companies that I've heard of using Laravel, or I've seen job postings that related to Laravel, are companies like Starbucks, Apple, NBC, the New York Times. Those are the household names that I've seen with job postings asking for Laravel experience.
But I hear so many crazy stories at conferences. Probably the airliner software, which was some sort of maintenance reporting software that the pilots could use from the plane, if they had an issue. And then the Bitcoin mining software is probably some of the more interesting things I've heard of.
Len: That's really fascinating to hear the airliner story. Because as I'm sure you know, it's so highly regulated and everything is examined in the minutest of detail. So that's just amazing to hear that Laravel's at the point where it's being used for those kinds of processes.
Taylor: Yeah. And not to worry people, I don't think it's a flight-critical part of the airplane. It's just sort of a bug reporting system that's built in a web way, I guess.
Len: Speaking of products built using Laravel, you've got your own products built using Laravel. You mentioned you use a SaaS model to fund your work. I'd to ask you specifically about Nova, which you just announced very recently. But, how do you decide what to work on next?
Taylor: A lot of stuff is borne out of my own needs. Going back to 2014, when I built Forge, I was constantly having to build web servers from scratch - set up all the software on them, configure them and things like that. And I really wanted an automated way to do that, so I could quickly spin them up, mainly for the purpose of testing Laravel. I needed a quick web server to test Laravel on in production. I was doing that a lot, it felt like, and so I built Forge to automate that whole process.
Then I needed a way to deploy updates to the website, without having any downtime. And so I built Envoyer as a solution to that problem. And then, similar things with Spark. And then with Nova, I have these several businesses, but I had no good administration panel for them to go in and dig into, if I needed to look at a customer's account, or update some of their information for them, or refund a charge for them, or things like that.
I was doing those things all very manually, and it required me to log into several different places, or even run a manual database query and things like that. I really needed a better way to manage all that. That's sort of what Laravel Nova was birthed out of, was that need. So a lot of it's just scratching my own itch, so to speak.
sometimes I don't really have a readily identifiable problem that's really bothering me at the time. So, I don't have a new product idea for a little while. But it seems like one eventually turns up, just as I go about my daily developer life. I just sort of latch onto that.
Len: And how do you market your products?
Taylor: Right now, almost exclusively through Twitter and the Laravel website itself. Sometimes I write on my Medium blog. But I've done very little actual advertising. I've run a few ads on the PHP subreddit, on reddit.com. And I think I may have done some promoted tweets sometime [23:16 ?] - a lot of advertisement, I think mainly because my Twitter following has grown over the years and it's just quicker and easier to send out a tweet, or I have a mailing list I could send out an email to. So, it's really pretty simple as far as marketing goes.
That's the value of having an audience from all the work I did on open source - it gave me this audience that then was interested in the things I was building. Whereas, if I was trying to build sort of application from scratch and didn't really have a following, I think it would be much more challenging to launch a successful business that way.
I'm always pretty impressed when someone can build a new business and is not "tech famous" in any way, but is able to build a successful business out of it. Because I think it would be a lot more challenging.
Len: Speaking of the business side of things, there is a recent post I saw on Hacker News, by Paul Dix, called, It’s Time for the Open Source Community to Get Real - I don't know if you saw it, but there's a quote from it that probably captures the essence of it, where he says, "In short, it takes continued investment, and that must be subsidized somehow," when he's talking about open source frameworks.
Now, I confess, I'm not deep in the open source community, and I'm not familiar with the strength of the debates. But I suspect you are. I was wondering if you could talk a little bit about your position on this issue?
Taylor: So he's talking about open source contributors and maintainers being compensated in some way?
Taylor: Yeah, it's a big problem in open source, because a lot of people build these libraries, and people are pretty demanding over their time, and want the bugs fixed. And there's usually very little, if any, compensation, which then leads to other personal problems for the developer, burnout or things like that.
There's been a few efforts, and I've seen a few different approaches for how maintainers try to build some sort of compensation out of their product. Sometimes people just ask for donations. But I feel like a lot of times, very few people donate and if they do, it may only be a few dollars. It's not enough to make a sizeable dent in their living expenses.
A growing trend is releasing information products, like books or video courses - which was the first thing I did, was release a book on Leanpub. I've seen several people be fairly successful with that. As long as you have an interesting topic and an audience, that's a good way to go.
I feel like building an application is pretty rare. Because a lot of open source libraries are just not really conducive to turning into a full sized business like Laravel Forge.
I think there's still room for a lot of improvement in the whole area. Donations a lot of times just doesn't pan out. But not everyone can start a whole business or has the time. I think there's room for innovation around that, and hopefully it improves.
Len: Speaking of innovation around that - you actually have a model of your own on Patreon that people can use to support Laravel. I was wondering if you could talk a little bit about that?
Taylor: My approach to Patreon was - I was really interested in trying to turn Patreon into a sponsorship model, where I had several expensive tiers, much more expensive than you would see on some Patreons. I had a $750 a month tier, which gets you your own page on the laravel.com website talking about your development agency. All of these tiers are geared towards companies that build Laravel websites for other people. So, consultancies or development agencies. And then all the way up to a $2,500 a month tier - to have the top spot on that page.
Because I felt like - I sort of knew that if there was low dollar amounts on the tiers, it just would never really be a meaningful amount of money to run a Patreon. I've given that advice to a few people - try to get five or six sponsors at a higher value, rather than trying to just setting like a $1 tier on their Patreon, and getting maybe 150 people to sign up for that. And making $150. Try to get even just three or four sponsors at $500 a month, and you're making a bigger dent in what you need to work on it, part time or full time.
That's the approach I took for it. Which has been really nice for both parties, actually. Because the sponsors, I give them other benefits. Like each month, they can schedule a 30 minute or hour long video call with me, with their development team. We can chat about Laravel. It's good for me, because I get to talk to their developers about Laravel. I ask them what problems they're having. It helps me improve the framework and get firsthand feedback from a development team that's building lots of real world projects.
It's good for them, because as they're pitching their services to clients, it's helpful for them to say, "We have direct access to the maintainer of the framework. We're in a Slack room with Taylor Otwell. We can call him on Skype." That lends them credibility and makes customers more comfortable with their services. They know they have good access into the maintainer in the framework. So, it's worked out really well, and been helpful for both sides.
Len: You mentioned burnout, and that reminded me of something you talked about in an interview once, about doing the hardest stuff first when you start a new project. I was wondering if you could talk a little bit about that?
Taylor: Whenever I'm starting a new project, I always have in my head a few areas that I know are just going to be really gnarly, and hard to figure out. Rather than sort of kick those down the road and work on easy stuff first for - let's say, three or four weeks of knocking out easy stuff - I would rather just know upfront if there's going to be a substantial roadblock to the project. So I'll just try to tackle those hardest things.
I would rather just fail early in the first few days, rather than work on easy stuff for a month, and then get a month into this project and realize, "Oh, there's a fundamental flaw in this whole idea, and now I've lost a month of time," basically because I put it off.
So, I always like to dive right into the hardest stuff for that reason. I think it saves time in the long run really.
Len: Speaking of marketing, my second last question to you is - what's your next product? I know Nova's totally new, but I think you've written something about a product called Horizon?
Taylor: Yes, we launched Horizon. So that's out. The next product for me - I would like to improve Horizon, improve Laravel Forge. We have a visual refresh of Envoyer, that's already been designed. So we need to launch that.
But you know what? I'm kind of reaching a point where I think I've got enough irons in the fire, so to speak. I think it's going to be hard to keep expanding and launching these new products without more hiring, which we talked about.
But right now, I'm in that stage where I just launched a product. So I'm just waiting to see, what's that next itch that needs to be scratched? Or, what's the next problem I'm having? It hasn't turned up yet. So right now, the plan is to just sort of improve what's out there. But if something turns up, may have to jump on it.
Len: I often like to end my interviews by asking a selfish question. And in this case - I can tell that you're a Star Trek fan from the examples you use in demos, and from the portrait of Spock and Kirk behind you. I wanted to ask you what you thought of, Discovery, the new CBS series?
Taylor: I've only watched the first episode, because I was in the middle of watching Star Trek: Enterprise, and I'm almost finished with Enterprise. I only have five more episodes left, and I didn't want to jump into a new series before I finished Enterprise. So I've actually stayed very spoiler-free on Discovery, and I don't have any idea what happens. I've only seen that first episode.
So I'm actually really looking forward to watching it. I saw today that the Blu-ray's coming out - I think it was October, November. I don't know if I'll make it till then. I think I'll finish Enterprise before then, so I may have to watch it on CBS All Access. But I'm really looking forward to it, and I hope I can go to a Star Trek convention in Las Vegas sometime. But it always seems to sort of conflict with Laracon, or vacation, or Laracon EU. But maybe next year?
Len: I guess then, I'll ask you one more question, since you haven't seen Discovery. So: if you had to guess what they were going to do with their new Picard series, what would your guess be?
Taylor: Oh gosh, there's so many cool ideas. I [32:57 ? audio distorted] maybe on earth, either a senior position with Starfleet, or maybe even retired. And either he'll be in some mentorship role or some quests will come up from the past that he embarks on.
A cool tie-in I would like to see - I don't know if they'll do it, but somehow tie in his Inner Light episode with his new series. Because I feel like that would have been such like a huge moment in his life, to live this whole other life, and have children and have a wife - and then in a blink of an eye be back to his old life - which I feel like would really change somebody, and be a pretty big deal. I think it would be cool if they explored that in some way. I don't know how they'd do it. But those are kind of my realistic expectations and what my optimistic hopes would be.
Len: Thanks for that. My two hopes or expectations are, one, that he'll be a retired Admiral, and he'll have heard about some lost civilization at the edges of the galaxy, and he'll be on a long-term voyage.
Taylor: Yeah, I can see that.
Len: Because of his love of archaeology. And the other one is - this is a more cynical one, which is that the Federation will have collapsed, and he'll basically be like an eye-patch captain or admiral of the last remaining fleet, and it'll basically be Battlestar Galactica in the Star Trek universe.
Taylor: Yeah, that would be interesting too, it would be a big shake up for the Star Trek world.
Len: Well, thanks a lot Taylor, for taking the time to do this. I really appreciate it. We did it on a little bit of short notice because of the Laracon EU conference coming up, which Leanpub is humbly sponsoring to the extent that we can. I know you'll be speaking there, and I know everyone in Amsterdam will be looking forward to hearing from you.
So, thanks very Taylor for being on the Leanpub Podcast.