Why Open Source Matters for Institutional Adoption

Transcript

[applause] >> Great. Thanks for coming. Uh let's get started. So today I'm going to talk about open source software and institutional adoption with lessons learned from the Linux Foundation. So what am I going to cover? I'm going to talk a little bit about some open source background in the Linux Foundation mainly so I can convince you to care about my opinion. I'm going to talk about some open source table stakes for institutions like software licensing, IP protections, best security practices, and then finally I'm going to talk a little bit about open governance and communities.

Uh usual disclaimer applies. So let's get started. Um there's a really big perception particularly in the blockchain community that open source is Cypherpunk, right? We have uh Vitalik's blog where he's talking about you know, make Ethereum Cypherpunk again and uh if you've read the Ethereum Foundation mandate, right? It's it's really big about open source. But it turns out open source is just everywhere. So even in a typical closed source enterprise code base, 90% of a modern application's code base is open source. And if you're interested in these exact facts and figures, we have them all on the uh Linux Foundation research website. Definitely check them all out.

And maybe some of you are builders and you build like this. Um but when people typically build all applications, they start with an open source framework, they write a little bit of custom code to connect everything, and they use open source libraries to solve problems. We sort of refer to this as the open source hamburger. Um and why do they do this? Well, there's tremendous value in open source uh to enterprises. And I'm not going to read through all of this, but I hope I can convince you that enterprises see a ton of value in open source and working in open source.

And how does this work? Well, there's sort of a virtuous cycle or flywheel around open source software. There are open source projects uh and these are used to build commercial products that get put into production use. You know, these make money for people and then some of those profits are put back into the projects. So, this is kind of a a useful or virtuous cycle around open source software development. Um but this is especially powerful or amplified when there's truly an open source community that forms around a project. And so, right here I've got the breakdown of Kubernetes, which is a Linux Foundation project. Um the

contributions by company and sort of the big blob is Google on the bottom. Uh and you can see, you know, over time they've become sort of a a smaller share of the overall contributions, even though their absolute number of contributions has not decreased over time. But this has enabled them to build a big community around Kubernetes and it's one of the reasons why Kubernetes is so ubiquitous today. Um and this is where the Linux Foundation exists and this is why we exist. It's to solve collaboration for open source code.

Uh when multiple companies or individuals want to collaborate on open source software, but they don't trust one single party to own the code, this is the problem that the Linux Foundation solves. And it's always great talking to blockchain folks about this because they really understand the benefits of decentralization. I don't want this to be an LF infomercial, uh but I do want to just give you some of the breadth of the Linux Foundation. Uh so, hopefully you'll take my opinion on open source matters, you know, seriously. We have a ton of projects, you know, maybe some things you didn't know that were in the Linux Foundation, like RISC-V, I mentioned Kubernetes,

you know, very interesting things like the Academy Software Foundation, which does the animation for Hollywood movies. We're a huge organization. I'm just going to put up some numbers up here. Um you know, lots and lots of code, developers ecosystems. You know, and I I just want to show you this. So, when I say, you know, we've seen something um we have the numbers to back it up. And why am I here today? Well, we actually have a lot of Ethereum projects or Ethereum-related projects at the Linux Foundation. So, have people here I assume are familiar with Besu or they've used Besu?

You know, it's something like uh 15 to 20% of mainnet probably. Um a bunch of tools uh and uh you know, things that are very tied to the EVM like uh Lineth and Hyperledger. Um So, the point I want to make right now is that institutions already know and trust open source software, but you have to make them happy if you want them to use it. Um and particularly in the blockchain space, following best open source software practices can make it much easier to gain adoption. So, let's get started with that. So, one thing I want to start with is uh just some table stakes items. Like, what do you need to do right if you want institutions to use your code or use your software?

So, let's take a step back. Let's define what open source software is, right? The important thing right now in this definition is it's released under a license, right? And this is just a legal document that uh records and formally expresses a set of acts around the software. Who here loves software licensing? Nobody, exactly. Nobody likes this. Um but, you know, you have to deal with it if you want your project to get used correctly. There are three main types of open source licenses. There's a BSL license, a copyleft license, uh and a permissive license. Maybe you've you've heard of some of these.

Um, I'll go through them quickly here. So, a BSL license is technically not an open source license. It's a source available license. Um, the code is public, but the use is legally limited, right? It's essentially, uh well, you know, proprietary software, but people can verify your code. Um, and example projects in this space that you may know of are things like Arbitrum Nitro. Um, this is, you know, useful when you want to do proprietary software, um but, you know, there are a lot of caveats. Certainly, we don't accept BSL license code, um and other organizations don't necessarily like it, either.

Um, copyleft licenses. These are licenses that require users to make available all derivative works. Um, so if you modify the code and you use it in something else, you have to make the whole source of that something else available for free. Um, this, you know, has great principles, but it's just very hard to use commercially because companies are worried that, you know, if if they use GPL code somewhere, it'll get reused somewhere else, and all of a sudden they'll have to make every line of code they've ever written public. Um so the goal is sort of, you know, to increase contributions back to the code base from users by legally requiring them. Uh, the unfortunate

reality is kind of people just don't use your code if there any viable alternatives due to legal requirements. Um, and I'll say it's very hard to relicense things. Uh, the OpenSSL relicensing is a a famous instance of this. And finally, there are permissive licenses. When you think of open source and you can do whatever you want with the code, this is really what a permissive license captures. Um we recommend this uh if you want others to use your code because it's by far the easiest to use. Companies are happy with it, uh particularly if you use Apache 2.

So, we default to permissive licensing in the Linux Foundation. Um a couple of common pitfalls that I'll fall I'll I'll hopefully I won't fall in them. I'll go briefly through. Um be careful with your dependencies. We see a lot of people uh not correctly understand or use an LGPL dependency. Watch out for that. Um and uh be very careful with licenses that don't have IP protections. So, one of the reasons we recommend Apache 2 for projects is because it has explicit patent grants. And some of the other permissive licenses don't, so we encourage you to be careful. Um so, again, just a summary, uh if if you're,

you know, mostly looking at your phone, uh please pay attention to the licensing requirements and we recommend you default to Apache 2. Awesome. Um and I'll just point out what the uh Ethereum Foundation mandate is on this. Um they also support, you know, copyleft licensing, um but we've just generally found that it's very hard to get institutions to use copyleft licensed open source. Awesome. So, what about other legal and IP protections? I've alluded to this. Uh well, contributors to open source software may unintentionally or maliciously add code that has some form of IP protection.

Um this is something that really worries institutions. They're always worried about patent lawsuits. Um and uh this is not a hypothetical thing at the Linux Foundation. If you want to read more, there's a a whole series of lawsuits uh that erupted around this. Um and it resulted in us building what we call the developer certificate of origin or the DCO. Um whether you use a DCO or a CLA, it's important to have appropriate legal frameworks around your code to deal with these kind of IP restrictions. And I know maybe if you're working for a startup, it it may not seem uh important, but this is something that institutions will definitely want to know and and check.

Um in case you're curious, this is the DCO. Um that's it. That's what it looks like. Uh you can automatically sign it on GitHub. Just uh you know, use your commits with the dash S flag. You know, generally pretty easy to to do. Um right. So, I'll encourage you to have legal protections for your code. We will require some form of this IP protection for all LF projects, and you probably should, too, uh if you're working in open source.

Um we like the the DCO, but you know, you can use CLAs for for things, too. So, let's move on. Let's talk a little bit about security. This is obviously a big project. Um there are a few things different in open source, and importantly, institutions will want to be able to verify that you're following best security practices. So, three things I'm going to talk about today uh are vulnerability disclosures, S-bombs or software bills of materials, and uh software authentication and artifacts.

Um I'll point out we have uh sister foundation at the Linux Foundation called the Open Source Security Foundation. Definitely look at this. This has all of the best practices you should be following for security, whether you're an open source software project or not. Especially if you're an open source software project, though. So, definitely check that out if you have questions. Um So, one advantage of open source, right, is that community members can find and and report bugs. You want to make this as easy as possible. Uh you want to a security response team, and you want institutions to be able to participate uh in this process and be very familiar with this. Um

we have a lot of different ways of doing this at the LF. Uh a lot of our projects use GitHub tooling. Some projects have very complicated pipelines. So, I think at this point Besu has seven reporting channels. I could be off by one or two right now. Um but but that's more complicated one. How many people know this XKCD? Yeah. Um of course, this has become much much more troublesome recently with all of these software supply chain attacks.

You all have probably seen many of these. You know, I could do a whole talk on these uh or in fill up many slides with them. Um but uh the software supply chain is really problematic. And this is a big thing that concerns institutions. Uh if you just look at these numbers, this is downright frightening, right? So, Black Duck uh annually does an audit of the most important open source software code bases. Uh this time last year they looked at a thousand code bases. Um 81% of these uh contain high-risk or critical vulnerabilities.

Uh that's uh that's pretty pretty bad, right? You know, when you have a dependency on an open source library with a critical vulnerability. Um you know, old open source components, you know, you you need to update your dependencies more than every 4 years. So, the way we address this and the way that, you know, institutions will particularly like if you address this is through software bills of materials. Um what this basically is is it's a sort of dependency tree of all of your uh code that you've pulled into your project. Um we encourage you to to keep track of all your code uh and be very careful with the

dependencies that you use. Um you know, it's sort of ideal to have as as few dependencies as possible and in many cases it's worth the effort to re-engineer something uh rather than have it as a dependency. There are a lot of good tools to help you with this. Uh there's the Squawk tool and there's a ton of stuff at the OpenSSF that you can check out. Awesome. And finally, uh if you build a popular project, people will attempt to impersonate you. I'm sure people in the audience have had, you know, rogue NPM packages or or Rust crates or something where people try to uh make something that looks like your project to get people to install malware. We get this all the time.

Uh but we encourage you to use tools to sign and authenticate uh artifacts. Uh Sigstore's a great tool if you haven't seen it. Very useful for authenticating your project. And then finally, I'll say a few things about AI. Maybe you've seen some of the news about all of the AI uh attacks recently. You know, I'm I'm sure everyone here has. It makes it very hard to handle security. But we recommend having uh an AI contributor policy. The Linux kernel has a great example of one. And we recommend considering making AI reported security bugs public. Uh this makes managing your security list much easier.

And it isn't really likely to result in new attacks since enough people have access to these models anyway that you may as well consider the bugs public. Um and I'll say finally that verify ability is important. Um so just being able to show institutions that you're following best security practices is extremely useful. Um we have the scorecard at at OpenSSF and I definitely encourage everyone to take a look. It's very easy to set up uh particularly if you're already following best security practices.

Awesome. Then finally I want to talk about governance. One of the things that the Linux Foundation does is define and set open governance for projects. If we go back to our definition of an open-source software license right? The key phrase at the end here is this collaborative public manner, right? And this is what allows for large and diverse communities to form around popular open-source software projects. Uh and it lets people contribute to and reap the benefits of these projects.

Um so when we talk about open-source software and open-source development, it really gets conflated but we're really talking about three separate things. We have open source which is just code. We have open development which means there's a community building on open-source code in the open. And then finally we have open governance. And this is really when their procedures and roles for the community uh decisions and priorities are are governed in the open uh as well as the road map.

So there are lots of different flavors of open-source governance. Um I'll go through four sort of broad categories here. First we have a public demonstration and this is just when kind of somebody puts code out in the open, right? This is just a dump. Um and you know, as many of you probably know, you probably don't want to build on top of uh a code dump. And institutions don't either. The next one is kind of an open product, right? Uh imagine a company or entity open sources a piece of software, but doesn't allow outside contributions. But maybe it shows a road map, you know, regular releases and and follows best security practices.

Some open source projects run as a benevolent dictatorship, where an individual or company uh open sources code. They allow contributions, but the ultimate authority is is always this kind of uh benevolent organ. I I use that in quotes for a reason. Um and then finally, there's true open governance, right? This is code with transparent documentation, meritocratic governance. Uh we have this concept called a doocracy, where those who do things get to decide things and sort of governance rights are uh allocated in proportion to how much you do. Um and these projects are very inclusive. Anyone can join and

contribute, and there's a clear path for leadership. Um So, I'll say institutions are significantly more likely to adopt your project the more openly governed it is. Uh open governance helps avoid vendor lock-in. It provides assurance of long-term project health and reliability. Uh and people will just trust you more if your open source project is governly opened. And uh finally, I will say, you know, whatever governance model you choose, it's very important to document your governance. Um that's how people trust you and and they understand what the implications are of using your software.

All right, I think with that, I'm out of time, and I have a slide for questions, but I don't think I'm allocated time for questions, but I'll be around. So, if you have questions, just come please find me, shoot me an email, and uh thank you very much for your time. >> [applause]