This blog post was originally published on our Tidelift community page.

Some of you may have seen that open source has been in the news coming out of Washington, DC lately, with open source security in particular getting increasing attention from the White House and (two weeks ago) the US Senate.

In this post, I’m going to try to briefly run down what this news means for maintainers.

Why is this happening?

After Log4Shell and SolarWinds software supply chain vulnerabilities, the US Government has begun to grapple with the fact  that it is one of the world’s biggest consumers of software. And because much of modern software development relies on open source, this also means it is a huge user of open source software. These two things: being one of biggest users of software + one of biggest users of open source software means that it is a big target for hackers. So it’s been rapidly trying to figure out what it should do to protect its software infrastructure.

What’s the focus, so far?

To date, the primary thrust of the various US Government activities has been understanding the scope and scale of this problem. You can see this, for example, in a recent White House memo, which calls for (within 180 days!) a creation of a registry of what open source is being used within the government. Similarly, the recent US Senate bill is very focused on creating standards to help understand how secure (or insecure) the most important software is.

What’s not the focus, so far?

No one, yet, is talking about imposing specific solutions, or forcing open source developers to do anything. The NIST is not going to be calling you up and telling you to enable two-factor auth, and the CIA is not going to demand you use Rust. So don’t lose sleep over that. But we should be clear: governments often gather data as the first steps towards creating regulation. So it’s incumbent on us not to panic, but also to get this data gathering right as early as possible, before regulations are drafted.

What’s good here?

I think there are a few very important and positive things here, even if you’re skeptical of the current state of the US government:

• The US government is getting real about security: Software (not just open source!) really does have a security problem; we have often traded off security for convenience or efficiency. The best time for that discussion was twenty years ago and the second-best time for it is now.
• The US government is getting real about resourcing: Open source software in particular really does have a resourcing problem—the non-profit package managers, for example, have limited resources to improve their own security scanning or other metadata. Bringing federal government resources to bear may help, especially in areas that traditionally have free-rider or collective action problems. Solving those sorts of problems is literally what government is for! 

This is only two bullet points, so this seems like a short list of “good”, but each of these are huge for the future of open source. So please take my concerns, below, in this extremely positive context.

What concerns are there?

While overall I’m optimistic about this activity, I have a few concerns. In particular:

• Is the problem open software, or all software? The recent US Senate bill talks about the problems “unique to open source” but then prescribes standards that should apply to all software, like use of multi-factor auth and memory-safe language by developers. It would be a very bad outcome if open source is held to a higher standard than proprietary software—these efforts should be careful to distinguish between the deep problems of all software, and those problems specific to open source.
• Tradeoff of speed and flexibility/nuance: The government is moving quickly here, as it probably should, but it must do that while retaining flexibility to adapt as the underlying open source communities evolve. It must also avoid a one-size-fits-all approach, since different communities of practice have different security requirements and practices, often well-adapted to their languages and use cases. A government (or business!) policy that doesn’t recognize those nuances will fail to improve security.
• Balance of spending: Traditional open source security techniques have emphasized scanning tools, and often not emphasized supporting developers to fix the issues uncovered by those tools. The US Government is in a unique position to fund a transition from “find the problems” to “find and remedy the problems”! There are promising signs of this, but more awareness needs to be built and the open source community can help.
• Listening to communities: The recent US Senate bill is very specific that communities should be consulted, which is great, but it should specifically call out the important and unique role of 501(c)3 (public benefit) non-profits in our space. I hope those organizations can step up in this important moment (and I’m particularly proud that Tidelift partners with several of them!)

It’s worth noting that all of these have clear paths for improvement! So work needs to be done. But it can be done.

What about other governments?

Since maintainers (and Tidelift-partnered lifters) are all over the world, this is a very fair question! I’ll be writing more about this soon—there’s definitely work underway that we’re keeping an eye on, including EU announcements last year on supply chains and last week on software liability.

What is Tidelift doing?

We’re doing a couple of things.

• Monitoring: We’re keeping an eye on, well, everything. And trying to write about it as much as we can! Here, for example, is a recent post I wrote about the new proposed legislation making its way around the US Senate. And here is one our CEO Donald Fischer wrote about the new Office of Management and Budget guidance for organizations building applications with open source.
• Advising: Last year, we filed a response to a US Department of Commerce request for comment, pointing out that uptake will be slow if maintainers aren’t compensated. We will continue to look for opportunities to present the interests of maintainers, both formally and informally.
• Standards-building: To their credit, the US government does seem dedicated to learning from work the open source community has already done. So we are working hard with our maintainer partners to adopt and improve these industry standards, making them a better basis for future government action. In particular, we are working directly with maintainers to validate which of the new proposed industry standards will have the most direct and immediate impact on improving open source software security and resilience, and paying  maintainers to implement these standards first. If you’re already a Tidelift maintainer partner and want to participate, keep an eye out for more details on that; if you’re not, apply now!

What can you do?

I hate to ask maintainers to do more work, but there are a few things that might be helpful.

• Contact your 501(c)3s: If you’re a member of a software community 501(c)3, reach out to them about this and ask what they’re doing. Obviously they’re all stretched thin—but they need to have an eye on these new government initiatives.
• Give feedback on new security standards: The various security standards like OpenSSF Scorecard and SLSA.dev can be a lot to digest, but they are likely going to be very influential in developing government standards. Take a peek at them, and if you have concerns or questions, file issues. The people behind them want to hear from a broader range of maintainers, so your feedback really does matter. (If you’re a Tidelift maintainer partner, you can also bring the feedback to us—we are participating in these discussions, and may be able to either point to existing discussions, explain them more deeply, or bring your feedback to the appropriate places.)
• Sign up to be a lifter with Tidelift: Feels corny to end this with a pitch for my company, but we’re working hard to support maintainers in a variety of ways. We call our maintainer partners “lifters,” and we would love you to join us, if you haven’t already. Help us build a coalition of like-minded maintainers who want to build a people-oriented, financially-sustainable open source model  that works better for everyone.