Only maintainers can prevent software fires

Most software engineers who maintain an open-source-using application for their organization have a story of an epic software “fire” they’ll never forget. Maybe there was a critical zero-day vulnerability they had to patch in their infrastructure. Maybe there was a bug that brought down production. Maybe they realized they had a compromised package they had to deal with. A software fire, just like a real-life forest fire, can cause disastrous effects that take weeks, months, or even years to recover from. Feature work goes out the window; other deadlines are missed. All because something unexpected and dangerous happened, and they needed to fix it NOW.

Ask your developers if they would like to reduce software fires, and they’ll undoubtedly say yes. No one wants to be dropping everything to scramble and fix some newly discovered problems. But how do you reduce the number of software fires in your organization?

Many organizations think of open source software as a thing that just happens. If there’s some vulnerability reported on NIST, they go to NPM, or PyPI, and the internet will provide them with fixed new releases to install. But (at least until AI takes over the world) software just doesn’t appear—it needs to be written, and without maintainers that doesn’t happen. When urllib3 has a vulnerability, it doesn’t magically get fixed—maintainers like Seth Michael Larson have to come up with a fix, write tests, release a new version, and more.

The truth is, only maintainers can prevent software fires.

Let’s look at some examples.

In August of 2022, the maintainer of SockJS, a Javascript networking tool, decided he was done maintaining it and wanted to move on to other things. If he couldn’t find a replacement maintainer, SockJS would be end-of-lifed and no issues or discovered vulnerabilities would be fixed. The maintainer, Bryce Kahle, asked Tidelift for help. Tidelift worked with another maintainer, Asif Saif Uddin, who decided to pitch in to maintain SockJS. Its users now have continued support…because a maintainer stepped up.

Jackson-databind is an extremely popular java data-binding library; as a data processor, it can process a lot of potentially untrusted, arbitrary data. And processing untrusted, arbitrary data can lead to security risks; over a period of time jackson-databind suffered from multiple vulnerabilities. The maintainer, Tatu Saloranta, decided to fix these issues once and for all. Thanks to consistent funding from Tidelift, Tatu was able to undertake a security audit and re-architecture of jackson-databind, removing an entire class of vulnerabilities. Jackson-databind’s users have a more secure future…because a maintainer had the money and time to do the work.

You may have heard about the recent xz-utils backdoor. A persistent entity posed as “Jia Tan” and socially engineered an overworked maintainer to get access to help maintain the package, at which point they added a backdoor. However, another paid maintainer for a different software package, Andres Freund, noticed some side effects in xz’s use, and discovered the backdoor before it became widely spread. Hundreds, if not thousands, of organizations avoided having to do an emergency patching session…because a maintainer noticed something a little off.

But don’t take just a few examples for it. Tidelift surveyed hundreds of open source maintainers, and the results were clear. unless they are being paid to do the work, many of them will not take on the added responsibilities required to align their software to emerging government and industry standards. 38% of respondents say they don’t have time, and 37% said they wouldn’t do it unless paid to do so.

So back to your developers.

You want them to be able to concentrate on the features they need to build for your business to drive value. They don’t want to be distracted by software fires, whether that’s the things they use being end-of-lifed or abandoned, by vulnerabilities not being quickly fixed, or even by new and novel supply chain attacks.

There’s only one path forward: pay maintainers to prevent these software fires. 

At Tidelift, we help organizations prevent software fires by partnering with open source maintainers and paying them to:

• Implement industry-leading secure software development practices and validate the practices they follow so organizations can have the same confidence in the security of their open source that they have in their own code.
• Contractually commit to continue these practices into the future so that organizations can confidently make long term investments in the packages they use.

Want to learn more about how the Tidelift maintainer advantage leads to fewer software fires for your team? Talk to Tidelift today!