 All right. So welcome to my talk. Today, I'm going to talk about navigating open source business risk. So I'm going to talk about evaluating risk for open source projects. I'll start with a brief overview about why it's so important to actually think about risk. I'll talk about the difference between company-owned open source projects and ones that are owned by foundations, along with some thoughts on neutral governance and how it impacts risk. I'll also share some thoughts about what policies and documents to look for, along with how to evaluate the community risks. Then I'll wrap it all up with a few final thoughts and links to some resources. The presentation is already uploaded on-schedge. So you have the links in the slides to peruse at will. So first, I will start by telling you just a little bit about me. I have been in the technology industry for over 20 years. Working mostly on open source projects from within companies like Intel and Puppet. Now at VMware, I'm responsible for our open source community strategy within the open source program office. I'm also on the steering committee for the Linux Foundations to Do Group where companies collaborate on ways to run successful open source program offices. I'm also a board member of Open UK, which is focused on developing and sustaining leadership in open technology in the UK where I live, and I'm a governing board member and maintainer for the Linux Foundations Chaos Project, which is focused on metrics and open source project health. I have a PhD from the University of Greenwich, where I researched how people collaborate in the Linux kernel. Now, unfortunately, the scenario on the slide is probably a lot more common than people realize. So one of the biggest examples of this was a couple of years ago, when it was discovered that OpenSSL had a security bug in their cryptography library. So that was heart bleed. Now, OpenSSL is a technology that almost every company in the world uses in one way or another. It was during this crisis that most of us learned that OpenSSL received about $2,000 in donations a year, and it was mostly maintained by a single person. So yes, that's right. Software that we all use had almost no resources to actually maintain that software. And there are probably hundreds or thousands of other open source projects in the same or similar situations. Now, this situation with heart bleed was resolved relatively quickly, but we might not be so lucky in other cases. So evaluating risk is important because it can disrupt your business. It's also important to think about risks being on a continuum. So, like with most things in life, there are no sure bets, and no project or technology open source or otherwise is completely without risk. There are only projects with more or less risk across a wide variety of categories, which we'll talk about. And whether you should accept that risk is a business decision. And it should also take into account how you use that project. I wanted to start by talking about why it's important to think about who owns or controls an open source project. Because it's something that many of us probably don't spend as much time thinking about as we should. The project's governance documents can usually help you learn more about the ownership and control of a project. And from a risk perspective, you should be looking for projects with neutral governance, where decisions are made from a variety of different companies. Projects that are controlled by foundations and ones that are owned by an individual company can have very different dynamics. And different risks associated with participating in those projects. So I'll start with a couple of examples of what can happen with projects that don't have neutral governance. Licensing changes are one thing that can increase our business risk. Especially when an open source project is controlled by a single company. So there have been several companies who are fed up with cloud providers selling software as a service offerings based on open source projects. And those companies didn't necessarily give a lot back to the open source projects. So the solution from these companies was to use more restrictive licenses. In the case of MongoDB, they created a new license called the server side public license. It would be used for MongoDB, but also for the security patches for previous open source versions of the software. So this prevents people from continuing to use an older open source version because it's not going to be secure. Now Elastic followed suit recently by moving Elastic Search and Kibana under the SSPL. And it's important to note that the SSPL is not an OSI approved license. So this means for all intents and purposes, MongoDB, Elastic Search and Kibana are no longer open source projects. So situations like this one increase your business risk. License changes require time from lawyers to help us interpret those licenses. And new restrictions on how we can use an open source project can delay our product delivery to our customers. And decreases our productivity if we need to spend a bunch of extra time finding and implementing suitable replacements. Governance issues caused by ownership of open source projects can undermine the project's success and lead to disruptions within the project. In some cases, these disruptions make it really difficult to make progress on a project, but they can also result in the project forging and becoming separate projects. So forging a project in particular can be extremely time consuming for everyone involved. And all of this takes precious time away from the development of the project and slows down progress until things sort of shake out and settle down after the fork. And it increases the business risk for companies who are using or contributing to the project. And here are a couple more tangible examples, which we talked about in an earlier presentation. But MySQL was forked into MariaDB when Oracle acquired Sun. And many of the original MySQL core developers, including Mahdi, the creator, just didn't think that Oracle would be a good owner of MySQL and wanted to ensure that the code base would remain open. And in a similar fashion, shortly after that same acquisition, LibreOffice was forked from OpenOffice. And both of these forks created a significant brain drain away from those original projects. Because a lot of the developers moved over and began working on the forks. In the case of LibreOffice, the fork became way more popular than the original project. Now, one way we can avoid situations like the ones I talked about on the last two slides is by supporting projects that are under neutral foundations, like the Linux Foundation, whenever possible. However, it isn't always clear whether a foundation is neutral or not. If the board of directors or other leadership bodies are made up of people who work in a wide range of companies, especially competing companies, that's a good indication that it's a neutral foundation. If the board members are made up primarily of people from a single company or a couple of companies with very close ties, it's probably not a neutral foundation. You can also look at trademarks. If the foundation owns the trademarks for most of the projects, that's likely to be a neutral foundation. If, on the other hand, a single company owns all of the trademarks for all of the projects under that foundation, it's probably not a neutral foundation. And it can help to look at the projects themselves under the foundation, were they originated at a single company, or did they come from a bunch of different companies? Do the projects have leaders from a variety of companies? Do they have a contributor license agreement from a company or from the foundation? And so the more you see references to a single company across the projects, the less likely that foundation is to be neutral. CNCF, Linux foundation, Eclipse, Apache softwares, a foundation are all examples of solid neutral foundations. And one of the reasons that Kubernetes has been so successful is because it was contributed to the Cloud Native Computing Foundation. So putting Kubernetes into a neutral foundation provided a level playing field where people from a whole bunch of different companies could work together as equals to create something that benefits the entire ecosystem. Open source projects that are controlled by a single company are higher risk because they operate at the whims of the company. And there's little recourse for outside contributors when that company decides to go in a direction that doesn't align with the expectations of the other participants within the community. So think back to the examples from earlier where projects moved to non-open source licenses or were forked. Now, for company originated open source projects, consider the reputation of that company as a steward of open source projects. But always keep in mind they can change their strategy at some later date. And I'm not saying that you shouldn't participate in open source projects owned by companies. So VMware, we have a whole bunch of open source projects that we own. But you should think about the risks that you're taking. And in some cases it makes a lot of sense to accept this higher risk. But you should try to at least make sure that you understand the risks you're taking and how those could impact your company. Governance can be found in all open source projects in one form or another. And it helps outline the expectations around roles and responsibilities along with the decision-making processes. But it will vary quite a bit by the size of the project. A project with only a few people will not need elaborate elections to select leaders. But the project should have at least a few basic rules defined, like maintainer for example, and knowing how collaboration occurs and how decisions are made is vital to being able to make contributions that are more likely to be accepted. If the processes for collaboration, leadership and decision-making are not clearly documented as part of the project governance, this can increase the risk of participating or using that project because it introduces a lot of uncertainty into the mix. Now one way to help mitigate this risk is to have some discussions about governance within the community to gauge interest in getting some help with governance. In a lot of communities there can be various types of informal governance that just isn't documented. Quite a few people tend to avoid working on governance. So if it's missing, you might be able to volunteer to help, which is a great way to learn about how the community operates. And it also gives you a gauge for how open they are to actually documenting the governance within the project. Sorry, I lost my water bottle. Now, because leadership is such a critical piece of governance, I wanted to spend a little bit more time talking specifically about it. At a minimum, there should be some kind of documentation about leadership within the project. There may be committees, working groups, special interest groups, or other groups with opportunities for leadership. If you become an active participant in a project, you will want to understand how your contributors can move into leadership roles. And having employees in leadership roles helps reduce your risk as a company, since these employees aren't a position to understand more about how the project operates and how the project works and be able to mentor other employees and other people into the project. And there are quite a few different options for selecting leaders as a part of governance. And the ideal is to have a process that provides some sort of fair and level playing field that defines how contributors can become leaders. And this should be documented so that all participants can clearly understand the criteria and the process for moving into leadership positions. Bigger projects like Kubernetes have an election process, at least for the top levels of leadership, like a steering committee. But the key is that having a fair and transparent process for selecting leaders, like elections, reduces your risk of participating, since your contributors can participate in the elections. And they can have a say in the governance of the project. Higher risk options would include organizational leadership seats, where a certain number of positions are allocated to specific companies. And those companies get to decide who gets their leadership positions. And there's no easy way for new leaders who don't work for those companies to move into leadership positions. But regardless of how leaders are selected, you want to make sure that there are opportunities for your contributors to move into leadership positions, which will help reduce the risk for projects that you use and contribute to. Now, in addition to the governance documentation, there are quite a few other policies and documents that you can look at as a part of your risk assessment for a project. So security was talked a lot about this morning in the keynotes. People often worry about security for open source projects. Under the premise that if everyone can see the code, they might also be able to find and exploit security vulnerabilities. But the flip side is that there are more people who can view the source code for the purpose of fixing those security issues. Now, within a product team, working internally within a company on a project, you'll have a limited number of people. And an increased chance that your shared backgrounds will lead you to think of things in similar ways. With people from many different companies and backgrounds contributing to an open source project, those innovative ideas will also apply to proactively making the project more secure. And then also, reactively fixing any vulnerabilities that might arise later. However, this certainly obviously does not mean that open source projects are automatically secure. It's not the way it works. One thing I look for when assessing the risk of open source projects is whether they make regular releases, where they quickly patch security vulnerabilities. And you should also look at the project's security policy documents to make sure that they have a solid process for allowing anyone to privately report vulnerabilities and a process for then dealing with those reports quickly and efficiently. Projects that take a proactive approach to addressing security issues and releasing fixes are going to be a lower risk for your company. There are a few documents that even the small ones should have. They need appropriate licensing documentation. They should have a code of conduct that people can easily find with details about how to report incidents along with consequences of violating that code of conduct. The contribution documents should provide enough details about the contribution process so that someone who's brand new to the project can make their very first contribution. And the communication process should also be clearly defined so that people know how and where to communicate within the project. Now, if everyone understands how people within the project communicate with each other, it avoids frustration. So not just for those new users, but also for the experienced ones as well. And again, one way to mitigate these risks is to volunteer to help with some of the documentation. So long-term contributors have probably not looked at their new contributor documents in a very long time. And they may not notice that their documents are incomplete, out of date, incorrect. And someone new to the project can often be a really big help in finding the problems and approving the documentation. And the better all of this is documented, the lower the risk, since your contributors will know what to expect and how to navigate the project when they make contributions. The community can make or break an open-source project and the overall success of a project often depends a lot on the community. Communities usually the first thing I look at when trying to decide if an open-source project is healthy is the community active and engaged in productive discussions about the project? Are they helpful when people have questions or problems? Are they welcoming for new contributors and new users? Do they treat each other with kindness and respect? You'll want to look carefully at how people treat each other on mailing lists and GitHub reviews, Slack, and other communication channels. People with a culture of treating each other with respect and kindness are going to be a lower risk because your employees will want to continue to contribute. On the other hand, projects with toxic cultures can put your employees and other contributors at risk. There could be real health risks, both mental and physical, for your employees. And these toxic environments can impact retention since employees might be so eager to leave the project that they'll look for another employer where they won't have to work in this toxic community. And if the culture is too toxic, this is one of those things that can be very difficult or even impossible to mitigate. So if the community isn't amazing, this is a risk. Now, it doesn't necessarily mean that you shouldn't get involved, but you should approach it with a lot of caution and understand the risks that things could go terribly wrong if it gets even worse within the community and your contributors start disappearing. If you're actively using an open source project, it's likely that you'll find bugs or want to contribute fixes back upstream. So for new projects that you're considering, you'll want to make sure that maintainers and other contributors typically respond in a timely fashion. So seeing large numbers of issues and pull requests on a project is a red flag for me because it can indicate that they either don't have enough contributors to handle the incoming pull requests or even worse, that they don't actually care about or want contributions from other people, which is something you occasionally see. Now, in some cases, you can help solve this problem by making contributions to open source projects part of the job for some of your employees. And so the projects that really don't want contributions from other people, those can be a really high risk because if you're using them, you're going to want to upstream some changes and if you can't get those upstream, you're going to hold them forever and that's going to suck. So we don't always spend enough time thinking about the contributor risk associated with open source projects. For any open source projects we rely on, are there enough contributors that if one of them won the lottery and retired on a beach, could the project continue with minimal disruption? This is a bigger risk for projects that are highly complex or contain technologies that require specialized expertise, like we saw a few years ago with the OpenSSL Heartblade example. You should also look at organizational diversity as a part of the health and risk for open source projects. If all or most of the contributions are from the employees of a single company, what happens when that company has a shift in strategy or gets acquired or runs out of money and goes out of business? Would the project continue if the company pulled all of their employees out of the project? And again, it comes down to risk and whether we're willing to take that risk. Got a few resources that people might find useful. The slides are uploaded on schedule so I'm not going to talk about those but I will leave you with some final thoughts. Most business decisions boil down to an assessment of risk and making trade-offs. And we should all be thinking about project risks in light of how we're using these projects within our business. If we build our products on top of open source technologies, we want it to be as low of a risk as possible. On the other hand, if we're using an open source project and some small part of some non-critical infrastructure that isn't really that important, then we can accept more risk. Now, no project is all good or all bad, all risk, no risk. And no one solution will be right for every single situation. So project risk, like I mentioned before, exists on a continuum. And deciding which risks we're going to accept is the beginning, not the end of the process. Since we should also be thinking about how we can monitor and mitigate those risks over time. We need to think about the risks we might be taking and make informed business decisions about which risks to accept. With that, thank you. And I think we have two minutes for questions but I'm going to go ahead and unplug so the next speaker can prepare. So any questions? Oh yeah, let me off hook that easily, sweet. No, go ahead. I'm not sure that I understand your question. Yeah, I mean, it depends. It depends a lot on the project, right? So we do try to focus on contributions to the project, not necessarily engineering. Sometimes those are other contributions. I was just in a presentation by Omar in the other room and he's basically a product manager and he's been working on Knative and making product and user contributions there which has been really helpful for the project. In other cases, we donate money to foundations. We do a lot of other work. Sometimes, yeah, I don't know how much VMware does of this but projects that I've been on in the past, things like infrastructure and those sorts of resources are really welcome. So it just sort of depends on what the project needs as for what kinds of resources we provide. Like with anything, open source is one of those like, is no one solution. So the next presenter can go ahead and get set up. I'm all off the podium.