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.
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.
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.
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.
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.