Log4Shell highlights the need to proactively cooperate with open source maintainers at scale

Over the weekend, there was much ado on tech Twitter about the Log4Shell vulnerability and the reality of unpaid maintainers being asked to shoulder the load of keeping our entire infrastructure secure.

And weekends before that we had the same discussion around leftpad, and before that openssl, and many more we’ve already forgotten.

The good news here is that the industry is starting to recognize that volunteer, unpaid labor is no way to secure the global tech infrastructure. But the bad news is that the industry’s collective approach to fixing the problem might as well be described as “do a volunteer barn raising after the horse has bolted.” Or “Oh, these folks got hosed, let’s donate to them after they have done all the hard work.” (I’m told that in Russian the equivalent saying is “throwing a punch after the fight”—which feels even more apt after the body blows every security team felt this weekend.)

The current approach doesn’t work, and it is never going to work. Why?

• It isn’t proactive, relying on finding out after the fact. Besides the obvious failure mode (we want to find things out early!) it also ignores packages that are widely-used but not well-known—exactly like Log4j and leftpad.
• It burdens already taxed engineering teams, who have to identify recipient packages and figure out how to replace or upgrade them.
• It relies on either charity or semi-related employment, which doesn’t scale to the size of the problem. With charity, widely used but less widely known packages get missed and even the largest projects rarely have enough funding. With semi-related employment, bosses (or simply attention spans) can change priorities at any moment.
• It requires a lot of overhead, since setting up donations, contracts, etc., is a lot of work for both companies and recipients. 

So what might work better? At Tidelift, our approach to paying the maintainers directly addresses all of these issues:

• We work proactively with maintainers, ensuring they are being paid for important security, maintenance, and licensing work before there is an issue, not just after. And we have lots of exciting plans to scale this work (in alignment with new security initiatives), to make it even more protective.
• We don’t have to guess which projects need financial support, we see it directly because our payments are based on what our customers are using. This is why we were offering Log4j money already before this crisis and will automatically offer more money every time we onboard a new customer who uses Log4j.
• We provide a win-win for maintainers and enterprise users, where organizations get tools, data, and assurances around the open source components they use to build applications, and open source maintainers get paid to help us provide them. Tidelift isn’t charity—yes, our subscribers are paying the maintainers, but they also get a lot of value in exchange. This exchange of value allows for much greater scale and stronger long-term consistency vs. one off charity donations or post-horse-bolting funding.
• Tidelift simplifies working with open source projects into a unified, comprehensive process, allowing organizations to get help from the maintainers of thousands of projects, while minimizing overhead by letting us handle the boring stuff (like sales and legal) and setting the standard of service across projects and maintainers.

There’s so much room for optimism here and much good progress being made. Yet there is still a lot of hard work to do before we solve the problem and see every maintainer being adequately compensated for their work in a long-term, stable way.

If you’re interested in coming along for the ride, either as a customer or maintainer, get in touch! Ideally before the next weekend we all lose to a vulnerability.