Taylor has built his career around Laravel and has a wealth of knowledge and wisdom regarding not just Open Source software development, but entrepreneurship and community building.
I'm an Open Source maintainer, and I'd love to make it a more significant part of my career path. Therefore, I paid particular attention to the things Taylor learned while building Laravel.
I've tried to condense some of Taylor's thoughts regarding Open Source in this article. There is undoubtedly a ton of things I missed, so please listen while you read:
Taylor built Laravel as a platform to launch his own products. He was seeking freedom in his work-life and saw entrepreneurship as an avenue to achieve that freedom.
Laravel was intended to be a tool that allowed Taylor to pursue his entrepreneurial goals more efficiently.
That intention was valuable for Taylor because it informed his decisions before he had stakeholders to give him feedback. Taylor used the dogfooding metaphor -- in which a creator can build an early feedback loop for a given product by using it themselves.
The idea that you can provide early feedback to your own Open Source project is the fuel for the phrase, "scratch your own itch." If you're building something that you use, you're more likely to make informed decisions during the initial stages.
However, as Dave Thomas warned me, you might eventually lose interest in your project if you can't find others who want to it. Which leads us to adoption.
One of the things that I found striking about Laravel was the volume and quality of content regarding the framework. From my own experience in Open Source, I have suspected that documentation drives adoption, but Taylor confirmed this for me.
To this day, Taylor writes most of the Laravel documentation. However, there are some really cool community-driven efforts, like Laracasts, to provide high-quality content on Laravel.
When you build Open Source projects, regardless of size, it's important to write some documentation. You can't expect anyone to navigate or use your product without some guidance. If adoption matters to you, write some docs!
A big fear for aspiring Open Source developers is rejection. I've seen this when mentoring other engineers and reviewing Pull Requests on Solidus.
Taylor spoke about some of those experiences in the Laravel project, even with a widely-adopted and loved project he still encounters critics routinely.
In his career, Taylor has run the gamut of emotional responses to unpleasant feedback: from discouragement to anger. Ultimately, he told me that there will always be critics, and it's never pleasant when someone dislikes your work.
Luckily, I've found that in Open Source for every unpleasant troll there are a non-trivial number of silently satisfied users.
In my experience, there is also an incredible amount of misunderstanding in the Open Source world. Primarily, because we tend to communicate over text.
To combat this pattern of misunderstanding, I was given some advice that radically changed how I read any text-based communication: Always assume people have the best intentions.
It's easy to read feedback and become defensive, but sometimes our interpretation of the voice behind that feedback is entirely off-base. Sometimes feedback may sound harsh, and it's actually intended to be helpful or friendly, but those good intentions didn't translate.
Eventually, however, you're going to encounter real critics and unpleasant people. All you can do is take feedback when it is offered and stay focused on building cool things for your core users.
A big part of Open Source software is community building. People get involved with projects because there is a community of like-minded behind the project. That community makes it easier to adopt tools and solve problems when they arise.
As an Open Source maintainer, Taylor found that making himself available to his early adopters helped to get people involved in the project; growing the community.
This is useful advice for both maintainers and contributors, being approachable means you will hear more about how a project is being used and can be improved. Not to mention, you'll have a lot more professional opportunities.
For Taylor, being approachable meant attending events and participating in discussions about Laravel. It had the added benefit of enabling him to travel the world and meet tons of interesting people.
While it's essential to build an online community for Open Source projects, Taylor and I talked about another important piece of his journey developing Laravel.
As it happens, Taylor and I both live in Arkansas, a state in the US not known for its tech scene. While we have some hugely successful businesses, tech jobs haven't been a big part of the state's economy until recently.
I was interested to hear how that geography had impacted Taylor's career in Open Source.
Interestingly, he found it was actually an advantage. Because there aren't constant meetups or conferences in Arkansas, it can be easier to focus on building something great. Taylor feels that he can go heads-down on Laravel more frequently than he might if he lived in a tech hub.
However, there are significant benefits in living near other technologists. Building a local community can be extremely important for your career and the quality of the software you produce. For instance, Taylor said he wished he had more opportunities to pair program with other developers.
If you're working in isolation, you probably aren't going to produce your best work. So, it's valuable to invest in building some kind of community around your work, and there are some real benefits to having shared geography with your colleagues.
Building businesses was a huge part of Taylor's motivation for Laravel. That being said, it took serious time before Taylor made any meaningful income from the project.
In fact, we spent the end of our conversation, discussing how he eventually was able to make money. Largely from products which he built for the Laravel community long after it had become a resoundingly successful Open Source framework.
Open Source can be lucrative (I've made some money from my Open Source work), but frequently, it is a longtail investment.
Throughout the interview, Taylor shared some precious wisdom regarding his career and building business as a developer, but you'll have to listen to the interview to hear most of that stuff. Because I'm so interested in Open Source, I wanted this article to focus on the actionable advice Taylor had for people looking to maintain or contribute to Open Source.
I am grateful to have met someone who has built such a successful career around Open Source software. I hope others benefit from my good fortune through the recording! Thanks for reading 🤠
If you're interested in learning from veteran engineers like Taylor, subscribe to my newsletter and follow along with the podcast. I have upcoming interviews with engineers all around the world who have built amazing careers for themselves.