Keynote: How to Properly Open Source Software: Lessons Learned from the Linux Found... | Devcon SEA

[Music] awesome hi everybody I'm Hart and today I'm going to be talking about how to open source code I think this is going to be a little more pragmatic than some of the previous talks but I'm going to start by talking about some open source background why do we open source and a little bit about the Linux foundation with a focus on why you should care about my opinion on how to open source code then I'm going to go into some open source table Stakes some stuff that you really need to get right if you want to properly open source code uh this will include software licensing IP protections and best security practices and finally I'm going to talk about open governance and open communities so let's get started so let's Recall why do we open source code there are two main reasons the first is so others can verify examine and learn from our code right if we want people to be able to trust what we're doing we have to show them the code and open sourcing also has many benefits around things like software security but probably the main reason why we open source code is so that others can use and even contribute to our code there are many economic efficiencies of working together in open source and a large ecosystem around a piece of Open Source Code ensures that even if one organization goes away development will continue so open source software has won in the broader ecosystem if you're a developer you probably know this but for many commercial applications you know even a typical commercial application even if it's Clos sourced 90% of a modern application's codebase is open source and if we look at how software is built today in the world and even commercial software this is sort of what it looks like right um people start with an open source software framework and then they use custom code and existing libraries to solve problems s and this can lead to tremendous economic efficiencies I know this is a cipher Punk track but if you're trying to convince your boss that you should be able to open source your code the economic efficiencies are a great argument um but open source is most efficient when multiple companies entities or people collaborate to build software that they all need in the open and you can think of this as decentralized development and this is the problem that the Linux Foundation solved we solve decentralized development for open source code and when multiple companies entities or individuals want to collaborate on open source software but don't trust one single party to own the code they turn to the Linux foundation and this is something that you know blackchain people tend to be inherently comfortable with which is fantastic so I don't want this to be an infomercial for the Linux Foundation but I do want to present some facts and figures that can hopefully you know convince you that we have the data and the EXP experience to properly give advice on open source code so we are behind some of the most critical projects in the world probably everybody knows the Linux kernel you know maybe you use kubernetes if you do Cloud development but you may not know that a large part of the world's Telecom stack runs on Linux Foundation open source code or that if you have a new car it probably runs on Linux maybe using something like Automotive grade Linux um you know there's you know fun projects too like the academy software found Foundation which hosts software where Hollywood you know uses to make uh animations and also stuff like Risk 5 um just some numbers I'm not going to read these to you but hopefully I can convince you that we've seen it all when it comes to open source and why am I here well we have a number of projects in the ethereum space as well many people here may know Basu which is one of the core ethereum execution clients we also have a number of other tools for ethereum in our open source ecosystem like web 3j which you might have used to develop on ethereum or Paladin which is a brand new lab for privacy for EVMS and again all of these code bases are completely free and open to use so you can go do it today if you want all right so let's get into the meat of the talk let's talk about open source software table Stakes what do you need to do to make sure you have a good experience open sourcing your code and let's look at a definition of Open Source software right it's a it's a type of software in which source code is released under a license and the key word here is license and the obviously a license is in this case a legal document that expresses rights and responsibilities around the code so there are three typical types of Open Source license we see today um we have business licenses which are typically very restrictive software licenses that may require payments to a developing company for use we have copy left license like a GPL license where modifying the software requires you to contribute back any derivative works or things you build on top of the software and finally we have permissive licenses which really let you use and modify the software in any way that you like and I'm going to go into a little more detail about all of these licenses so let's start with BSL licenses so technically a business source license is not an open source license it's a source available license and the source code is public but you're only allowed to use the source code if you've met certain characteristics um and this is sort of viewed as a compromise between proprietary software and open source software if you want to gain some of the benefits of people seeing and trusting your code but you want people to pay for it this is what people typically do um B USL is an example of this and in the ethereum space arbitrum Nitro has this license now let's talk about copy left licenses these are open source licenses that require users to make available all derivative works so if you modify the code and use it in something you typically have to make the source of that something available for free and also licensed under this copy left license copy left licenses are often very hard to use commercially um and notable examples are MPL GPL and lgpl and in the ethereum community gu is a notable example so I'll put this quote from Richard stalman about uh ganu and copy left licenses and I will issue a warning about copy left licenses the goal of copy left licenses is to increase contributions by legally requiring them and the unfortunate reality of these licenses is that people just won't use your code if there are any viable Alternatives due to the potentially cumbersome legal requirements and I'll say it's very hard to relicense to a permissive license from a copy left license so choose carefully and finally they're permissive licenses these are open source licenses that let you modify and use code freely um most commercially used open source code at this point in time uh does use permissioned Excuse me permissive licenses because they're by far the easiest to use uh and if you want to maximize Community adoption of your code we definitely recommend you use a permissive license uh you probably seen apachi 2 and MIT as examples of this uh there are lots of projects but in the ethereum space Basu has an Apachi license so before we go any further um I just want to mention some commoning excuse me some common licensing pitfalls you know most of these I've talked to at this conference and seen people make these mistakes so what I want to talk about is being very careful with code you use right and this is kind of an lgpl dependency issue so when you use a combined work with lgpl code which means you're putting lgpl code into your something bigger and and using that uh people sometimes think that you can link it if it's in a separate folder but as this provision shows uh you can't really have compile time dependencies for lgpl code it has to be a runtime dependency so carefully check your dependencies um and finally you know be careful with licenses that don't have IP protections so this is an example from an anonymized uh company documentation the basic basally says we're going to use a permissive license for code but we're going to enforce patents on this code so you still need to pay us to use this code so read carefully this company is actually very transparent uh and if you use code from less ethical and transparent people you might be rolling the dice on a lawsuit um so in summary I'll say pay very close attention to the licenses and licensing requirements of Open Source projects you use uh I personally recommend that you use apachi to for your own code because it's a permissive license license and it has explicit patent Grant protections um and if you want to make a proprietary code vase visible to others maybe use a BSL license right now let's move on you know we've been talking about IP protections so what do you do when you need to protect your code against IP issues right sometimes contributors might unintentionally or maliciously add some code that has some form of Ip protection to your project and it turns out we at Linux have had a big issue with this does anybody know of the SEO Linux disputes yeah some people so these were you know a huge number of lawsuits essentially because the colonel did not have explicit IP protection on it and to do this you know folks sent the LF created the developer certificate of origin and we recommend that for your code you either use a developer certificate of origin or a contributor license agreement it's very important to have these legal Frameworks around your code uh and this is especially important if you're taking contributions from Outsiders um so just as an example this is the dco right here uh that's it it's very easy to set up on GitHub using commits signed with the uh- S flag it takes a little bit getting used to but once your contributors are used to it it's very very easy um right so in summary be sure to have legal protections for your code if you don't people that can be sued will be very hesitant to use your code we actually require this kind of protection for all Linux Foundation projects if you contribute code you have to have this protection and you should have it too for your open source software we used the dco but again a CLA is perfectly acceptable right so what about security obviously security is critical for any software not just open source software uh and we could do a whole conference about open source security and there was one last month actually uh but I want to briefly emphasize some things that might be different for open source and those are vulnerability disclosures es bombs or software builds materials and authenticating software so I will say we have a great organization in the Linux foundation called the op ssf which has all of your op Source software best practices uh go check it out if you have any questions on security it's a great source just to make sure you're doing everything you need to be doing right so what about security vulnerability disclosures and pipelines uh an obvious advantage of Open Source software is that community members can find and Report bugs and the key point is you want to make this as easy as possible for them right you don't want contributor friction to be an issue it doesn't really matter the exact method in which you set things up as long as it's easy and to follow um I'll say that in the LF many of our projects have been using the GitHub tooling uh not all of them Basu for instance has seven reporting channels which can be a challenge for us to handle uh but we do now moving on recall that I said modern software was built like this right um this is is very nice and efficient but it introduces a number of problems right if you build on software with security bugs you might have a real problem and it turns out that a lot of the big attacks that have been publicized and caused a lot of problems recently have been due to these so-called software supply chain attacks uh and the solution to stopping these attacks is generally what's called called a software build materials or ES bomb has everybody here heard of es bombs before some people great okay if you haven't you should definitely check this out what es bombs let you do is they let you keep track of all the code you pulled into your open source software project if there are bugs you can quickly find them and update them right and I also encourage you to carefully examine the code you use to make sure it's well maintained you know don't pull in code from some you know random developer who hasn't updated it four years ago um and I will again well-run open source projects are very careful with the dependencies they use and there are a lot of good tools to help with this uh guac is excellent but there are many others as well right so I'll briefly touch on software and artifact authentication uh if you build in a popular open source project people will attempt to impersonate you uh this constantly happens for us at the LF you know just last month we had people create a bunch of fake npm packages to try to impersonate us um but you know there are plenty of tools that you can use to sign an authenticate code uh sigstore I think is an excellent example of this although I do wish and think they should be run on the blockchain all right so we've covered some basic stuff what about building an open community so if we go back to our definition of Open Source software one key thing here is this phrase collaborative public Manner and this is important because the freedoms provided by particularly a permissive license allow large and diverse community to form around popular software right um this allows for those economic efficiencies of Open Source so when we talk about you know open development and open collaboration we don't just mean open source right we also mean open development which means there's a community actively Building open source code in the open and open governance which means that procedures and roles for the community how decisions and priorities are made for the project and the road map are openly defined and managed so I'm going to go through a few open- Source models of governance here and and this is a Continuum it's not sort of you know it's only these four things just to give you a flavor of how you should set up your open source project so the sort of least open form is is called what I like to call a public demonstration and sort of the code is just open source it's just there it's not really updated there's not necessarily a road map uh you could be less polite and call this a code dump um then we sort of have you know move on to open Company products right and this is when a company or entity open sources a piece of software that constitutes a product right it doesn't allow outside contributions or makes them very difficult but it keeps a road map you know has regular releases and fall as best security practices and as we sort of get more open we have benevolent dictator projects and this is when an organization or individual open sources their code and allows contributions from external contributors but ultimate authority of the project is still that one benevolent organization and finally we have true open governance and this is code with you know transparent documentation decentralized meritocratic governance hosted under a neutal neutral entity and anyone can join they inclusive clear processes for leadership uh and no restrictions on who can join and become a leader right so we can go a little bit more into details on these sort of code models right I certainly believe that opening code in a kind of public demonstration is better than not opening code at all right third parties can audit your code see what you're doing people will trust you the biggest push back we get from this particularly from big companies is that there's reputational risk and my response is usually that if you're trying to build a production system you shouldn't be embarrassed to let others see your code that's a problem if that's the case um you know once we sort of move on to a more open product um it can be a little bit easier than a public demonstration but it's still hard to get others to use your code because the model requires a very high level of trust in the company what happens if the company changes Direction and abandons the software or goes out of business that might be a problem for you in your business if you're building on this code uh and then sort of a benevolent dictator model right um this is increasing in openness but it it still means that competitors in your space are those who don't trust your company or entity are unlikely to participate so it's easier to get contributions and have you know people participate uh than just an open product because people can make you know typically small changes they can fix bugs they can work on their pain points uh but ultimately it's not open governance and then finally we have fully open governed projects right this strongly incentivizes companies or other entities or people to contribute because they can play a role in governance proportional to their contributions you know a diverse set of contributors means that potential users can easily be convinced of the long-term stability and viability of the project and this will increase overall use of the project and the main drawback of this is It's the community project now it's not just your project and people that participate should receive governance Powers proportional to their contributions right so about governance I will encourage you to carefully choose projects to use or contribute to based on which style of governance is utilized by the community and whatever governance you do choose make sure you document it clearly if your main goal is growing a community we strongly recommend openly govern projects as you know we've talked about for the last two minutes right so finally I want to talk about some best practices for growing the community so one best practice is open source bureaucracy and this is what I've said before although I haven't really called it this is that the most successful projects that have stood the test of time have neutral open governance models where those who do the work make the decisions right um again not very Cipher Punk but the longest lasting most successful Open Source Products also have a good commercial support ecosystem right and a diverse commercial support ecosystem uh because the people that make money off the code can put it back into contributing to the code um it's ult to attract investment from potential competitors if one entity owns or controls the codebase so we recommend a neutral home are setting up some kind of neutrality around the codebase and finally it's very important to have transparent documented governance so people looking to contribute are going to want to know exactly how they can participate and they don't want to be surprised so right this seems hard uh what should I do well um take a look at the Linux Foundation or another open source software Foundation you know something like the software Foundation as a home so you know the lf's role again is to serve as a neutral organization to host code if you don't have this or or you need this then we can potentially help you know we're trusted by essentially all of the big companies in technology um you know it's hard to put an open source Community together um we have experience there and with us and and all these other software foundations you know the same legal structure that for us at least protects the colonel and kubernetes can protect your project uh and finally you know I do want to emphasize and mention that contributing code or a project is completely free and open to anyone so any Linux Foundation project you can come join you can use the code you can contribute the code it's all free and completely open so um yeah come find us at Linux Foundation decentralized trust if you have any questions and uh thank you very much for your time all right thank you once again har for that we do have a few questions here can you explain the differences between MIT and Apache 2.0 licenses great question this is a hard question and the true answer may not even be legally known because we have not had court cases that have separated these licenses again not a lawyer this is not legal advice the main difference is the Apachi 2.0 license has explicit patent protections so this has not happened yet but there might be a case where there's a successful patent lawsuit against an MIT codebase but not against an apache2 code base for now that hasn't existed uh you know for now they're mostly identical they're compatible licenses uh you can use them interchangeably but uh you know if you're extra paranoid you might want to use aachi too all right what are the most effective Revenue strategies to ensure the financial sustainability of an open source project and how can you build enough Community interest to reach that sustainability this is also a great question uh you know we could spend an entire talk on this uh it really depends on your business model there are a number of successful open source business models I'm sure many people in the room have them uh but the big thing is that you know people should be successfully using the open- source software in commercial businesses right um you know whether it's like you know selling services on the open source model that's a very popular one right uh you know selling premium products on top of the open source model you know or software those are sort of two of the main models uh there are many more but again um the key is is building a commercial ecosystem around this um if I knew the answer to to that in in every kind of application you know I would be a billionaire software executive uh I am not not so you know I'll say it does depend on the project maybe in another life okay on to the next question fascinating talk but how do we get the average people to actually care about open source software uh that's a great question um we're always at the Linux Foundation you know looking to do that more um you know I think it's it's a much easier conversation to have with with developers uh so you know I don't know I don't know have a necessarily good answer to that question I I think it's a difficult problem you know people have to understand software and software development first uh so it's it's a hard question the next one says you talk a lot about governance can unchain governance help with this uh potentially in the long run onchain governance can help you know right now lawyers are very uncomfortable and the the precedent really hasn't been set um you know I'm optimistic in the long run that you know that we can have at least some governance on chain yes all right how many of these best practices do you wish were not needed in a world with better legal Frameworks and or less frivolous lawfare well I certainly wish we had uh a less crazy software patent uh system where we didn't have to you know constantly engage in you know mutually assured destruction patent practices and things like that so you know I would love to um I would love to see that cleaned up you know some of the licensing is that you know companies you know do need to make money off of Open Source software but I certainly think the patent system is is a mess um how do I oh sure yeah how do you envision open source software evolving in a world that's increasingly dependent on decentralized and privacy focused Solutions well you know decentralized Solutions inherently mean more people have to come together to solve problems right and that's going to mean a bigger role in open source because you know the only way people can build software together is is effectively is really in a neutral home right we're going to have to have you know decentralized neutral homes for software so I think decentralized technology is going to really you know accelerate the development of Open Source and the use we're already seeing a lot of this in the banking industry all right are there any resources to help transition from a benevolent dictatorship to an open governance model absolutely we have a ton of this at the Linux Foundation uh you know go look at our website come talk to us this is a very common question we get asked quite a lot and we have a lot of experience uh you know doing this all right onto the last question does the uh LF look at public good funding experiments in the ethereum ecosystem um we periodically look at funding uh you know we don't you know we're a nonprofit so we don't have a ton of money to give away we obviously don't have a token but certainly our maintainers and projects look at funding opportunities for themselves all right thank you so much for that and thank you to every single one of you can we please give a harder Round of Applause thank you