Luis Villa at TechCrunch Disrupt: Free but not cheap, the open source dilemma

Last week, Tidelift’s Luis Villa joined a TechCrunch Disrupt panel entitled “Free but Not Cheap: the Open Source Dilemma” alongside Aeva Black from the Cybersecurity and Infrastructure Security Agency (CISA) and Bogomil Balkansky from Sequoia Capital, moderated by Lorenzo Franceschi-Bicchierai from TechCrunch.

TL;DR of the conversation:

• The current model for ensuring the independently maintained open source projects most organizations rely on are secure is not sufficient and needs to be fixed.
• Volunteer open source maintainers shouldn’t be required to shoulder the burden of keeping projects secure without being compensated for the work. 
• End consumers also should not pay the price for the consequences of insecure products.
• Governments are getting involved and leading efforts to raise the security standard for open source.
• Organizations incorporating open source into their commercial products (open source integrators) WILL be expected to shoulder the burden of securing open source. 
• They should start paying attention because regulation to force the issue is on the way. 
• In the EU it is here already (through the recently passed Cyber Resilience Act and the Product Liability Directive) and the US likely won’t be far behind.

A few highlights:

According to Luis, at its heart, the open source security dilemma comes down to a very simple truth: the average open source project is backed by a solitary open source maintainer who in many cases is simply an unpaid volunteer.

“The median number of people who work on an open source project that your company consumes is one. It has always been one, and we have some data that suggests that maybe someday it will be two. But these projects with hundreds or thousands of paid developers are very much the outlier. And yet all of those pieces in the middle are vulnerabilities waiting to happen. This is not an indictment of those people—those people are all awesome and we should thank them whenever we meet them. But at the same time, that’s our reality.” 

Aeva looked at the problem from the perspective of the organizations consuming open source to build commercial products. If these organizations want to improve the security of their products, they must take the responsibility for better understanding the open source ingredients in them and how these ingredients are maintained and secured.

“If you don’t know what’s in the box, you can’t secure it, so it is your responsibility as builders to know what’s in the box. We need better tools, we need better engagement to enable everybody to do that with less effort and less burden on individual volunteer maintainers and non-profits.”

A lot of the discussion centered on why the government is now getting involved in open source security and the impact that will have on open source and its creators. As Luis said:

“One of the tensions in the current moment is that on the one hand, it’s great that we are getting government attention because this has been rightly pointed out that it is now a national security concern. The good news is that open source has been so successful that we have White House conferences about it. The bad news is that we have White House conferences for some very scary reasons and that kind of attention is going to bring pressure on open source that I don’t think our communities, and certainly not our solo maintainers, will handle just for the fun of it.”

As Aeva pointed out, the U.S. government has played a key role in setting standards for what secure software development practices might look like, and these standards are gaining traction:

“We’ve seen some uptick in open source foundations adopting the NIST Secure Software Development Framework as a guideline for how to securely do development of these projects and then share the artifacts that demonstrate they follow these best practices to everyone downstream from them.”

But expecting voluntary compliance with recommended standards may not be enough on its own without some regulatory teeth. Luis talked about some of the regulations recently adopted in the EU that will potentially increase liability for organizations using open source software that do not follow secure software development practices.

“The EU has already answered this question definitively. Those regulations are coming. The Product Liability Directive and the Cyber Resilience Act were both adopted on October 12. So by mid 2026 and mid 2027 for the PLD and the CRA respectively, software is going to be impacted by product liability rules. So if your software has anything to do with consumer safety, for example if you are a car manufacturer, the software in your car is now going to be treated in the EU as a product liability issue just like any of the rest of your car. The very bottom line is that both the PLD and the CRA have carve outs for open source but nevertheless some of those things are going to inevitably flow down. Some of that will be very hard to do without maintainers, so how that is going to scale is going to be interesting.”

As Bogomil from Sequoia shared, organizations using open source software in their products will need to adapt to this new reality and take responsibility for the security of their software supply chain.

“Through regulation and market expectations I think the integrators of open source now have a powerful incentive to secure their consumption or their integration of open source because at the end of the day they’ll be the ones responsible for the holistic security of their products.”

“These integrators face a relatively simple economic dilemma. Either spend the money and resources to fix vulnerabilities in whatever open source I am consuming or I channel money, resources, and or time to help the upstream maintainers of open source to do it for me. There’s only two ways to do this, either you can do it yourself, or you help the creators or maintainers to do it. I think we’ll see a mixture of both.”

Finally, Aeva painted a picture of what the future could look like when organizations take accountability for the health and security of the open source software they consume.

“Just imagine if every company who is using open source software, whether a federal contractor or not, chose to be responsible about how they consume it. To ensure their own longevity, they contribute back to make sure the project is healthy, to stay involved and stay ahead of CVEs when they come out, and to ensure that their business a year, two years, or five years from now isn’t depending on a project that’s no longer maintained because the maintainer won the lottery or threw their computer in a lake. Staying involved is how you maintain your product in the long term.”

If you found those highlights interesting, you’ll enjoy watching the full session on YouTube.