In late 2022, Tidelift fielded its second survey of open source maintainers. Hundreds of maintainers responded with thoughts about getting paid for their work, the security and maintenance practices they have in place for their projects, and where they need help most, along with a host of other interesting insights. In this post, we share the fifth of eleven key findings. If you don’t want to wait for the rest of the results, you can download the full survey report right now.

In our previous headlines, we shared some data about emerging industry standards initiatives like the NIST Secure Development Framework, SLSA, and Open SSF Scorecards, including the percentage of maintainers who were aware of these standards and whether they were planning on aligning to any or all of them.

We also wanted to dive deeper to understand exactly which security and maintenance practices maintainers have already implemented for their projects, and which they plan to implement in the future. We anticipated that this data might be interesting for organizations to see so that they can compare the security and maintenance practices followed by maintainers whose packages are being used in their applications to their organization’s own security and maintenance standards and expectations.

First, we provided maintainers with a list of some of the most important security and maintenance practices we are partnering with maintainers to validate at Tidelift, and asked them to tell us which of these practices have been implemented for most or all of the projects they maintain.

Of this list, far and away the most commonly implemented practice, with 86% of maintainers choosing it, was having a clearly documented open source license. Almost two-thirds of maintainers currently provide documented release notes and upgrade considerations (63%) or a published contributor guide (62%), the two practices that were next most commonly implemented.

We then showed our respondents a list of the practices they reported have not yet been implemented for most or all of their projects, and asked them to tell us which of them they planned to implement in the future. We combined these two data points together to get a comprehensive look at which standards and practices are either already in place or on the roadmap to be put in place in the future by maintainers.

All four of the top answers relate to documentation practices. Ninety-two percent of maintainers have either already or have plans to clearly document their open source license. Next on the list is publishing a contributor guide, which 85% of maintainers have already implemented or have plans to implement, followed by documenting release notes or upgrade considerations (78%) and publishing a code of conduct (78%).

The next set of answers all relate to security or maintenance practices, including reproducible and verifiable build processes (70%), two-factor authentication (69%), a security disclosure plan (64%), and fixes and recommendations for vulnerabilities (64%).

Finally, we broke down the percentage of maintainers who had already implemented or had plans to implement each of these practices by unpaid (hobbyist) and paid maintainers (semiprofessional or professional)—and the results were startling.

Across every practice we asked about, paid maintainers were significantly more likely to have implemented it or have it on the roadmap. More than 50% of paid maintainers had implemented or had plans to implement twelve of the practices on this list (with only four not making the cut) while 50% of unpaid maintainers have implemented or plan to implement only five!

Particularly interesting were the stark differences between paid and unpaid maintainers on some important practices like having reproducible and verifiable build processes (47% unpaid, 77% for paid), providing fixes and recommendations for vulnerabilities (43% unpaid, 69% paid), security disclosure plan (42% unpaid, 69% paid), formal backwards compatibility policy (39% unpaid, 71% paid), defined dependency management process (26% unpaid, 57% paid), and published release schedule (15% unpaid, 41% paid).

Which leads to an obvious conclusion: when maintainers are paid, they have the time and motivation to more completely address common security and maintenance practices than when they are not paid.

If your organization is using open source in your applications, how does this data make you feel? Did you see most of the security practices you’d be expecting maintainers to have in place at the top of the list? Are there things on this list you’d expect to have been implemented for any open source package you use? And finally, looking at the differences between what paid and unpaid maintainers are able to do when it comes to security practices, what investments are you making to ensure the maintainers behind the open source components you use have the time and incentives to complete this important work?

We hope you found some useful and actionable information in this blog post. If you’d like to get notified as future posts come out, please give us a follow. Or if you don’t want to wait, download the full survey results today and RSVP for the webinar on Thursday, May 18 at 3 p.m. ET, where we’ll be unveiling the top findings from the survey.