or, “Holy shit, it works!”

Last May I left my job on the Go team at Google to experiment with more sustainable paths for open-source maintainers. I held on to my various maintainer hats (Go cryptography, transparency tooling, age, mkcert, yubikey-agent…), iterated on the model since September, and I’m happy to report that I am now a full-time independent open-source maintainer. That means I spend most of my time on maintenance, and I offer retainers to companies that benefit from my work and from access to my planning and my expertise. I now have six amazing clients, and I’m making an amount of money equivalent to my Google total compensation package,^[1] which proves the thesis that it’s possible to be a professional maintainer earning rates competitive with the adjacent market for senior software engineers.

For this first client cohort, I focused on companies that already understand open source, that work in fields adjacent to mine, and that I could reach through my network. My first client, who believed in the project before I even had a prospectus or contract tiers, is Glasklar Teknik AB, a new sister company to Mullvad VPN.^[2] Glasklar funds the development of Sigsum, an open-source public transparency log designed to produce offline-verifiable proofs, that came out of system transparency research by Mullvad. I’ve been working on Sigsum and on a framework and ecosystem of compatible and aligned open-source transparency tooling, and the collaboration has been great. In the order they joined, then came: Protocol Labs, who maintains IPFS and Filecoin, and whose R&D team produces excellent research on zero knowledge proofs and cryptography; Latacora, a retained security team for startups, who amongst other things makes resources such as myself available to their clients; the Interchain Foundation, themselves the stewards of the development of the open-source Cosmos SDK, a large critical Go+cryptography project; Smallstep, who provides easy-to-use PKI and Zero Trust tools (largely written in Go!) to manage human and machine identities; and Tailscale, a mesh VPN that feels like magic, with a passion for JSON, SQLite, and Go.^[3]

I’m sharing details about my progress to hopefully popularize the model, and eventually help other maintainers adopt it, although I’m not quite ready to recommend anyone else drop everything to try this just yet.

This experiment started from the observation that despite being critical for the functioning of the Internet—and, by extension, the economy—the role of open-source maintainer has not yet found a sustainable manifestation. Virtually all maintainers are either volunteers or full-time employees of large companies. Foundations on average don’t pay maintainers. A few projects manage to fundraise by selling support contracts or getting feature-scoped sponsorships.

All these models fail to align incentives with those of the project. Volunteerism is self-evidently not sustainable, as people’s life circumstances change.^[4] Full-time corporate employment scales poorly over time and especially when the project succeeds.^[5] Support contracts take significant time away from the actual maintenance work. Feature-scoped sponsorships reward increasing future maintenance burden without funding it.

What I’m doing is different, and I’m hoping it will be more sustainable, as well as reproducible for others. I am a professional full-time independent open-source maintainer. I’m funded through retainer agreements with a number of clients, and I get to focus primarily on maintenance work.

I’m not selling support hours or hard project deliverables. Instead, my clients get value in three ways:

1. they mitigate the business risk of a project they depend on going unmaintained, with its security and development velocity implications;
2. we establish a channel for reciprocal access, ensuring better outcomes for both them and the project; and
3. at the highest contract tiers, I’m available for advice on any topic I am an expert in, beyond the strict scope of the open-source project.

The business risk mitigation proposition is what every sponsorship offers, so it’s not at all innovative, but it’s important to forward-looking companies.

I’ve written before about the value of reciprocal access, but it boils down to this: I go in, meet the engineers, and learn what parts of my projects they use and how; then, I keep those use cases in mind in my own planning and I reach out and involve them for feedback when there are relevant changes on the roadmap. This improves outcomes for everyone: I want my projects to work well for users (regardless of whether they are paying me) and no one wants to find out something’s wrong after the release. Companies could get this “for free” by closely monitoring the issue tracker themselves and being active in development discussions, but dedicating an engineer to that task would probably be more expensive than my rate!

The expert advisor service at the top contract tier is a recent evolution of the model, based on conversations with Kaylyn Gibilterra, Kelsey Hightower, and others. I’m available to these clients for advice on all the topics I’ve become an expert in through my open-source maintenance years: cryptography, protocols, their implementations, Go, software supply chain security, open source, transparency logs, PKIs… The main concern I had attaching this to the offering was how reproducible it is: I know I can make a living as an advisor myself, but is it something that open-source maintainers can do reproducibly to financially sustain a main focus on project work? My hypothesis is that it is a great match for maintainers at large: maintainers are very legibly and recognizably experts in their field, because they maintain open-source software. If a company already uses my cryptography software, that’s probably the reason they believe I’m an expert in cryptography, and that they could use a cryptography advisor. It all correlates well, and would apply to any maintainer of a critical piece of open-source software: Kubernetes maintainers are orchestration and platform experts, ffmpeg maintainers are A/V experts, web server maintainers are HTTP experts. It also aligns incentives well with those of my projects: I’m an expert because I’m a maintainer, so it’s both in my clients’ and in my own interest for me to keep doing maintenance work.

I used a key word above: critical. The model I am experimenting with is geared towards the maintainers of critical open-source projects. In the metaphor of the XKCD comic you’ve all probably seen it’s meant to work for the projects at the bottom of the pile, maybe not for the ones at the very top. However, what’s critical depends on the client’s perspective, and many projects are critical for at least some businesses. This is how I frame it: if the effort required to replace or fork a dependency should it go unmaintained is measured in engineer-months, that’s a critical dependency and retaining its maintainers probably makes good business sense.

Concretely, I exclusively offer ongoing retainer agreements, without hourly billing or specific features as deliverables. There are three contract tiers: silver, gold, and platinum. Gold includes introductory and quarterly face to face meetings. Platinum includes the advisor services beyond the strict scope of my open-source projects. All tiers are in the five-figures range (USD, yearly). That’s significantly cheaper than an employee, but meaningful enough to contribute to a total that’s competitive with the US senior software engineer market.^[6] Every engagement is high touch and generally looks like a vendor relation, not like a GitHub Sponsors donation: I send a prospectus, work with a contact over a period of weeks to pitch to the decision makers and close the deal, we sign an agreement, and I provide monthly invoices to be paid by wire. As Patrick McKenzie would say, it’s shaped like enterprise sales.^[7] I hired an amazing part-time assistant who helps me stay on top of everything.

This is just the beginning, and I’m excited to explore how the model grows. Incentives are well aligned with the success of the open-source projects, as the more popular the projects are, the more companies will be interested in retainers, providing more resources to meet the increasing maintenance load. The workload also scales sub-linearly with the number of clients: for each additional client relationship I need to keep track of a new set of relevant interest areas and concerns, but managing multiple stakeholders is already a core skill of open-source maintainers, and the main task is still the day-to-day maintenance work which is shared across all clients. Platinum clients also have marginal cost in terms of providing dedicated advice, but again the bulk of the job is remaining an expert, and that doesn’t require extra effort for every new client. Of course, a lot of this is new and there isn’t much precedent to learn from, so I’m aware I’m probably off in some of my estimates and I am proceeding cautiously. After spending the past four months recruiting clients, I am now slowing down those efforts to learn more about capacity, bandwidth, and the marginal cost of additional clients. I’m still talking to a few prospects I would love to work with, and holding space for them in capacity planning. (If you’re interested, do reach out anyway and I’ll prioritize you as I resume onboarding new clients over time!)

Long term, I want this model to grow beyond me and become a known professional path. This experiment is both easier and harder for me than it will be for those after me: easier because I have an extensive personal network and the financial means to safely take risks; harder because it’s uncharted territory for both me and the clients and because there’s a lack of legal, administrative, and marketing tools. I hope that as things progress the barriers will lower, making the model accessible to more and more people.

I plan to write more about the model: how it went so far, how it’s proceeding, and how I imagine it growing in the future. I am not trying to build a unicorn or a platform to capture value myself, so I will share as much as I can to help others forge their own similar paths. If you don't already, subscribe to Maintainer Dispatches or follow me on Mastodon to stay up to date. Please reach out at [email protected] if you have suggestions, experiences, or questions; I read every email and I do my best to reply to as many as I can, although I am not yet set up to provide 1:1 guidance. In the meantime, I want to thank my clients for believing in this project, and I’m excited for some of the work on the horizon around Go 1.21 cryptography, transparency logs, age, and more!