larlet-fr-david-cache/cache/2022/acd4b5cdd3ebf13e74a102563aa90b9a/index.md

title: On Paying Open Source Maintainers
url: https://nadim.computer/posts/2021-12-12-maintainers.html
hash_url: acd4b5cdd3ebf13e74a102563aa90b9a


<span class="date">2021-12-12</span>
<p><img src="https://nadim.computer/res/img/maintainers.jpg" alt=""></p>

<p>I’ve been almost completely ignoring the recent <a href="https://www.zdnet.com/article/security-warning-new-zero-day-in-the-log4j-java-library-is-already-being-exploited/">Log4j security vulnerability story</a> simply because there’s nothing new in it: the story itself is the same old story. The discourse is the same old discourse. The hot takes are the same old hot takes.</p>

<p>One more interesting fork of the discussion has been regarding <a href="https://blog.filippo.io/professional-maintainers/">how to render open source projects more sustainable</a>. The article opens with a pretty strong and true lead:</p>

<blockquote>
<p><em>“Open Source software runs the Internet, and by extension the economy. This is an undisputed fact about reality in 2021. And yet, the role of Open Source maintainer has failed to mature from a hobby into a proper profession.”</em> <br><br>
<em>[…]</em> <br><br>
<em>“Volunteers are doing their best in their spare time out of passion, or because they are (or were) having fun. They feel tremendous responsibility, but ultimately can’t be expected to persevere in the face of burnout, a change in life circumstances (like, having a kid or changing jobs), or even shifting priorities. They also can’t be expected to provide professional levels of performance because, again, no one is paying them and they are well within their rights to do only the fun parts of the “job”.”</em></p>
</blockquote>

<p>The post goes on to suggest that open source projects should incorporate into LLCs (or similar) and start contracting with big companies depending on their projects.</p>

<p>What puzzled me about the post is that the above was framed as some kind of novel idea, whereas if you read it once or twice you may quickly realize that it’s basically the playbook that led to the creation of Red Hat Inc. and many other companies out there. In fact, the list of <em>“examples of what [companies] might want out of open source projects”</em> provided in the article is pretty much exactly what Red Hat Inc. has done as a company towards RHEL and by extension Fedora Linux for the past decade.</p>

<p>There is however a more novel aspect to the post, one which seems to be suggesting that maintainers also consider sending largely unsolicited invoices to big companies using their software and expecting those companies to <em>“assess, approve and pay them as a matter of routine”</em>.</p>

<p>This, to me, is puzzling, and turns the post into a combination of two things: the idea that open source projects incorporate into LLCs, which is tried and true but definitely not without serious costs and downsides, and the idea that open source projects make themselves “<em>legible</em>” to the invoice-processing departments of big companies so that they can begin to aggressively invoice them for <em>“support and sponsorship”</em> on letterhead.</p>

<h4>Here are the list of issues/questions that I have with that post:</h4>

<blockquote>
<p><em>“The trick is that you can easily incorporate a pass-through US LLC and open a business account for it even if you’re not a US citizen, it’s not rocket science. I am not an accountant but I did it in an afternoon.”</em></p>
</blockquote>

<p>I run two companies: <a href="https://capsule.social">one US-based startup</a> with VC investors, 14 employees, etc., and one <a href="https://symbolic.software">EU-based software consulting outfit</a> for my personal consulting projects and software publications. Both of them indeed took mere hours to set up.</p>

<p>But that is an incredibly reductionist metric by which to measure the time, effort and commitment it takes to go from an registered LLC to a structure that’s handily dealing with invoicing big companies, processing these invoices, handling financials, delivering on contractual promises at scale, hiring, dealing with incidental costs and responsibilities, the potential need for legal, and much, much more.</p>

<p><strong>Starting a company, anytime, anywhere, for virtually anything, is an extra set of commitments <em>on top</em> of being an open source maintainer. It is more like going from being engaged to being married to your project, rather than a free solution to balance maintainer responsibilities with new compensatory income.</strong></p>

<p>If you want to, as the blog post suggests, use the above to get into a position where <em>“eventually, a whole career path with an onramp for junior maintainers, including training, like a real profession”</em>, then that’s not something for which the difficulty can be accurately represented with how long it takes to set up an LLC. That’s something based on an entirely new set of commitments and responsibilities: corporate responsibilities. Fiscal responsibilities. Taxes. Hiring. Delegating. Planning a product roadmap — you have to pretty much go all the way. It’s not a fun solution. It’s, at best, building a tiny Red Hat.</p>

<p>There are some extremely lucky exceptions, such as what WireGuard has been able to accomplish through donations, grants, and adoption by private startups such as Tailscale. But that’s largely through a level of luck, goodwill and pretty insane level of privilege on the part of the project’s founder, who nevertheless worked on the project obsessively without the promise of revenue anyway for its first many years. WireGuard was also intelligently designed to avoid unnecessary overhead on the maintainer: it brilliantly eschewed even the possibility of needing to deal with dead weight such as backwards-compatibility due to its lightweight cryptographic design, or the need for WireGuard’s maintainer to bother with the questions resulting from composing WireGuard into larger systems and protocols (see the end of this post for how this could have also applied to Log4j.)</p>

<p>So, when the blog post says that <em>“now is the perfect time for Open Source maintainers to become legible to the big companies that depend on them—and that want to get more out of them—and send them five-to-six figure invoices.”</em> it’s actually saying something far more boring and predictable: that it’s time for open source projects to become “legible” to companies by… becoming companies.</p>

<blockquote>
<p><em>“The moment a company has a contractual relationship with a maintainer for a significant sum of money (1x to 0.3x of a market salary, depending on how likely the maintainer is to invoice other companies, too) it can request what it needs as a contractual condition […] (Or not, if they turn down the contract! I’m very specifically not talking about transferring governance.)”</em></p>
</blockquote>

<p>Right, except that the transferring of governance doesn’t occur in some apolitical vacuum, and is often pressured by financial and political considerations that evolve as a result of the growth of the open source project. This point seems to be ignored and reduced to <em>“oh, but they can just turn down the contract!”</em> — which isn’t reflective, sadly, of how the world works. The blog post seems to be somewhat pushing for open source projects into the trap of becoming the clients of much more powerful corporations (and in some cases, nation-states) and I’ve personally seen the disastrous consequences this can often have on software and research communities over and over again (stories for another time).</p>

<blockquote>
<p><em>“This is what I hope to see happen more and more: Open Source maintainers graduating to sophisticated counterparties who send invoices for “support and sponsorship” on letterhead.”</em></p>
</blockquote>

<p>This point was actually (in what became the top comment on the blog post’s HN submission) <a href="https://news.ycombinator.com/item?id=29524103">already touched upon by the president of VideoLAN</a> in a much more effective manner than anything I could myself provide:</p>

<blockquote>
<p><em>“Well, this is exactly what I’ve been doing around VideoLAN (VLC, x264) and FFmpeg for the last few years. In order to do that, I’ve created 2 official companies Videolabs and FFlabs (besides the non-profit orgs) and I’ve gone through all the hoops to get paid (PO, billing, invoices, registering to large companies is a lot of paperwork, tbh, but well..) and we try and bill small to large companies that depends on those projects.</em> <br><br>
<em>And FFmpeg and x264 are the core of the online video.</em> <br><br>
<em>So I did exactly what Filippo is saying we should do.</em> <br><br>
<em>But the result is really not impressive. Seriously, asking for money for support from those companies feels like we’re pulling the nails, even if their full business depends on it. Getting 30-50k$ from those companies for support for one year can be very challenging, long or leading to nowhere at all.</em></p>
</blockquote>

<p>Exactly — a main reason why big companies are employing open source software to begin with is because it saves costs. Companies are subject to obligations on the part of shareholders to keep expenses as low as possible, while startups are under even more onerous restrictions due to runway considerations.</p>

<p>I would find myself hard-pressed to genuinely have faith in this level of corporate generosity, unless I myself ended up being an exceptionally pampered employee at a big tech company for so long that I managed to confuse what is a well-calculated socio-economic retention mechanism towards high value employees, for genuine kindness and a propensity for good will towards open source projects.</p>

<p>Finally, there are also some inconvenient truths regarding Log4j, the particular open source project that inspired this discussion:</p>

<ul>
<li>First, like many other open source projects, Log4j is small enough to easily become in-house-replaceable the moment that companies start to feel pressured to spend money on it. Tangentially, Apple doesn’t sponsor Homebrew.</li>
<li>Second, the fact that you can also solve a lot of these problems by reducing your overhead as a maintainer, and not by increasing it:</li>
</ul>

<blockquote class="twitter-tweet tw-align-center" data-dnt="true"><p lang="en" dir="ltr">Apparently the maintainers of Log4j already agreed the underlying functionality was a ridiculous feature and wanted to remove it, but were held back by backwards compatibility requirements <br><br>if your engineers are telling you something old needs to go, it needs to go</p>&mdash; badidea 🪐 (@0xabad1dea) <a href="https://twitter.com/0xabad1dea/status/1469643409799499785">December 11, 2021</a></blockquote>

<p>All of this to say that, once more, reality is ultimately both more boring and more complicated. I wish it wasn’t: I’d love for it to be so easy and consequence-free to raise money as an open source project maintainer.</p>