 When Mark Andressen wrote his Wall Street Journal article in August 2011 in which this famous quote, software is eating the world appears, he was really addressing the question of software disrupting every single vertical, whether through digital transformation of incumbents or through new startups built on software that would show up in the markets and create new opportunities there. What Mark Andressen wasn't expecting though was how ubiquitous open source would be in the course of a decade. If we look at the numbers in 2018, those numbers come from Black Duck, a company that does Merging Acquisitions audit about a thousand to twelve hundred each year. In 2018, 96% of the applications that they surveyed contained open source components and in those open source was actually accounted for over half of the code base. So was that in mind, I think it's time that we revisit Mark Andressen's decade old statement and transform it to say that in short open source is eating the world. So although pretty much everyone that is building software now is using and relying on open source for a substantial amount of the software that they're building, it turns out that still very few companies actually contribute back to open source. And you know, this begs the question, well, why should companies contribute to open source in the first place? Why would they do that? What's in it for them to some degree? And the answers we have to this question usually are very much kumbaya answers for lack of a better word. Essentially, we're talking about, well, you should contribute back because it's for the common good, or it's paying it forward, or it's the right thing to do, et cetera. So none of these reasons are really addressing genuine business driven reasons for a company to contribute to open source. And the problem was addressing open source, contributing to open source that way, is that when you put these lightweight feel good reasons on the scale and you start comparing them with counter arguments that will arise from other parts of your organization such as losing IP, or losing a competitive advantage, or increasing your risk surface, or wasting resources on open source that can ultimately just help other companies, or just the fact that as a company, you don't really have the know how of how to contribute to how to release open source. Then this makes it really difficult to concretely, solidly make the business case for open source inside of your company. And so the purpose of this presentation today is essentially to move a place where as an industry, we understand the return on investment at the ROI of using open source really well. The proof of that is that everyone is actually using open source. And realizing, first of all, that we don't really understand the value of contributing to open source that well. And giving us a number of tools, a toolbox essentially to be able to assess the actual benefits contributing to open source would have for our organization and be able to argument it and present a strong business case for doing so. The other aspect, obviously, is that the risk of contributing to open source are not really well understood. Like the shark here, we are concerned, we're scared of sharks when in fact they're essentially not really dangerous animals and they don't kill, they kill way less people than bees or even dogs do on a yearly basis. And so our fear of contributing to open source is based on not well understood risk and exaggerated risk. So let's start with trying to understand the value of contributing to open source. And for this, we'll look at three categories of benefits of open source. Strategic benefits, operational benefits, and what I like to call second order benefits. Let's start with strategic benefits. One of the key strategic benefit of open source that is used by companies is using it to commoditize your complement. Well, what's the complement to a business? It's the thing that needs to exist so that you can sell the products that you are building. So let's have a look at some concrete examples and how that translates into open source projects and open source involvement in contributing to projects. Google for example, well, their key focus, their core focus of their business obviously is search. And what's the complement to search? Well, it's a way to bring eyeballs and people to search, right? And well, it turns out that unsurprisingly, Google is heavily invested in two open source projects that do just that, the Android platform and Chromium, which is behind the Chrome browser. Let's look at Intel. What is Intel's core business? Well, Intel builds and sells chips. What's the complement to a chip? What an operating system obviously, and hence unsurprisingly, it turns out that Intel is the biggest contributor to Linux. Talking of Linux, Red Hat, the second biggest contributor to Linux, essentially builds services and packaging around Linux and hence contributes to it. Facebook, that's a really interesting example because it stretches this idea of commoditizing your complement a bit and lets us see how open source can benefit us in very unexpected ways. You can say that Facebook's core business is actually data mining of user behaviors and finding patterns that it can then sell to advertisers to do targeted advertisement. And so if you think that data mining is their key focus, then obviously the complement to data mining is all of the hardware that you need to have to build the data centers that Facebook is relying on for stocking and processing all of the user information. And so a number of years ago, Facebook started the open compute project, which is essentially open sourcing data center plans and server and hardware specifications. And as a result of this, Facebook mentioned on numerous occasions that it was able to save billions of dollars by creating a level playing field for the hardware manufacturers and being able to really just pick from the vendors that were the most interesting to them, that were all building to their specs. And other very common strategy used for open source is to on ramp developers onto paid offerings. So it's a surprise to no one in 2020 that developers are actually critical in the purchasing decisions of organizations because once a developer knows that technology prototypes and your product on that technology, it is fairly common for that technology to end up in production and thus was sort of like enterprise level service agreements after that. And so unsurprisingly, cloud providers and related sort of infrastructure providers are focusing on open source significantly to bring developers to their offerings. That explains, for example, why Microsoft bought GitHub for seven and a half billions a couple of years ago in order to really drive usage of its Azure platform. Now that we've looked at strategic benefits, let's look at operational benefits. So those are interesting because they are actually useful to companies that are not necessarily buying, sorry, selling software directly. A key one obviously is paying technical debt. I think we've all been there, used an open source project, forked it to fix a bunch of things that were specific to our needs, and then had to handle sort of patching it, pulling new versions and ended up with a lot of work in that space and sometimes as a result, not patching for security issues fast enough, etc. Well, there's a really easy solution to that problem. Just upstream your changes, right, contribute back your changes to the community, and suddenly this kind of like technical cost just essentially disappears. Another really interesting benefit of contributing to open source is to leverage the external contributions. A great example is React. When Facebook released React, they also wrote a bunch of white papers for sort of like other pieces of the ecosystem that would be useful to react applications. And no and behold, the community actually wrote things like React Router and Redox based on those white papers, and really quickly the teams at Facebook that were relying, that were using React and had built internal equivalents to React Router and Redox realized how better these external tools were and used them instead. And the other interesting benefit here is that they were also able to hire from the contributors to these projects. So the last category of benefits of contributing to open source I'd like to look at are second order benefits. And to better understand what those are, let's start with this diagram. This diagram describes the process of engineering and it shows an engineer that takes as input a problem in coffee and that spits out as output a solution and as byproduct sarcasm. If you change that slightly and consider the same process diagram for software engineer, nothing much changes except the output instead of being just a random solution that's now expressed in code. Turn the same software engineer into an engineer that is contributing to open source code. And what you will see is that this output, this code output is now feeding the pool of commons. And shortly thereafter what happens, another software engineer comes to contribute to the same pool. And what's really interesting is that this other engineer can come from a completely different background whether it is cultural or it could be a corporate engineer or instead a student or a hobbyist just enjoying this particular project. And soon these two software engineers will start interacting. This could be just through random conversations on the mailing list or a github issue. It could be in code reviews. It could be through mentoring. It could be through networking events and in real life or online etc. Now remember the sarcasm was a byproduct that I was mentioning earlier that's they're more of a joke. Turns out that byproducts are really interesting and obviously all of this conversation could refuse mentoring etc. going on also creates byproducts. And when you think about those they are the key to the second order benefits of open source. Let's have a look at a few. As you can see from those there are a lot of byproducts of having people work together on open source code. It's hard to figure out exactly what the benefits are here so let's organize them in four categories that essentially are benefits to projects, individuals, teams and organizations. And as you can see benefits to project will really be focused on how the code and its documentation is improved as a result of being an open source project. For individuals it's really about leveling up engineers and having them build the kind of skills that will make them better leaders and will also give them more opportunities. As a team, teams that participate in open source get to meet other teams that do the same and this obviously feeds efficiencies and innovation. And finally at an organizational level companies that contribute to open source tend to see as a result to improve culture and moral and being perceived as leaders, access to a talent pool that they would not have access to otherwise, being remote friendly which again in 2020 is a really nice byproduct and reducing things like churn. All right so by looking at all of these new benefits of open source we're now sort of tilting the scales back in favor of contributing but our doing this was solid arguments. So the other thing that we have to do now to really continue completely tilting the scales and showing the benefits of open source is to actually assess the negative aspects that people mention when we talk about contributing to open source and wonder whether there are actually really that concerning. So one of the key things that shows up all the time is contributing to open source means losing your competitive advantage. So two things here. First of all obviously no one is suggesting that you should contribute the code that is absolutely critical to your business and that you see as a huge competitive advantage. Frankly if you look at all the software stack in an organization that's usually a really small chunk. It's not the whole thing. So start by contributing code that isn't key to running your business and go from there. The second aspect which I find really compelling and sort of to use this overused Wayne Gretzky quote which says I skate to where the puck is going to be not to where it has been is that it turns out that if you want to be effective at competing against other companies just copying them is really a bad strategy. Like it doesn't work. You're always late. You're always a couple of years late and that's not how you win. So the real concern of like I'm going to build all of this software and other companies are just going to come and steal it and then beat us at our own game is widely exaggerated. Another one another problem that shows up really often is lost IP. If we contribute to open source we're going to lose IP and here the question is really one of what's the value of IP compared to the value of having great innovative teams that are able to iterate quickly and ship software which is what you get when you have amazing teams of engineers that are able to contribute to open source and that are happy to do so. So I'd like to quote Jan Lacan here who was the head of Facebook's machine learning AI division and he says the following in today's world the fast paced internet services deployment owning IP has become considerably less important than turning research results into innovative products as quickly as possible and deploying them at scale. What matters is shipping innovative products. So build the teams that help you do that and one of the best way to build teams that help you do that is to have a really strong open source culture with a new company. All right so there are a bunch of other risks of other issues like increased risk wasted resources lack of know-how etc that are also interesting to tackle. We don't really have the time today but I just want to mention that most of those are either exaggerated again or can be handled like lack of know-how it's easy to educate higher the right people to help build that internal culture. All right so having done this we're really tilting now the scales in favor of contributing to open source but of course what you have to remember is like that's going to be different for every company and so what I wanted to do here today is give you the tools to be able to do this and to be able to do this for your specific context and your specific organization. So the key here is this is a framework to think in terms of business trade-offs. What's a benefit? What's a risk? And understanding that in some cases risks can overweigh benefits but in general that is not the case. The second thing is this is actually a toolkit right there are benefits and there are mitigation strategies and you should use those and apply those to your organization. So when you do that a few suggestions. First of all be reasonable if if your company just invested heavily in a patent portfolio it's going to be really difficult to make the case for giving all of that away right. Second thing is show empathy to others needs in the organization understand why legal is pushing back understand what it is that they need listen to them it's very often the case that there were communication issues that prevent different organizations within a company of finding common grounds and being able to move forward so listen to others. Aim for small wins start small start with a hackathon or contributing back to a project that is not critical or releasing a small piece of software or organizing an event or giving money sponsoring some of them the dependencies that are critical to your business and that are open collective or something like that right start small and the key is to remember that this is a mindset shift right move from the notion that open source is good and that you should contribute to it because that's the right thing to do right to the notion of seeing how open source contribution is aligned with your business the business goals of your organization and can help drive them you will find that conversations once you adopt this mindset this mindset conversations with executives and business leaders and legal are going to be way more easier because you're suddenly speaking the same language