Subscribe
Share
Share
Embed
In this conversation, Ben interviews Taylor Otwell, the creator of Laravel. They discuss everything from the age-old argument of tabs vs. spaces to the origins of Laravel and how Taylor has turned it into a thriving, sustainable business.
Links:
Laravel, the framework Taylor created
Tuple, used by the Laravel team to collaborates
Takeaways
Links:
Laravel, the framework Taylor created
Tuple, used by the Laravel team to collaborates
Takeaways
- Coding preferences and philosophies can vary among developers and programming ecosystems.
- Maintaining backwards compatibility is important for frameworks with a large user base.
- Clean code can be subjective and depends on the specific needs and goals of a project.
- Testing is crucial for shipping software with confidence. When starting a new project, consider writing documentation first to iron out any potential issues and ensure a user-centric perspective.
- Focus on high-level testing, such as feature-level or controller-level tests, to gain confidence in the functionality of your code.
- Challenge assumptions and ask questions to improve the quality of your code and avoid unnecessary complexity.
- Believe in the potential of your project and raise your ambitions to achieve greater success.
- Building a business around open source can be a sustainable model if you create commercial products that complement and support the open source project.
Chapters
- (00:00) - Tabs or Spaces?
- (08:00) - Shells
- (10:46) - Minimalism in Coding
- (17:24) - Stripe and Their API
- (22:41) - Aesthetics
- (25:09) - A Coding Hill You Would Die On
- (28:09) - Clean Code
- (33:38) - Testing
- (40:30) - Personal Involvement With Code
- (45:00) - Notes and Manifestos
- (49:09) - Skill Over Time
- (51:49) - Ian Landsman and Laravel
- (55:49) - Businesses Based on Open Source
Creators & Guests
What is The Tuple Podcast?
Ben Orenstein interviews great programmers about their craft.
So I want to start with something non
-controversial and ask you tabs or spaces.
Oh, we use spaces in Laravel, but I think
there's merit to the tabs argument, if I'm
being honest.
Yeah.
You know, I have to give it credit.
Yeah, you could be convinced.
Yeah, so when I originally wrote Laravel,
it actually was tabs.
OK.
And, you know, so of course, I guess the
merit I'm referring to is people can kind
of configure what that looks like.
on their machine.
At some point in the PHP ecosystem, there
was sort of a coding standard that was
adopted across the whole ecosystem.
And it gained a ton of traction across
tons of projects.
And it dictated that you use spaces.
And that's when we moved to spaces, sort
of.
They forced our hand, in a sense.
But we were originally tabs.
Interesting.
OK.
And do you miss that?
Did you take advantage of the fact that
you could change what a tab meant?
I actually didn't on my own machine.
But I know that's just one of the things
that people refer to as an advantage of
tabs.
Gotcha.
Yeah, that's fair.
I wonder if people do that at all, or if
that's just an argument that justifies
after the fact some other preference.
Yeah, I'm not sure.
You come from, I think, a Rails
background.
That's a spaces environment, right?
Yeah, I think Ruby's all spaces.
I don't think there's any traction on the
tabs in Ruby land.
But it's that whole like, I do this, but I
respect the other side's argument is how I
feel a little bit about like Vim and
Emacs, for example.
Like I'm a Vim guy, but I got to admit,
Emacs is a great editor.
It's being able to like code your, like
configure your editor and Lisp is badass.
The fact that it's just like a running
Lisp instance is just super cool.
So I respect both sides.
Yeah, and I've never used Emacs.
I've only used Vim.
Vim's not my primary editor, but I'm...
proficient enough to like make changes in
a program if I need to using Vim, if I'm
in like a production server or something.
But yeah, all of my college professors
were big Vim users.
And that's all we used in all of our
classes actually.
So I got a lot of Vim experience then.
Nice.
I feel like people should try it.
Like I think it's worth knowing to
experience like, hey, modal editing is a
thing.
It's kind of a different paradigm than
everybody else.
basically everybody else uses.
I think that's just like worth exposing
yourself to even if it doesn't really
click for you.
Yeah, I agree.
So what is your daily driver now?
What do you what do you code in?
I am in die hard, die hard, loyal to
sublime text still.
Oh, OK.
Which I don't you know, I don't know what
the current state of sublime text is as
far as user adoption, but.
Before like VS code and I mean before VS
code there was like the atom editor from
github I don't know if you remember that
but sure and they kind of VS code came out
and it feels like VS code grabbed a lot of
Sublime text old market share, but sublime
text is just so dang fast.
It's so light feeling You can just fly
around files.
It's so much faster than VS code which I
think even VS code users admit I think the
The downside to Sublime is its package
ecosystem is not nearly as vast as VS
codes is at this point, probably because
you can write things in JavaScript and VS
code, whereas in Sublime Text, you're
writing Python, which maybe is not as
widely known, I guess.
So yeah.
When you say fast, is that like fast to
start, fast to open files?
Like what is fast?
Yeah, both.
Everything.
Okay.
Yeah, fast to start, fast to open files.
just navigating around files even somehow
feels faster within a single file, you
know.
Interesting.
Okay.
Yeah, it's just a pretty sweet little
editor.
And I think it's cool because it's one of
those projects that's written by kind of
one person.
It reminds me of like a roller coaster
tycoon or like Stardew Valley, you know,
or some of these pretty ambitious
projects.
Those are both games, but they were
written by a single developer all the way
through.
and sort of achieved worldwide fame and
success, which is, I think, pretty cool.
And Sublime Text is like that.
Was there going to be some big Sublime
Text rewrite that never happened?
Or am I remembering that right?
There was a long break kind of between
Sublime Text three and four.
And the Sublime Text author, I think his
name is John Skinner, he'll just disappear
for months, you know, and then he'll pop
back out with a huge update.
And there's not a lot of updates in the
meantime, you know of like hey, yep still
working on it.
Here's what I'm doing It's just radio
silence and then boom sublime text 4 and
then that kind of a year like I kind of
get that You know, it's just like I'll be
in my coding cave.
I'm not gonna talk to you Yeah, I like to
imagine he lives on like sort of a
Caribbean Island and just resurfaces every
now and then to Ship an update.
Yeah, he doesn't have any internet.
He just had like every few months takes a
boat to the mainland like upload something
Yeah, exactly.
I thought what are you using?
I mean, so most of it, I'm still Vim.
Like my VimRC is like almost 20 years old
at this point.
Yeah, but yeah, it's just it works for me.
Yeah, I think once you're that invested in
Vim, you know, it's probably hard to
totally.
Yeah, I mean, it's like super, super
sanded down to like be like the way I want
it.
You know, it's like it's really highly
configured and I have a lot of muscle
memory built up and I still feel like.
at least for most of the editing I'm
doing, it feels like the fastest for me to
get code out and to make changes into
files and things like that.
I think there are times where I'm a little
jealous of certain things, like, oh, are
there better debugging tools or
refactoring tools or slightly higher level
things that maybe I'm interested in?
I want to check out Zedd.
That seems pretty cool as an editor.
I don't know if you play with that.
I haven't.
And I actually don't use a lot of those
kind of higher level tools either.
Are you a shortcuts guy?
Are you kind of like arrow keys, just like
doing an old -fashioned way?
Yeah, I use a lot of shortcuts for sure.
I don't use a lot of like high -level
debugging tools like that, you know, like
kind of IDE style debugging tools.
I don't really get into that.
I think because a lot of what I do is
program for the web, and I've actually
found that like early in my career, I
wrote .NET desktop applications.
where the application starts up and it's
sort of like this long -lived process,
right, that has sort of state that is
maintained over hours potentially and
variables and things.
And I find that when I'm writing web
software, you know, any given web request
exists for an order of milliseconds.
And the path through the application is
generally easy to follow from beginning to
end as far as what is happening.
And I just don't feel like it really
requires like...
a step debugger to step through those
kinds of situations very often.
Whereas when I was writing desktop
applications, I used the step debugger and
all of those tools in Visual Studio every
single day because there was this
complicated state in the desktop
application and you kind of need to step
through it or even reverse and see what's
happening when users click certain
buttons.
But I just haven't had that experience on
the web as I haven't found myself reaching
for that.
Yeah, interesting.
It was a trip going from desktop to web.
Yeah, I mean, super different.
But I like writing for the web.
And when I'm referring to the web, I'm
primarily referring to server -side web.
So I'm sure if you're writing heavy client
-side applications, I think those bear
actually more resemblance to desktop
application development than back -end web
development, where a quest is in and out,
done, over.
So yeah, it was a big change.
But I'm...
I enjoy it, you know?
Yeah, totally.
So switching from editors, do you have
thinking about shell?
Do you have a are you a what shell are you
using?
I use that.
Oh, my.
Is it zish?
Yeah, sure.
Zish.
I think.
Yeah, I use that.
I don't configure it all that heavily
other than how it comes out of the box.
I just have like a pretty simple bash
profile that sets up some aliases and
some.
a couple of functions, but I'm not a, I
don't have a ton of customizations, I
would say to my shell.
Do you make heavy use of the functions and
the aliases you write?
Like what do you use it most frequently?
I have a lot for jumping around different
directories on my system.
I have some for like, Sim linking certain
directories so that I can test Laravel,
the framework against like the application
skeleton without kind of involving a
package manager.
I have some related to like SSH -ing into
different things, but I mean nothing too
crazy, pretty basic stuff, I would say.
And then your Sublime Text, similar deal,
not super configured?
No, I have a few packages.
I mean, I kind of like that.
I feel like it's kind of like even on my
iPhone, I tend to try to use like the
native apps, you know?
I try to use notes, try to use music.
So I think that carries over into like my
dev stack where I try not to actually get
into this sort of crazy customization
because I feel like when I start up a new
machine, I just kind of like not having to
do a bazillion different things to get my
sort of like environment configured.
It's just a lot to wrap my head around.
So I like to keep things as simple as
possible in general.
I bet I only have like seven or eight
extensions installed on Sublime Text.
You know, it's pretty simple.
And on the dot, I do have...
basic dot files, but again, nothing crazy,
you know?
Okay.
Nothing super nuts.
No.
Not even a dot file big enough to put in a
GitHub repo.
It doesn't even feel worth doing that.
Yeah, interesting.
And so it seems like maybe that's kind of
a philosophy of yours in some sense.
Yeah, I think, I mean, I'm a minimalist in
general, you know?
I was definitely even more of a minimalist
before, like I got married and had kids.
But still a minimalist, I would say.
And I think that carries over outside of
my personal life.
It definitely carries over into my code
life, into the way I write code, the way I
set up my environment, everything.
And I think it carries into Laravel as
well.
I think I've tried to maintain a sort of
minimalist philosophy as I write Laravel
as well.
Totally.
I watched that documentary that...
somebody made if about Laravel recently
and Yeah, I heard the word minimal a lot
of times that seemed to be like a really
core thing that you cared about Yeah,
yeah, we tried to avoid obviously
complexity at all costs I mean, I think
every programmer would say they like to
try to avoid complexity But yeah, we
definitely I At least try to make that a
priority for sure.
Yeah, so what was how do you given that
everyone wants it?
But I would say minimalism is actually
probably in sort of short supply.
Like, what are you doing that actually
works there?
I mean, just kind of getting into the
nitty gritty of like how I like to write
code.
But great.
I try to keep the code like to me, good
code is just code that is easy to change
and doesn't have a lot of like sort of
like apparatus around it or like.
You know, it's not like this big ornate
cathedral that feels extremely
meticulously designed to be this perfect
creation that will withstand all business
use cases without, without, you know, it
will be able to absorb any use case we
need because it's so flexible and so well
thought out.
And I actually gave a talk a few years ago
where I sort of parroted a quote by, oh,
it's a lady.
I'll have to look up her name after the
podcast and put in the show notes.
But she said, you want your code to be
like Kenny from South Park and not like T
1000 from Terminator.
Disposable, easy to change, you know,
because as much as you can try to like
plan ahead for so many different business
use cases, it just never pans out.
It seems like and that's actually what
leads to a lot of complexity.
I think in code is trying to anticipate
all of these future scenarios.
Whereas if you just keep the
Write like the minimal amount of code you
need now.
And I think there is some balancing to
this.
Like you can't just be sloppy or, you
know, do something totally, you know,
that's just going to cause you a lot of
problems later, be significant tech debt,
but try to write the minimal amount of
code to get the job done well, let's say,
and go from there.
You know, don't try to anticipate every
single business case you might have in the
future on your product and code around
that.
It seems like it could be that like having
an opinion enables minimalism.
Like if you decide like this is how we're
going to do cues in Laravel and like this
is going to be a small API.
Like this is how we do it.
And we're not going to support a bunch of
other things.
And that lets you have a small surface
area and like keep things minimal.
Does that sound right to you?
I think so.
Yeah.
I mean, yes, agree.
If you have opinions, you can keep things
much simpler for sure.
And I think.
Laravel is an opinionated framework in the
sense that it's born out of the Rails
lineage of sort of inspired frameworks,
which Rails being an opinionated framework
written by a pretty opinionated developer.
We definitely follow in those footsteps,
and it makes our life easier to an extent.
So we try to keep things like, as far as
Laravel goes, keep things extendable and
flexible where people can write sort of
third -party packages to...
hook into maybe some interfaces we've
written or contracts we've written in our
queue system.
Like, hey, as long as your queue system
does like a push, a pop, or whatever, you
know, queues do, you can just write your
own driver and support your own queue.
So we try to do that and it helps us keep
the core pretty minimal.
Yeah.
Do you value backwards compatibility a
lot?
Like, do you try really hard to maintain
that or is that like a thing you're
willing to sacrifice for cleanliness?
So...
As Laravel has gotten older, and I
released Laravel in 2011, I value
backwards compatibility more so, the
longer that Laravel is around.
When Laravel was very young, like in 2011,
we made breaking changes all the time,
because there weren't that many users.
Most of them were early adopters that were
sort of used to living on the cutting
edge, and were perfectly willing to have
breaking changes in the name of like
progress and fixing things that kind of
weren't panning out in the framework.
And we were sort of still feeling our way
through.
what we wanted the framework to be like
and what we wanted its personality to be.
Now though, 12 years later with so many
businesses and so many developers using
Laravel, I do feel a greater obligation to
maintain backwards compatibility, mainly
because I know how much it sucks to update
dependencies that are breaking things all
the time.
So we definitely value that.
We do releases once a year and there are
usually some minor breaking changes and I
sort of...
think about it in time.
So in our documentation, we list like
estimated upgrade time.
And I try to keep that like 15 minutes,
you know?
So there's a few breaking changes, but
it's not hours of work or days of work.
And try to try to do things that we can
automate as well.
Yeah.
So does that do you find?
So that basically requires you to get it
kind of right in the first place or?
to have some sort of like compatibility
layer that you insert for people that lets
them not have to change if they don't want
to.
So do you feel like you're...
That sounds right.
So are you investing a ton of effort in
trying to get the initial API correct?
Does that sound like you?
Yeah, I would say so.
I mean, we're definitely very hesitant to
take on new APIs because once we do, you
know, we're committed to that API.
So I definitely think those through a lot
before we adopt them.
And yes, we do try to, like say an API
doesn't pan out or it just kind of like
doesn't feel right.
We do try to develop a new API while
keeping the old one.
So like this, say, I mean, let's just keep
it really simple and say like, I hate this
method name that we named this method.
Like we could obviously just leave the old
method in there.
We'll make a new method.
We'll have the old method just call the
new method and everything sort of works.
We do that actually fairly often if we
want to.
Fix things but not break things.
Nice.
Yeah, we should turn off your automated
reaction things.
I don't if you just saw that.
Yeah, what was that?
This is a new Mac OS feature they turned
on by default.
I think if you click the green camera in
the menu bar, there'll be a little video
thing somewhere.
I see that, reactions.
Oh, I turned it off.
Okay.
You do it per app, by the way, so get used
to doing that.
Wow.
Which is a wild decision.
Yeah, so then...
Yeah, I feel like the I heard interesting
things about like how stripe maintains
their their API or there's all of these
transformations They've written going
basically back to the beginning of time
where it's like you can just be on any
version and they will translate it for you
to get to you where you need to go and
that's just like that that commitment to
To not making programmers go back and
change stuff.
I feel like it's kind of an
underappreciated Bit of work that keeps
your thing popular and appreciated and
loved
Yeah, and one thing I've talked about
actually with with Adam Wathen on this
topic is I don't like people to go
shopping on the framework.
Like if I make a bunch of breaking changes
And I think you can kind of see this Maybe
with like view 2 to view 3 I don't want to
put like view and to negative of spotlight
But when you make a lot of breaking
changes and people sort of have to almost
rewrite it feels like if I'm rewriting
Now there's sort of like a question in my
mind of what should I rewrite it in?
And it's not necessarily going to be the
same thing.
And programmers love a new thing.
They're excited to try the new whatever.
So they'll take that They would love
nothing more than to rewrite the whole app
in an entirely new stack.
Not just rewrite, but rewrite in a new
place.
Yeah, with a new thing.
Absolutely.
So I try not to sort of instigate that
mentality in developers.
Because if we have to rewrite,
Why not rewrite in React or Zvelt or in
Laravel's case, why not rewrite in, you
know, I don't know, Rails or Django or
Next .js or whatever it is.
Yeah.
So is there anything besides trying to get
the initial API right and trying to like
not just like be conscious of breaking
changes that helps you keep avoid that
fate?
A lot of the stuff we do, I would prefer
it to be born out of real world needs.
So like surprisingly, when people
contribute to a framework, they will
contribute things that they actually have
never needed in the real world.
And I think when you do that, that's when
you run kind of the biggest risk of not
getting the API right, right?
Cause it's not really born out of any
application need or any business need that
you actually had in the real world.
And I think that's one thing that benefits
Rails and benefits Laravel quite a bit is
that both of the frameworks,
are sort of extracted out of real world
stuff, whether it be Laravel's queue
system or authorization system.
And like, you know, I saw Rails just came
out with a new solid queue that's sort of
born out of their queue experiments and
sort of database backed queues and also
their new solid cache package.
I think that helps you get the API right,
you know, because you know that the use
case is valid, that the methods make
sense.
So I'm always very hesitant and I've
actually closed PRs on the Laravel
framework that I could tell were sort of
built in a vacuum and they weren't
connected with any sort of real
development need.
They're just sort of cool to have.
I think that's risky.
Is there a smell that you noticed that
those have?
Yes.
So I see them come in, like we'll get,
let's say we get one PR that adds a
feature and it gets merged.
someone will see that it gets merged and
then open a very related PR to add maybe
like a complimentary method or something
that I know for sure they have not had the
need for yet.
They only saw the first PR get merged.
And so they're like, oh, well, it would be
cool actually if we had this too.
And I almost always close those.
Interesting.
I can tell.
I can tell where they're coming from.
I assume there's probably a little bit of
a sense of cache from getting a PR merged
into the framework.
Like do you?
I picture myself as a young developer
seeing that, like, ooh, we added first,
second, and third.
Maybe if I make a PR for fourth, that'll
get in there.
Exactly.
And then I get my name on the contributors
list.
Yeah.
And I get it.
People do get excited about contributing
to big open source projects.
But yeah, that's exactly the kind of PR
I'm referring to.
Gotcha.
Yeah, nice.
I've heard that your comments are a little
bit infamous.
You have a very specific comment style.
I would love for you to opine about
comments.
Yeah, so all of the comments in Laravel
are three lines long and each line is
three characters less than the line before
it and I don't know I honestly don't
remember how or when that started but
eventually it became Kind of a thing and
it felt like I was so invested in it.
I might as well keep going And make every
comment that way from now on
There's actually a pretty funny like stack
exchange post from me.
This is pre Laravel actually I was still a
dotnet developer asking like is it dumb to
care about these sort of aesthetic things
in a code base And most of the answers
were like yeah There actually is better
better things that you could be spending
your time on probably But I don't know it
is sort of like is a small thing that
makes me happy when I go through the code
base and like all the comments are the
Same even though it has no real value but
yeah, it's kind of become just like a
a shtick at this point and we just keep it
up in the code base.
Yeah.
It seems like you have a strong, like,
aesthetic sense or like a sense of craft
and like you care about small details and
things.
Do you feel like that was like, was that a
learned thing?
Like, are people born with that?
Did you pick it up by seeing other people
do it or something?
Like, where did that come from?
Probably a little bit of both.
I definitely picked it up some from seeing
other people do it and not seeing it just
necessarily in programming alone.
Like for example, I used to mow grass when
I was in college and back then my grandpa
would help me actually sometimes.
And after every time we mowed, he would
make me lift the mower up on this like
lift and spray off the whole underside of
the mower before we put it back in the
garage.
So it didn't get any, a single blade of
grass in the garage basically.
And he just sort of had this personality
in general of like, you know, like,
finish the backside of the piece of
furniture, you know, make everything look
good, even if no one's going to see it.
That kind of personality, I guess.
And I did pick up on that and sort of
carry it over into programming in some
sense where if I knew, for example, that
like there was some nasty file took deep
into Laravel that was just gross.
I just like couldn't sleep well at night.
Like I wouldn't want to even use Laravel
at all, you know, because I would know
that deep down in there, it's sort of
like.
Farce and there's this ugly code and I
can't well, how can I build my business on
this piece of trash, you know?
So I think it is a little bit OCD to an
extent in a legitimate sense, but that's
just sort of like It's been a it's been a
good thing for Laravel I guess in the
sense that it's made me really thorough in
terms of the quality of the tool I feel
like this I feel like I I can empathize
with some of this where I think I think
people that create stuff
to create things tend to have this like,
it has to be amazing and like it's trash
otherwise.
And like you just want it to be so perfect
and so good.
And I feel like all of us are just kind of
like, man, it sucks today, but eventually
I'm gonna make it like so good.
Once I get these last few things, it's
just this constant sense of not quite good
enough.
And it can be hard to live with, I think,
because it's not, it doesn't feel, yeah.
Yeah, it can be hard to live that life
sometimes.
when you're focused on the negatives and
like needle things to want all the things
to be perfect.
But I do think it leads to really great
software.
Yeah, I agree.
All right.
Do you do you have a coding hill that you
would die on?
Oh, gosh.
What's an example of a hill?
Like, do you have a hill?
Like all instance methods should be like
one line, Max, maybe three lines if you
are an emergency kind of thing.
Um.
Wouldn't say I have a hill that specific
No, I can't even honestly think of like a
certain hill I would necessarily die on in
that sense I Mean I I think in general We
have a few guidelines that I try to follow
I like to keep methods fairly short I
would say but not necessarily a specific
number of lines of code one thing We also
try to avoid really small thing, but I
think it helps
in terms of code readability is we never
make callers of like a function pass
Boolean flags to change the behavior of
the function.
So basically you don't want to end up with
a function that's like some method name,
open parentheses, false, true, false,
true, true, false, you know?
And it's just like imperceptible from the
outside what any of that means.
So in all of Laravel, you never would have
to pass a Boolean flag to any method.
So the way we work around that, you know,
is usually having another method.
Like, let's say we have a method that
generates a URL.
We have a function called URL.
And maybe sometimes people might be
tempted to put like a Boolean flag if they
want the URL to start with HTTPS instead
of just HTTP, like a secure flag, let's
say.
We would just make like a secure URL
function that requires you not to pass the
Boolean flag.
So we do that throughout Laravel.
But I don't know.
None of them are like...
That's actually probably one of the
strictest rules we have.
I would definitely die on that hill.
Before I would put a Boolean flag in the
Laravel docks, I would rather delete the
project, I feel like.
Nice.
By the way, I think that's a really good
anti -pattern to know about.
The term to Google is control couple.
I remember reading about this...
quite a bit.
It's it's sort of like you're effectively
leaking into all the colors of this
method, the conditional that's in the
method.
You know, it's like, everybody knows I got
a conditional and it looks like this.
And it's like, that's not, you're not
supposed to know that.
That's a secret.
Yeah.
That's true.
Yeah.
Call, call the other.
Yeah.
So, so split them into different methods
and call, call what you actually want is I
think a better approach.
By the way, I just like Google control
couple just to remind myself.
And the first result is the anti pattern
that I was speaking about.
The second one is, are you in a
relationship with a controlling partner?
Nine signs.
It's bad.
And it's bad in a lot of contexts.
Yeah.
So no.
So no control couples allowed in there at
all.
No.
And you know, one thing, if I can bring up
something, I think one thing I find
interesting about clean code.
is how clean code is seen across different
ecosystems.
And you may have some insight into this
because we kind of come from different
ecosystems in a sense.
Yeah.
But like when you say clean code, do you
mean the book or the concept?
I mean, a little bit of both, actually.
So like in the PHP and dot net ecosystems,
clean code as in the book and clean code
as in like the Uncle Bob sense of clean
code, if people have heard of this person
is like super popular.
So.
tons of like tons of directories and
architecture and interfaces around
separating concerns really, you know, a
lot of ceremony around getting all of the
application architecture just right with
all of these boundary layers and how they
interact and things like this.
And it's just like a super popular thing
and in .NET.
And I think that's leaked over into PHP
and maybe Java as well, let's say.
Whereas like in JavaScript and
Even in Ruby, to an extent, I feel like
it's not the same emphasis.
And it's like not the same influence of
the same people has bled into those
ecosystems.
And it creates sort of different
definitions of what clean code means.
Whereas like in PHP and .NET and Java, I
feel like clean code means your code is
separated into different files in the
right way.
And they have the right interfaces.
And...
You know, they're typed the right way.
Whereas like in Ruby, or at least in
Rails, it feels like clean code is sort of
code that reads like prose or is, you
know, like more English, plain English or
something.
And it's not the focus is not so much on
like architectural purity as it is in like
ease, how easy it is to read and, you
know, kind of the syntactic sugar of the
code.
Yes.
Which I find interesting.
Yeah, that is interesting.
The word that popped into my head, it was
like idiomatic.
Yeah.
It feels like languages will have
different idiomatic ways of writing code
that is kind of distilled from the culture
of the people who are writing it in a way.
Like you could certainly write, like the
thing when I think of clean code, I think
of the solid principles, like the capital,
all caps.
And like, I would say...
I bet DHH would be like, yeah, that's not
that interesting.
I'm interested in how the file looks.
I'm a software writer, and I want to write
it like an essay a little bit, and it
should look a certain way and feel a
certain way.
And this thing you're telling me about the
Liskov substitution principle about how
this class should be able to stand up for
that class, I don't really give a shit
about that.
That's not that interesting to me in this
hypothetical world where I'm refactoring
in this certain way and using a class
hierarchy.
And so I think it's.
But I think that resonates that sort of
approach resonates more and maybe like
other o languages that are just just with
different people in them Yeah, and I think
one one place I was going with that is the
salt like take for example the solid
principles of clean code Yeah, which I
think in general are kind of helpful Some
of them are more helpful than others.
I think But I think it can lead to this
sort of
idea that clean code can be boiled down
into like a checklist.
And if I do these things in my code, the
code is going to be good and easy to
maintain.
And it's sort of, I feel like it's almost
a little bit of ironically, a lazy way to
code in the sense that you're, you can
not, you can sort of check out your real
critical thinking and just say like, as
long as I'm doing solid, the code is good
in this very robotic, you know, fashion.
Yeah.
And I think it's sort of chasing a silver
bullet to clean code that maybe isn't as
clear cut as you would like it to be.
And I've seen this a lot when working with
especially younger developers who are just
getting into code and they're kind of
taking code serious, which is good, but
they sort of latch on to sort of these
checklists that they can follow to achieve
clean code.
And I think it lacks a little bit of the
intuition that is needed.
when writing clean code, a little bit of
just like the experience of coding for
years and kind of knowing, hey, typically
when I've written code in this way, it's
gone poorly.
You know, like when I've written code in
this way, it's gone well.
And that's just born out of years of
programming, I think.
It can't be summarized into a checklist.
Yeah, I feel like that's also kind of what
makes coding so hard is like, hey, did I
pick a good architecture for this?
You can't even know that today or this
year.
Yeah, you know, you'll you'll know that
maybe like three years from now when like
you're trying to make these complicated
changes or like new people are coming up
onto the system and trying to understand
how it works and reason about it or it's
it like takes a long time to even get good
feedback from your decisions.
Yeah, it really does.
Yeah, unfortunately, you're making a piece
of a pottery.
You can be like, all right, this is a good
bowl of water.
It's you know, it's watertight.
It didn't fall apart.
And like, yeah, it looks nice.
I did it, you know.
Yeah, but like does did the queue system
turn out well?
Do we pick the right API for this or like
are we gonna regret parts of this later
that we couldn't anticipate?
That's that all comes much further down
the road.
Yeah.
Yep.
How do you feel about testing?
I like testing.
We write.
I write a lot of tests.
Laravel has thousands and thousands of
tests.
I don't do a lot of tests first.
I would say I do a lot of tests during
kind of tests after.
But yeah, huge fan of testing in general
would not be able to ship software
confidently without tests.
I don't think Definitely think it's you
know something that every developer should
learn But yeah have no strong opinion in
terms of like test first or test driven
development, I would say Gotcha went so if
you're what does it look like when you
are?
Tackling a kind of law a large new Project
of some kind you like are you a
prototyper?
Like, do you...
What does this look like?
When do the tests show up?
Okay, well, like, let's take, for example,
like a new package or a new feature in
Laravel.
A lot of what I do first is just go into a
blank text file and start writing kind of
my dream API for what this is going to
look like from the outside in.
So basically, kind of like what the
documentation is going to look like.
What are the examples that are going to be
in the documentation?
And sometimes I even call this, you know,
like documentation -driven development.
I think that helps iron out a lot of the
the warts and like problems in your idea
if you have to write out sort of how
people will use it and I also kind of
carry that over into Say I'm building like
a full app.
I have a whole new product idea I'll build
a UI first And it doesn't have to be like
pretty, you know, I'll just use basic
Let's say tailwind classes to sort of get
some basic shape in place, but I'm
definitely not like, you know
tweaking every drop shadow and every
gradient.
But just to make sure that the user
perspective is correct first.
And I didn't used to be this way.
When I first started programming, I would
do like back and I'm going to build this
whole API first that has no front end.
It's front end agnostic.
And that sounded like really appealing for
some reason to my developer brain.
But I was bitten by that sort of several
times where I would build this big API
that was front end agnostic.
And when I went to write the front end,
there was all these awkward things I
needed to do that the API didn't
accommodate for.
So now I start from the outside and work
my way in both if I'm doing an application
or I'm writing something that's just
purely a Laravel feature, like a package
for Laravel that doesn't have a UI at all.
In that case, I would start with a
documentation level, basically.
Gotcha.
And do you like to have like...
Will you spin up a new Laravel app to try
to use this thing?
Like you make it like a toy example kind
of?
Yes.
Exactly.
I do that every day almost.
I actually just have a blank Laravel app,
you know, ready to go to kind of like a
sketch pad that I can just write, drop an
idea into.
Got it.
And then from that app, you're like
writing calls you wish you had and then
updating the framework to try to support
that.
Yep, exactly.
Nice.
And then once you have it the way you like
it, some of those calls probably become
unit tests on the new functionality.
Yep, then I'll just go back in and fill in
the test and you know ship it out there
pretty much.
Yeah, are you are you?
What was your balance?
Would you say between like kind of lower
level unit tests versus higher level
integration type things?
This is another thing that's changed.
I think over the years Earlier in my
career.
I wrote a lot of low level tests.
They ended up feeling really brittle I
think I think there are certain classes
that like lend themselves well to low
level testing things that are sort of
really like say like you pass in a string,
you get out a string, you pass in an
array, you get out an array.
And they're like these very unit testable
types of classes, like a classic like
calculator class or something like that.
Where I feel like those kinds of things
actually lend themselves well to like low
level testing or even just like test
driven development.
But when I'm building web applications, I
test from like the feature level or like,
I guess you would say the controller level
of like, let's make an actual simulated
HTTP request into this endpoint.
we're actually going to assert that
certain records exist in the database
afterwards.
We're going to assert that a mail was
maybe dispatched to some user or a mail
notification or text message or whatever.
And some of those things might be sort of
like faked.
Like, of course, we might fake like the
actual mail sending.
But in general, the test is very high
level.
I just feel like I get so much more
confidence out of those tests.
And I guess the downside is if something
goes wrong, maybe it's not as granular
what exactly went wrong during the
request.
But in my experience, it's still been very
quick to sort of diagnose what was
happening.
And I just get so much more confidence out
of those tests versus like these very low
level tests that almost start to feel
coupled to the implementation of the code
that they're testing in a way.
And in general, I find that also,
the higher level test helped me achieve
what I consider to be the goal of testing,
which is one, shipping software
confidently that you know works, but then
also two, being able to change the code
without significantly changing the tests.
And I think a lot of people actually get
their tests so coupled to the code because
they are so low level that they're almost
one -to -one in terms of when they change.
And to me, that's like losing one of the
main benefits of even having tests is,
the ability to refactor the code or
improve the code without changing the
tests.
So that's why I kind of prefer, honestly,
high level end -to -end tests.
Gotcha.
Yeah.
I would say my style has moved that way as
well recently.
I was a pretty hardcore TDD practitioner.
So I was like, well, I need a lot of unit
tests to drive the next step in this
process of me writing another method and
changing how that method behaves.
But I had of come to the same conclusion
you did, which is that,
The maintenance burden of tests that are a
bit too low level is really pretty high.
And it just doesn't feel...
I feel like I get way more leverage on the
higher level ones.
Yeah.
And you know, like, I keep bringing up
Adam, but I think Adam Wevin actually has
one of the best testing video courses out
there.
It is a Laravel -based course.
It's a video course with like, I don't
even know how many hours of video.
It's gotta be like 100 hours.
But he does a high -level test, but tests
first.
And I think even if you don't use Laravel
or PHP, it's such an awesome course to
check out because it demonstrates, I
think, how to write tests that aren't
brittle but still write tests first if
that's kind of like what people are
interested in.
I don't know.
I found it super cool.
It actually was very influential, I think,
in my own testing journey in a sense.
Cool.
Nice.
That's test -driven Laravel, I think it's
called.
Yeah.
I remember that that was a beast.
I think I remember talking to him as he
was trying to get like the 80th through
100th video released.
Yeah, yeah, that was a quite a labor.
How often are you looking at like a big
chunk of code that you're trying to
understand?
Does this happen frequently with like
contributions or like picking up a
different library or something?
Is this at least weekly?
I would say I don't know I would go so far
as I daily, but weekly for sure, mainly in
the form of pull request, but also in the
form of code that.
employees here at Laravel have written and
we kind of have a peer review process
where probably other people have looked at
it first and we're kind of getting to the
point as well where I don't scan every
single line of code in our commercial
products.
I'm just gonna be such a bottleneck.
But at the framework level, I actually do
read through every pull request to this
day.
I'm the only one that merges pull requests
into the Laravel framework still.
So I review every single pull request and
of course some of them are pretty
complicated.
And so I would say about once a week I'm
looking at a pretty beefy pull request
that let's say is 20 files changed.
I would consider that kind of like in my
context a pretty big pull request for the
framework and sometimes even more than
that.
How do you do that?
Well, I don't know.
I try to tackle like the hard things
first.
So just in general, not just on this
topic, but if I have something that I'm
trying to tackle, I'll just do the hardest
task first and just get through it.
So I kind of do that with pull requests.
I don't really have any secret other than
just like gritting your teeth and pulling
down the pull request and going through it
kind of file by file.
So first, I'll take like a high level
cursory overview, just like in the GitHub
web interface and kind of get my head
wrapped around.
in general what they're trying to do and
then I'll pull down the pull request
locally go file by file checking them off
on GitHub as I go, you know, making sure
everything looks good renaming variables
refactoring methods if I need to, you
know, things like that.
Interesting.
Okay, so you'll so you'll you're editing
you're making edits here as you go.
Yeah, like maybe pushing to a branch that
is like their changes plus yours kind of
thing and merging that later.
Yep, exactly.
And I will say that like the bigger your
poor request is to Laravel, it has to be
really valuable.
So I'm all about like bang for your buck
poor requests.
So my favorite poor requests are obviously
poor requests that are like two lines
changed, but immense developer value like
added.
Because obviously almost no maintenance
burden, tons of value added for the
hundreds of thousands of people using
Laravel.
Like that's ideal.
The bigger your poor request is,
it has to be really freaking good in terms
of value added because I have to take over
all of the maintenance burden for that
feature going forward.
And it doesn't matter honestly how hard
the person promises that they'll stick
around and maintain the feature.
Just like you have to understand that life
happens, they change careers, maybe
they're in a different language, they're
at a different company and they're not
even using PHP anymore and it's like, hey,
sorry.
I don't remember exactly why we did this,
or I don't even use PHP anymore.
So I just assume that we're maintaining
this forever without any help.
And in that case, the feature has to be
freaking awesome if it's going to be like
20 or 30 files changed in the framework.
Yeah, that makes sense.
Yeah.
Do you care about good commit messages?
Yeah, when we squash things down, yes.
Especially if it's pretty complicated,
what's being added.
I try to add something meaningful in my
own pull requests at least Just to kind of
you know make it easier for people if
they're browsing through and seeing what
changed Mm -hmm And so do you is this
mostly like a description of like a high
-level description of what's what's going
on?
What's part of this this change?
Yeah, pretty much So like we recently
refactored some stuff in Laravel to make
it a little bit slimmer a little bit
easier to onboard
sort of new developers into a little bit
less overwhelming out of the box.
And when I made that change, I actually
wrote a pretty detailed description in the
get commit message of like everything that
changed and why it changed and the
implications of that, because it was a
sort of beefy PR that fundamentally
changed some things in Laravel.
So if the poor request is more, you
there's a lot of kind of moving parts and
a lot of things happening, you know, I'll
write a more detailed message.
If it's a pretty simple change, that's
pretty self -explanatory.
I might not write much of anything.
Right.
Do you draw diagrams or anything as you
work?
Do you keep notes or sketches or anything?
Rarely.
I mean, I can only think of like a handful
of times I might have done that.
There are times I wish I had a whiteboard
next to my desk.
I feel like when I used to have that when
I was like in a cubicle, I used that
actually a lot to sketch out things.
So maybe the fact that I don't sketch out
things is just lack of access to a quick
whiteboard, but...
No, it's not something I really reach for
very often.
I'll more like write, I would say, like a
manifesto of a new feature more than I
would like draw something.
So I might open up Notion, go to a new
document, let's say, you know, new
database feature in Laravel and type up
like a pitch for that feature just to kind
of wrap my head around it and the benefits
and the drawbacks.
I do that more than like drawing diagrams,
I would say.
Gotcha.
Do you feel like there are habits?
that you follow that help you make good
code.
Kent Beck has this great quote, which is,
I think he says something like, I'm an
average programmer with above average
habits.
That's interesting.
Yeah.
I mean, asking a lot of questions as far
as like, why does it have to be this way?
Why does it have to be that way?
You know, challenging assumptions in terms
of what we're building.
Do we actually need this code at all?
I think is a good question to ask.
Totally.
Which is, you know, not probably asked
often enough.
I sort of agree that like I see myself as
a very average developer with, I think my
power in a sense is I have a very low
threshold for like pain, developer pain.
And there are just like certain APIs.
I'm just not willing to stomach.
And I think my threshold is pretty low
compared to other programmers around me
that I see where it's like they're willing
to put up with a little bit more
complexity, a little bit more like
cumbersome APIs and just sort of live with
it and move on with their life.
Whereas in Laravel, I'm just have such a
low threshold for what I'm willing to
tolerate in terms of like cumbersome,
awkward, gross.
unrefined API's are.
And I think that helps a lot keep Laravel
nice and clean and feeling fresh and
enjoyable.
Yeah, I thought that's kind of the secret
of quality is just like caring a little
bit more.
Yeah, I think that just works in almost
everything is like it's not that like I'm
so brilliant programmer or a product
person.
I think it's a little bit more just like
I.
I have low pain tolerance.
Like it's I get more annoyed maybe than
the average person.
Yeah, when things are not awesome.
And so I'm just like, well, can't we just
make it better?
And often the answer is yes.
But you only get to that.
Yes.
If you're like, I find this too annoying.
Like I want you to make it better.
Yeah.
So I've long thought that was sort of one
key to, you know, Laravel success in a
sense.
It's just you.
Yeah.
You not being annoyed.
Yeah.
Being okay with pain.
Yeah.
And I think needing things, you know, I'm
not I don't feel like an exceptionally
gifted computer scientist, you know, I
kind of prefer things to be easy and
digestible.
And, you know, so I tend to try to write
code that way.
I mean, it's probably it's probably better
that you aren't because if you were a
super brilliant programmer, it might be
hard for you to know that you have written
something that is hard to understand or
follow.
Yeah, I agree.
I think I'm an average developer that hits
average developer problems and writes
solutions for the average developer, and
that is a big market.
There's a lot of people there.
Yeah.
Yeah, nice.
So if you think about your...
So maybe you're an average developer, but
let's...
If you think about your programming skill
over time, when was that curve the
steepest?
In terms of when did I improve the most?
Yeah, when were you improving the most and
what were you doing that led to that?
I feel like I made the biggest leap during
my dotnet days when I was working with
some really talented dotnet programmers
that were much smarter than me and had
much more experience than me in building
software.
And I just leveled up like extremely
quickly in that environment, which kind of
sucks because I feel like I'm not in that
environment anymore necessarily.
Yeah.
And I it's just awesome.
If.
early in your career, you can be around a
great team of people that really know what
they're doing.
And not in the sense that like they're,
you know, ivory tower people, but just
they've got a lot of experience building
and maintaining software, and they know
what works, they know what doesn't.
And I just think you can level up so
quickly in that environment.
Yeah, I think if you're a newer programmer
optimizing for the quality of your
teammates is probably the number one thing
like over
product or salary like, oh, I'm super
excited about the app or like I would make
a lot of money.
Okay, fine.
But like, how good are the people on your
team and are they willing to teach you?
That's that's the thing I'll be thinking
about early in my career in particular.
Right?
Yeah.
Did you?
So when these when you were getting better
by working with these more experienced
programmers, what what was the knowledge
transfer like?
Was it happening mostly in code reviews?
Was were you sitting at lunch talking
about this stuff?
Were you pair programming?
It actually was more like in the code in
the code reviews like and I was not a very
good programmer.
I had only been programming for you know,
maybe a year professionally at this time
and obviously making like just you know,
new programmer mistakes or writing things
in a way that maybe I wouldn't write today
and they'd be like, hey, what if we wrote
it like this way?
Or have you thought about like taking this
approach and it would just like click and
be like, oh yeah, that actually is a much
better way to do things.
So it was a lot of that, a lot of just
friendly review and pointers in the code.
And then also looking at how they wrote
code.
Because say I just had a down afternoon
where I didn't really have much to do
because I had wrapped up a project or
whatever.
Then I could just go browse some code and
just see how things worked and see what
people were doing.
Do you ever do that now?
Not really, no.
I don't do that a lot now.
But I did.
definitely do that early in my career just
to kind of like get insight into how
people were tackling different problems.
Yeah, totally.
It's kind of shocking to me how I was
watching in that Laird Mill documentary,
what a big role Ian Lansman played.
I didn't recognize him as kind of like the
daddy that like kind of incubated this
thing and made it happen.
That was really fascinating.
Yeah.
I mean, I think Ian took a pretty big risk
on Laravel, I guess, early days.
I had released Laravel maybe six months
before I got an email from Ian, like, hey,
we build customer support software and we
kind of want to modernize some of our, you
know, PHP code base onto Laravel.
It looks like kind of a cool tool.
Would you want to come work for us and
help us do that?
And Laravel was like not a...
It was not a big thing at all.
Definitely not outside of PHP, but even
within PHP, it was not even in the top,
let's say four or five frameworks that you
might choose to write a new application
in.
So in that sense, it definitely feel like
he was placing a bet on a pretty young
tool.
But what was cool is when I got there, he
actually gave me probably six months to
just work only on Laravel, building out
features that we knew we would need.
Like we knew...
we would need a queue system.
We were handling lots of incoming email,
building a customer support tool.
We needed to really queue a lot of
incoming email for processing later.
We wrote the whole database migration
system.
We improved the ORM a lot.
Tons of stuff that we knew we would need,
I built during those months.
So yeah, I mean, it was a pretty pivotal
moment for the framework.
He's also the one that sort of first
encouraged me to have like a Laricon in
general.
He was like, hey, I think we could do a
conference about this.
about Laravel.
And I was like, man, I don't know.
Like, I don't know if anyone's going to
come to that.
And he was like, you know, even if it's
only like 100 people, we should do it.
It'd be fun.
And that's just kind of how it got
started.
Yeah, that's so cool.
I feel like my takeaway from that was that
it can be so powerful to believe in a
person and a thing and like encourage them
to raise their ambitions a bit.
Yes.
Yeah, agree.
I've done that in the Larval ecosystem
sometimes where I'll see like someone
write something really cool and I'll just
like email them and be like, I just want
to let you know, like this is a pretty
cool thing.
You know, if I can ever be in any
assistance to you, you know, like, let me
know.
Like not any kind of like I'm not looking
for any business deal or anything like
that, but just like if I can like put you
on in any way that helps you, you know,
like, let me know.
Yeah, I think that's really good.
Like, like kind of like watering the seed
a little bit, but it also seems like Ian
watered the seed and also like
told you like this could be bigger.
This can be like a real thing.
This conference can happen.
People could like really love this
framework.
Like it was like raise the ambitions, not
just like support.
I think this is good, but like this can be
more than you think it could.
Yeah, yeah, totally agree.
Because at the time, like when when I was
writing Laravel, the most popular
framework in PHP was a framework called
Symphony and like and also code igniter.
And I was like Laravel will like.
obviously never be his biggest symphony.
Like that's what I was thinking in my
head.
And that was fine.
Like I was just building Laravel for
really for myself, honestly, to build my
own ideas.
But if anyone else used it, that was just
added bonus.
And then once it was his biggest symphony,
it was like, it'll never be as big as
rails, you know, like it'll never reach
that level of like market permeation.
And then eventually sort of basically got
to that point.
So I don't know, just crazy.
But yeah, he did.
kind of seemed to always believe that it
could be much bigger than I did.
Yeah.
So, yeah, I hope people sort of take that
lesson.
I don't think it...
In this case, he gave you a job, so it
literally cost him something.
But I think the raising someone's
ambitions and helping them believe
something could be bigger doesn't usually
directly cost anything, but can have huge
impacts.
Yeah.
So you're one of two people that I talk to
pretty regularly, the one being Adam, who
have...
taken an open source thing and then built
a pretty huge business around it, which is
kind of wild.
And it feels a little bit like the dream.
It's almost like the best sort of freemium
business there is, whereas like the open
source thing is free and then there's paid
things around it.
Yeah.
Any thoughts on like how you pulled that
off?
Because I know you left Ian and you were
like, you're like, all right, I'm going
full time on Laravel.
Did you have a path in front of you when
you did that and knew how you were going
to do it?
When I first wrote Laravel, no, I had no
idea.
And that wasn't even the intention,
honestly.
The goal was to write my own SaaS using
Laravel and start my own business that
way.
And Laravel kind of turned into this meta
business.
But when I first wrote my first commercial
product, which was Laravel Forge, which
was kind of this deployment tool that you
could use to deploy your Laravel apps, I
wrote that and launched it in 2014.
And even in the weeks before it launched,
I was talking to my wife and I was like,
if it just pays our mortgage and our
bills, that'd be awesome.
And we can just have that money for fun
money and whatever.
But within a few weeks, I was actually
making more than I was making at
Userscape.
And soon I was making double what I was
making at Userscape within a couple of
months.
And then it was like, oh boy, this is a
real business at this point.
And that's basically when Ian was like,
look, you can't work here and run your own
full business at this scale.
OK, so we sort of transitioned me out of
userscape at the end of 2014.
But I mean, it was all of it was like a
surprise to me, honestly.
I guess I just underestimated how many
people were going to be interested in that
kind of thing.
And then once that was out, we just kind
of kept building more commercial products
around Laravel and went on to launch, you
know, four or five more things.
Do you ever talk publicly about the
revenue of those things?
I think I have a few times so like a
couple years ago.
I think I had I did a podcast series on my
own podcast of like Building Laravel to
like ten million dollars in sales as like
a solo founder and that was a few years
ago And I mean I think all time Laravel's
an ecosystem has passed like 30 million in
revenue or something like that That's the
commercial products built around open
source.
Yeah, the commercial products.
Yeah and Across all of them.
So we have five forage vapor on voyeur
Nova spark
And all together, I think they've passed
like 30 million lifetime revenue since
2014.
So pretty crazy, honestly, for like an old
source tool.
And we've also done conferences, but
conferences have always been a very
breakeven thing for us.
We've never made any significant money
running events like that.
Yeah.
But it fills the excitement bucket,
though.
Yeah.
That's the only reason it exists is to
just sort of build excitement and goodwill
like in the community.
Yeah.
So I went to the last Lericon, it was
great.
And like the excitement is real.
And like I was talking to some tuple users
there and that like filled me up with just
like that's the in -person interaction
with people that you normally like only
talk to through the internet is like, it's
amazing.
Yeah, I always come away from those events
like super energized, honestly.
And I didn't realize how big, how much I
was missing that during the COVID years.
But when we did our first Lericon since
COVID, which was actually like July of
this year,
I was like, wow, I actually really miss
this a lot.
So I'm glad we got back on that train.
And I'm actually I just signed the
contract for 2024 LaraCon today.
So we'll be we'll be back next year as
well.
Cool.
And so it seems like it sounds like you're
spending a lot of your time focused on
Laravel itself and less on the commercial
products now.
So have you have you freed yourself up
mostly from that?
From a coding perspective, yes.
So what I do is like at the beginning of
each month, I'll write up like a pitch of
all the things I think we should do on the
commercial products and kind of who I
think should work on them.
But honestly, like that, even that is sort
of flexible based on what the employees
are feeling like and what they have an
appetite for.
So I'll write up the high level product
pitches and maybe a few technical details
of like how I think maybe it could work.
But then they're sort of like free to go
implement those things as they see see fit
I mean they know the code base is better
than I do at this point like I actually
wrote every commercial product at Laravel
from start to finish in terms of the 1 .0
version that was initially launched to
customers So I did know the code base is
like top to bottom at one point but over
the years I've of course forgotten them
and now they know more than I do so they
do that and I mainly focus on the open
source stuff and
I mean, on a day -to -day basis, I'm
almost exclusively in our open source code
because I think the framework is sort of
the foundation and centerpiece of the
whole ecosystem.
So I'm really focused on making sure that
stays really well maintained.
And then are the other Laravel core team
members paid as well?
Are they employees of you?
Yeah, so we have 10 employees and they're
all full -time paid employees.
And we actually have two of them that are
really
It's pretty exclusively open source, full
time, salaried, open source people that
help me triage things, help me with the
release process, because we have a lot of
packages these days, and we do weekly
releases, help me with that whole process.
Just make sure things are like running
smoothly.
If there's a really gnarly bug that I
don't have bandwidth to really chase down,
like we have a guy that's just really good
at chasing down hard to find bugs that are
deep into the framework.
So they help with that.
And then the other programmers are
primarily on the commercial products seems
like such a huge advantage if you can make
it so that your Open source project can
have some sort of revenue stream attached
to it That then lets you hire people to
work on the open source project that feeds
the paid thing.
Just like a beautiful flywheel Yeah, I
mean it is a huge huge advantage and I
think there's like
only a few categories of open source
project that actually lend themselves to
this sort of model.
Unfortunately, I think there's so many
important libraries out there that just
never seem to lend themselves to
significant revenue.
But frameworks are definitely one of them
where it feels like you can kind of
leverage this model.
But there are some open source packages
like you have a Excel spreadsheet
manipulator.
package on GitHub.
And it just never seems those kinds of
packages just never seem important as they
are and widely used as they may be.
Never seem to make any significant
revenue, you know, unfortunately through
like donations or whatever.
And people ask me all the time, like, how
did you make open source sustainable?
And I don't feel like I actually made open
source sustainable.
You know, I just built commercial products
around an open source platform.
And to me, that's sort of a little bit of
a different thing than actually making
open source sustainable.
Right.
Right.
It's like open source.
Open source became sort of lead gen for
these paid products that plugged in
nicely.
Yeah.
I don't know very many people at all that
just like maintain open source and make a
couple hundred K a year on GitHub
sponsorships.
That seems like incredibly rare.
Right.
Yeah.
Totally.
Yeah.
Well, if I ever started open source tool,
that will be my goal.
It's something that could get that
flywheel going.
Because man, what?
What a huge advantage to like have all the
incentives aligned.
Like you just like, yeah, I want to hire
more people and pay them to work on this
thing that we happily give away for free
because that generates new customers who
can new potential customers for these paid
products over here that lets us hire more
programmers.
It's just, it's, that's great.
Yeah.
Yeah.
Yeah.
It's been nice.
Cool, man.
Awesome.
Well, thanks for sharing all this
programming wisdom.
That was a great chat.
Yeah, that was a, yeah, it was a fun
conversation.
Covered a lot of ground.
Yeah, we did.
I enjoyed it.
Cool.
Well, thanks.
Thanks.
Thanks for having me.
Yeah, take care.