I'm an independent open source maintainer
tl;dr - I’m independent, sponsor me!
I’m still focused on Rust, async, and HTTP stuff. Projects like hyper, reqwest, h3, tower, and any other new ideas that come along. I just won’t be doing so as an employee.
So, then how do I get paid? Let me just clear up a couple ways I’m not. I’m not making separate licenses. I’m not charging for features.2 I’m not selling prioritization on roadmaps. Rather, I plan to make maintenance work my primary focus.
Maintenance can feel like riding a squared unicycle while juggling water balloons. Some of those balloons are:3
- Designing proposals, interviewing users, re-writing those proposals.
- Coding, coding, coding.
- Triaging a never-ending supply of issues.
- Spelunking in ancient code paths to understand and fix weird bugs.
- Following a proper security policy with responsible disclosure, collaborating privately, and preparing detailed reports.
- Reviewing pull requests for quality and sticking to the vision, and hopefully teaching potential collaborators.
- Writing articles and giving talks, as a form of marketing and teaching.
- Pretending to be a project manager.
It’s a lot of work, so who would pay for all that?
Does your company depend on my work? Become a sponsor! Consider it a form of business risk mitigation. You can use GitHub Sponsors or Patreon. I can also work with an invoice system, for any requiring that.
I am also interested in some deeper relationships with companies that want more. What exactly those relationships will look like will evolve. It would likely be things that look like office hours, support or private advice. If you want to explore that with me, reach out at firstname.lastname@example.org.
I learned a lot from my 3 years at AWS. Many lessons, some anti-lessons. Overall, I’m very grateful for my time there. But I had been planning this change for a while. And it was quite refreshing taking off a few weeks before jumping back into it all. ↩
A win about being independent is that no single company is deciding what features should be added. ↩
This would be a good subject for another article. There’s a lot more to it, and it’d probably be surprising to people how many hats are needed to maintain popular open source libraries, besides “just being a programmer”. At least, if you want to do it well. ↩