At Tidelift, we have believed since day one that understanding, and supporting, the motivation of open source maintainers is critical to making open source work better for everyone. So we were very excited to see the Office of the National Cyber Director ask explicitly about maintainer motivation in its August Request For Information (RFI) on open source security. We've now submitted our response and wanted to share it with our readers here.
Readers of this blog know that Tidelift helps enterprises effectively manage the health and security of the open source software that powers essentially all modern software development. To do this, Tidelift partners with leading independent open source maintainers—and pays them—to ensure their projects follow secure development practices and document this important work.
- What can happen when maintainers work is not supported? (including maintainer burnout, which results in packages falling unmaintained—and becoming susceptible to security problems).
- What can happen when maintainer work is supported? (including maintainers spending more time working on important security and maintenance tasks, and improved security scores by independent measurements like the OpenSSF Scorecards).
Our RFI response also discusses how governments can be tempted to solve this challenge with unfunded mandates, like the one forthcoming from the EU. We explain why this is not just a mediocre idea, it's an actively bad one—likely to turn off the exact people our society needs to build a more robust, secure infrastructure.
Core challenge: mismatch of volunteer suppliers and enterprise users
The core challenge of securing the open source ecosystem is that the composition, and therefore the motivation, of this supply chain is unlike any other supply chain that is so critical to the global economy. This creates a mismatch between the expectations of enterprises at one end of the supply chain, and the motivations of the largely independent volunteer developers at the other end of the supply chain.
Volunteers dominate the open supply chain
Every other year, Tidelift conducts a survey to more deeply understand what motivates open source maintainers, what makes them thrive, and what stands in their way. In Tidelift’s latest survey, which came out in spring 2023, 60% of open source maintainers described themselves as unpaid hobbyists, while only 13% said they earn most or all of their income from maintaining open source projects.
Similarly, somewhere around half of open source maintainers do that critical maintenance work alone. In our survey, about 44% of maintainers said they were solo maintainers, and other studies report similar numbers (eg, 57% in this study of the most popular projects, and perhaps 93% in this study of Python).
Volunteers are different from traditional suppliers
Traditional supply chains have traditional motivations: a supplier provides a widget into the supply chain, and the next step in the chain pays for that widget. This incentivizes the widget supplier to (among other things) continue existing, so that it can charge for support, and so that it can sell more widgets in the future.
Open source software’s volunteer-centered supply chain has different motivations. These motivations can be extremely powerful, but the motivations necessary to continue to maintain that software for decades, in the face of demanding users and a hostile security environment, are different. Open source has had ongoing challenges as a result.
Volunteer “lifespan” is different: turnover and burnout
Burnout and turnover are real challenges in open source. In Tidelift’s recent maintainer survey, a majority of maintainers report either having quit or having considered quitting (58%). And these respondents are those who have quit and yet still stayed engaged enough to respond to surveys—suggesting that the actual numbers are probably worse.
Projects that are unmaintained are more likely to be insecure (along a variety of dimensions, including hijacking), so this burnout problem leads directly to security problems.
Volunteer interests are different: non-performance of security critical tasks
It’s important to say that many volunteer maintainers are interested in security, and we do not intend this to be a critique! However, many security practices are not well-aligned with maintainer motivations and resources. Here are some examples:
New processes: For maintainers who are already feeling overworked and underappreciated, the additional time commitment or hardware cost of a new process may be discouraging, and can even be the “last straw,” causing them to abandon their projects altogether. This is not hypothetical; one high-profile maintainer—when asked to turn on two-factor authentication—deleted hundreds of widely used projects.
New documentation: Developers are famously averse to “paperwork,” and so security attestations and similar requirements (like SBOMs) whose job is primarily to document the outputs of other, more interesting and rewarding tasks, are likely to be completely ignored by maintainers.
To put it another way: If security problems don’t align with the interests and time resources of the volunteer supply chain, adding more “requirements” is not likely to solve the problem—they will at best not respond, and at worst quit doing other maintenance activities!
The solution—and government's possible role
The impact of volunteerism on government and industry is that (1) deep, fundamental security work requires constant, consistent work and (2) uncompensated volunteers don’t typically get work done on a constant, consistent basis.
Not surprisingly given our experience, we argue in the RFI that focusing on maintainers, and paying them, could play to government strengths—like the government's strong ability to make long-term, far-sighted commitments.
After all, history has shown that solving the largest problems of society often requires government collaboration. We believe that securing the open source software supply chain that powers all technology is a critical societal issue that the U.S. government is in a unique position to positively impact.
Proposed policy approach: directly incentivize maintainers
Directly paying independent maintainers to ensure and attest to the secure software development practices followed for their projects is an approach with proven impact. Beginning in June of 2022, Tidelift undertook a focused project to incentivize open source maintainers to improve adoption of the OpenSSF Scorecard recommended practices, and overall scores. At the conclusion of this project, Tidelift’s paid cohort for this research was outperforming their previous scores from September 2021, as well as their peer open source packages.
Because of this work, Tidelift can now definitively measure investment, outcomes, and impact for open source software supply chain security—and it starts with paying independent maintainers.
Proposed next steps for the government
With that background, we suggest that the government could use a range of the tools at its disposal to encourage economic support of maintainers for the society-supporting work that they do. Among other things, the government could:
- Add attested SBOM requirements to legislative touchpoints that regulate software security or privacy, like HIPAA and SOX
- Include long-term support incentive schemes in relevant metrics, like the FITARA and FISMA scorecards
- Prioritize approaches that apply incentives to all steps in the supply chain, not just containerization or other end-product-focused approaches
- Experiment with Hack the Pentagon-style bounties for developers who need one-time incentives for big challenges
- Require testing with, and feedback from, independent maintainers on all government security standards
No one solution is likely to be perfect, or cover all of the many thousands of relevant open source projects used across the government and critical national infrastructure, so we would urge broad experimentation across a number of policy and funding vehicles.
— — — — — —
At Tidelift, we’ve found that open source developers are long on passion, but short on time. We hope our RFI response helps urge the federal government to use its unique purchasing and funding power to attack that problem using a proven tool: paying those volunteers to ensure, and attest to, the secure software development practices followed by their projects.
Want to read more of our thoughts on this subject? Download the full RFI response here.