<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=705633339897683&amp;ev=PageView&amp;noscript=1">

Not all open source work is equal

Hynek Schlawack
by Hynek Schlawack
on October 24, 2023

Updated on January 3, 2024

Don't miss the latest from Tidelift

We regularly feature posts from our maintainer partners. In this case, we asked Python maintainer Hynek Schlawack to share his thoughts on how being compensated for his work has helped him carve out more time to work on the open source projects he maintains.

Open source maintainers like me publish our projects because we have something to share with the world, something that will make at least someone else's life better. Suppose we have the good (or bad) fortune of success with the project; a slew of new tasks land on our shoulders: community management, enforcing codes of conduct, and so forth.

Maintenance and keeping users safe

As someone who has always cared a lot about security, drove the improvements of SSL/TLS in the Python community, and was a founding member of the Python Cryptography Authority (PyCA), I see it as my responsibility to keep my users safe.

I've always been a big advocate of using type-safe languages, using two-factor authentication (2FA) (or eliminating the possibility of leaking credentials in the first place—for example, by using Trusted Publisher PyPI uploads), secure TLS configurations, et cetera. I have written and given conference talks about all these topics and published tools to make it easier for other maintainers. Multiple important Python projects use my tools and workflows, filling me with pride.

One big reason I am motivated enough to spend my weekends doing and advocating for these invisible, unglamorous topics is my income from Tidelift, whose specific purpose is to support me in maintaining my software.

That makes a lot of sense because programmers usually don't need a lot of motivation to write new code—it's the maintenance of the existing one, together with keeping up with the current packaging and language standards, that is the draining part. To the uninitiated, it can be surprising how much work it is to keep a project in good shape over the years, even if it's largely feature-complete.

I've also had the excellent fortune of being part of Tidelift's project to adopt OpenSSF Scorecard practices, where they paid me to improve the security of my attrs package for a whole year. Of course, while the payment was for only one project, I've applied everything I've learned to my other projects—particularly security-sensitive ones like the password hasher argon2-cffi.

It was a great way to experiment with security features (don't tell Tidelift, but I applied most of them beforehand!) and discuss the features and their efficacy with other maintainers. I wish more companies would spend resources on working with maintainers instead of dropping new expectations on us Ex Cathedra.

The rise of the supply chain

One particular expectation grew lately (and louder) under the moniker of supply chain security—a term that made some maintainers bristle so hard they deleted their projects in protest.

Corporations now feel entitled to enterprise-grade security without paying for it. As generous as the tools and documentation from Google are, concepts like Supply chain Layers for Software Artifacts (SLSA), Software Bills of Materials (SBOM), or sigstore signatures are new burdens on generally already overloaded maintainers who just wanted to share some code, and, crucially, that are only interesting to corporations and downstream packagers.

Remember when I mentioned how much work it is to keep a project in shape? This adds a bunch of new moving parts to project maintenance that will change and that will break over time, adding more headaches.

For me, this is where the puck stops. I don't begrudge anyone applying these new concepts to their projects—they're fancy new toys, after all!

But unless something systematically changes, I'm not playing along. I will not spend my weekends so S&P 500 companies can hire fewer people to ensure supply chain security. I will not work my evenings to make the life of commercial Linux distributions easier.

A way forward

I won't make the tired argument that companies who use open source software should give back. The upsides of motivating and appreciating project maintainers are too abstract for a corporate spreadsheet. It's also unlikely people will stop writing open source software pro bono—we've written software before money was even on the table, and not every project lends itself to gate features to paying sponsors. 

However, the quality and security of project maintenance are tangible. This time, the roles are reversed: We don't want to share something with the world—(parts of) the world want us to provide a service to them we have no interest in doing for our own reasons.

Time and time again we've seen what paying people to do things they don't want to do otherwise can achieve. I don't see why it should be different this time.

But it will take people who claim to care about the supply chain to put money where their mouth is.


For most of us, that motivation is money. Over at GitHub Sponsors, I've set the minimum amount to motivate me enough to deal with this to $2,000 per month. Given that sponsorships lately went down instead of up, it looks like supply-chain security is not that important after all.

Corporations wanting enterprise-grade supply chain security can't expect it for free. They will have to choose between doing it internally or paying maintainers to do it for them.

Tidelift 2023 open source maintainer impact report