Skip to content
GitHub Copilot is now available for free. Learn more
Photo of Caleb Porzio

Bringing simplicity, joy, and order to web development

Caleb on monetizing his craft and the value of transparency and sustainability in open source.

Caleb Porzio // @calebporzio

Hi, I’m Caleb. 🚶‍♂️I left my day job in January, 2019 to pursue open source. Since then, I’ve built Laravel Livewire, AlpineJS, and a bunch of other stuff. My mission is to make web development as productive and joyful as possible. That’s why I build and teach the things I do. That’s what drives me every day. 🙏 Oh, and I’m also severely addicted to fly fishing. 🎣

The ReadME Project amplifies the voices of the open source community: the maintainers, developers, and teams whose contributions move the world forward every day.

I grew up not knowing how much money my parents made because it was taboo to talk about income. So I had to learn a lot on my own, and money has been a stressor at every job. I don’t want to undervalue myself and ask for too little. But I also don’t want to ask for too much and seem greedy. If I do get the job, when do I ask for a raise? How much do I ask for? The cycle starts again.

Daniel Coulbourne, my co-host on our podcast No Plans to Merge, is all about transparency. We worked together at one point and he told me he made $15,000 more than I did at the time, and we did the exact same thing. So I met with our boss, asked for a raise, and got it. Now they have transparent salaries at the agency because it helps everybody.

I love openness. I love open companies, open startups, open source software, and salary transparency because it benefits the people at the margins. I have always talked freely about it, even when I didn’t make a lot of money as a freelancer, which made me a little insecure. But I know it’s important, regardless of how much you earn.

Before being accepted into GitHub Sponsors, I even shared how much I made on Twitter. I wanted potential sponsors to know their contributions really mattered, and I wanted fellow maintainers and developers to know they weren’t alone.

Photo of Caleb Porzio hiking in the woods.

If you build it, they will come

About two years ago, I quit my job because I needed a break and haven’t looked back. I started with backend code and PHP. Then I got into CodeIgniter, then Laravel. My apps were very Rails-like with back-end driven templates. Then I got into Vue.js and it felt so powerful and I could do so much on the front end. But after a while, I realized I missed some of the simplicity from my back-end days, and that’s how my open source journey began.

Initially, I started a proof of concept for Livewirein 2019 and it’s taken on a complete shape of its own. Livewire is awesome at building front-end interactivity without writing any JavaScript at all. It’s completely changed the way I write and think about web apps.

Despite needing to write much less JavaScript, I still needed to write some JavaScript. Mostly for little things like dropdowns and modals. Rather than pulling in a huge framework like VueJS or React for these little things, I wanted a framework that was modern and behaved similarly, but had a much more reasonable scope. Something like jQuery, but for the modern web. With all this in mind, Alpine was born. It’s my ode to simplicity. It gives the developer the power and expressiveness of data-driven JS templates, without all the overhead like needing a bundler or using a virtual DOM. It really struck people from day one.

After putting everything I had into building and marketing Livewire, I wanted to take a different approach with Alpine. A kind of “if you build it they will come” type of thing. It started out as ‘Project X’ because I didn’t want to name it prematurely. Despite my subtle and hands-off approach, people picked it up and really liked it. Adam Wathan, who wrote Tailwind, adopted it early and started hyping it. Then it really gained steam.

To me, both projects are two sides of the same coin. They both work together to create a development workflow void of slow bundle-steps, duplicated logic, and cumbersome test-suites.

Photo of Caleb Porzio working at his desk.

Feeling the weight of working for free

I kept focusing on making my open source projects bigger and more useful, and figured that at some point they would take care of me somehow. About 20 people asked me to join Patreon, but even if every one of them supported me, it would take much more to get to a critical mass. That just wasn’t where my community was spending their time.

I ended up signing up for GitHub Sponsors because I was already on the platform and it felt easy enough. I put a few sponsor tiers on there and got a handful of donations. But it was nowhere near anything that I could live off. Not even close.

The open source culture was completely new to me, and I had to learn as I went how to properly value myself. The experience of going from an open source consumer to an open source maintainer is profound. Before, you have the sense that yeah, maintainers put in all their work for free, but they’re famous. They have conferences. They’re these rockstar developers. Isn’t that payment enough?

When I started spending 100% of my time writing code for other people to use and make money on—and I didn’t make a dime—it really sunk in. It’s like working for free at the most poorly managed company ever where they open up your Asana or JIRA board to any and all customers. Issues and pull requests just flood in, never ending, and that weight can absolutely crush you.

As a result, so many projects inevitably fail. They’re unmaintained. Maybe they get forked, maybe they don’t. We end up with this endless graveyard of projects. And that story would be very different if being a full-time maintainer was sustainable, let alone lucrative. Some of the models that really work are at companies that fund open source projects, like Facebook with React. But that’s the exception, not the rule.

Recognizing that the value of code is code (not stickers)

Open source code may be free, but maintainers pay the cost. It requires time and effort, sometimes money. At the beginning, there’s all this excitement, but if it’s not sustainable, there’s a giant valley of despair full of self doubt, a pile of issues, and a stack of stickers to send.

I initially promised every GitHub Sponsor a sticker if they gave me $4 minimum. So I had all this work to do mailing stickers and I hated it. That experience reminded me that I already provide plenty of value in the projects themselves. There’s no need necessarily to go above and beyond with stickers (or other small perks) to justify a sponsorship. The value is already there.

Along those lines, I also realized I needed to change the messaging surrounding my sponsorship tiers. Instead of forcing potential sponsors to think, “How much money do I want to give Caleb every month,” I should make it easy for them to recognize how they benefit from my software. So instead of silver and gold and platinum tiers, I added personas: the individual, the freelancer, the developer, the agency, and the enterprise.

This little UI hack forces people to automatically ask themselves which category they fit into. No one’s obligated, but I want people to know what’s a fair expectation. You’re an agency? You could definitely afford to give me $250 a month. That’s one of your hours of labor, and I’m saving you much more than one hour with my code.

While I know the value I provide is in the code, I found that code alone is not enough to spur the majority of people to hit that “Sponsor” button. I started offering educational screencasts (on top of the free educational stuff I already put out) and that’s when everything changed in a big way. In a matter of months I went from $0/year to $100k/year with GitHub Sponsors! It’s been a dream come true ever since and I’m now able to devote ALL of my effort to open source. If you’re curious, I wrote about the entire journey in this blog post.

Photo of Caleb Porzio in his fishing gear.

The missing manual and the tragedy of the commons

As an open source maintainer, there are all of these ethical questions that come up on a minute-to-minute basis. Let’s say somebody submits a huge pull request you don’t need. If I pull it in, I’m pulling in code I don’t necessarily understand, and taking their word for it that it’s necessary. And then I have to maintain it forever. Or I can reject it and ruin their day. It’s tricky because I want to foster a community, but I don’t want to hurt the quality of the product.

My podcast with Daniel is called “No Plans to Merge” because we’d pour our heart into all these pull requests for a project that we both originally contributed to. After eagerly watching the PR for days, the maintainer would often say, “No plans to merge,” and close it. It’s kind of an inside joke now.

As a maintainer, you’re responsible for your messaging. I try to go the extra mile, but it’s not always feasible. My advice is to say no responsibly. There are a lot of unnecessarily rude maintainers. But you can be nice and courteous and still say no to new features and scope creep. It’s a tragedy of the commons. If you open up the repository to everybody’s whims, the project will suffer and people will stop liking it.

When it comes down to it, I love creating beautiful things and bringing order to all the chaos. I haven’t stopped coding since the day I quit my job, and it’s been absolutely huge and life-changing. I can’t even express how thankful I am. I want more people to have this opportunity, and for open source to be more sustainable for more maintainers who want to dedicate themselves to this full time.

GitHub Sponsors allows you to financially support the people who build and maintain the open source projects you depend on. One-hundred percent of your sponsorship goes toward helping Caleb maintain Laravel Livewire.
Support Caleb on GitHub Sponsors

About The
ReadME Project

Coding is usually seen as a solitary activity, but it’s actually the world’s largest community effort led by open source maintainers, contributors, and teams. These unsung heroes put in long hours to build software, fix issues, field questions, and manage communities.

The ReadME Project is part of GitHub’s ongoing effort to amplify the voices of the developer community. It’s an evolving space to engage with the community and explore the stories, challenges, technology, and culture that surround the world of open source.

Follow us:

Nominate a developer

Nominate inspiring developers and projects you think we should feature in The ReadME Project.

Support the community

Recognize developers working behind the scenes and help open source projects get the resources they need.

Thank you! for subscribing