 You know, this event, you know, we call it the leadership summit because we bring together folks from open source projects, developers who are leading and maintaining critical open source projects, some of which we host, others are just important projects and we love having those folks here. We have folks from the business world who are in charge of bringing in open source code and productizing it to create value for their company or in some cases governments. We have lots of attorneys here who help us sort of make the intellectual property value chain work across all of this sharing. We have investors here this week from venture capital firms who invest in open source companies and it just really makes up for a really terrific crowd. And I want you to get motivated this week to talk about the intersection between those different kinds of communities. Super communities, business communities, legal communities, investor communities. And I want to get you kind of warmed up by looking back I think about 16 years to when open source was just sort of emerging as a movement and look back on sort of how far we've come since then. And I want to just show you, some of you may have seen this before, but it's a short video from a Super Bowl ad that was aired one time announcing sort of the birth of Linux in terms of a commercial sense. So let's just take a look at that video. Can we roll that? I think you should see this. It's just a kid. This is a G chord. He's learning. I'm so open. He's getting smarter every day. Homo Habits was the first to use tools. A player who makes the team great is more valuable than a great player. Losing yourself in the group for the good of the group. That's teamwork. It's happening fast. We've always watched the stars. If you look at the sky, you can see the beginning of time. Collecting data is only the first step toward wisdom. Sharing data is the first step toward community. Poetry. There's not much glory in poetry. Only achievement. Knowledge and justification. What he learns, we all learn. What he knows, we all benefit from. One little thing can solve an incredibly complex problem. Everything's about timing, kid. This is business. Faster, better, cheaper. Constant improvement. So, you want to fly, huh? Win, speed, thrust, it's physics. Respublica non-dominant tool. Come on. It's all about the tools. Speak your mind. Does he have a name? That's awesome. It just hits on so many points, you know, what motivates people to share, the fact that all of us are smarter than any one of us. It's just amazing. And look at how far Linux has come since then. It now really dominates almost every sector of computing and arguably runs modern society in terms of technology. It is just an impressive achievement, and I think that again captures just how those humble beginnings and how sharing was such an important part of getting us to where we are today. As a quick aside, does anybody know what ever happened to that childhood actor? Eminem. Eminem. Yeah. He went on. I'm joking. It kind of looks like Eminem, right? Like a little bit. But Linux has definitely come a long way, and it continues to evolve faster than ever. These are some statistics. Greg Crow Hartman, who maintains the stable Linux kernel branch, is back there. He gives you these stats every year, and it's just amazing to look at how fast Linux evolves, how many lines of code are modified and changed every single day. I mean, it's just an unprecedented velocity. We're only starting to really see similar velocity in projects that are very recent, things like Kubernetes, which we're going to hear about in the next talk. But open source development itself continues to accelerate. If you look at the number of repositories, I have to go back and update this almost every week, where there's now 78 million repositories on GitHub, millions of developers working on thousands and thousands of lines of code, creating billions of dollars in shared value. It is amazing. It leads to this question that I want us to discuss this week, and I think is important for this group in particular to talk about, which is of the 78 million repositories are out there of the billions of lines of code, what are the ones that we should really be looking at? What are the ones that are really important to the function of society, to our collective cybersecurity, to our collective privacy, to the growth of the collective economy and technology that we all depend on? That's a question that I really want to encourage all of us to ask this week and to try and come up with answers for. I also want all of us to think about this week and challenge all of you in each of the sessions to think about this diagram, which I show a lot, which is from an upstream project to a downstream solution product to the value creation of that product into profit or into more efficiency, back into the reinvestment of that project with more code, which creates better products and solutions, how do we make this spin faster? I show this diagram all of the time and it's an interesting sort of simplified view of it, but this week is different. This isn't a naive group of people. This group needs to dig down into the details and into the subtleties of this feedback loop. Here's examples of questions that we get all the time at the Linux Foundation that I want to pass on essentially to all of you. I don't have answers to all of these, but it's really important to look at how we all think about solving and answering some of these problems and questions. How do I share what I want to share and keep what I want to keep from an intellectual property perspective? How do I allow others to participate in an open source project without screwing up the architecture or making it kind of go sideways? How do I handle security issues? How do we do better collective response? How do I make sure that an open source project is consistent and interoperable with other technology and that consistency can be applied and even certified in a consistent way? These are the questions we get all the time and this is the week to dive into the details. It's not a high level talk, let's really get into the details. I want us to this week think about that positive feedback loop that I showed in terms of innovation gears, where you have projects that get solutions that create value and then some of that value gets harvested and reinvested back in the projects, but let's dive deep this week. My challenge to all of you is to really get into what is a cog in each of these gears, how do we optimize how these gears interact with each other? And this is an intentionally busy diagram for a keynote presentation. The design team when I sent this over said no one's going to read any of this. And I'm not even asking you to read any of it. What I'm asking you to do is collectively look at what kind of methodologies based on your particular perspective in this value chain, can we do to improve this cycle? And so this one really is something that the Linux Foundation holds near and dear in terms of what does it mean to be a truly good upstream open source project? How do we create and identify the value for a project? Is that something that happens organically in a developer community? Is that something that happens with a collective interest of a set of users? How do we provide a neutral home for that? What are the legal frameworks that we can put in place in terms of the intellectual property license, patent sharing arrangements and so forth? What are the metrics that we might look for that indicate to the world that this code is safe to consume in a commercial sense, that we can get more reinvestment in it? Are there certification programs that we might stand up to indicate consistency to create stable APIs for these projects? How do we license a trademark, for example, in order to create that kind of a conformance test or platform for any particular open source project? And so on and so on and so on. This week isn't about, hey, open source is about sharing. This week is about let's dive down into the details. And at every level, how do we make this better? How can we innovate in terms of providing metrics or creating effective license compatibility across all these different projects from an upstream perspective? And the same applies for people who are building solutions. How many people here work in an open source program office at their particular company? Yes, a lot, great. So do many of you participate in the to-do group? This is our organization, which is a peer group of folks whose job it is to essentially, I like to call it managing external R&D, right? If today, 80, 90% of the code and any technology product or service is open source, and your company's spending, let's maybe say $2 billion on internal R&D, but there's $8 billion of value coming in through open source, you should probably have some systematic way of managing that. And that's really what this cog is all about, this gear is all about, is the solutions that people use to either how people bring code in, modify it for a solution, and then share back those changes and then to be able to continue to harvest value. And again, this is actually detailed work that I challenge all of you to talk about this week in terms of how we can improve it. How do we create IP policies that make it easier for folks to pull in code to create products and services without having to go to their general counsel every time they want to bring in that code? Forgive me, cuz I see some attorneys right here, Dave right there in the room. Also, how do organizations engage with community? So that they're not just pulling code in, forking it, and then sort of defeating the purpose of participating in open source, but actually are able to share back. I love telling the story about how at IBM, which was one of the early pioneers of creating a group like this. They had an open source technology group inside of IBM. And we're really struggling to get their requirements into the Linux kernel project. It was back in 2005, I think, 2004. And they sat down and thought, what are we doing wrong here? Well, what they were doing is for every patch that they would submit externally to the kernel, there was a review process internally that had to clear it out. People would have to agree upon it. Then they would submit it to the mailing list and then if they got that code in, that particular developer who got the code in would be paid a bonus for the patch based on the amount of code they got into the kernel. What they did was changed it. They said, first of all, all discussions are gonna happen on the external mailing lists. We're just not gonna do this internal review thing anymore. We understand the license, we're confident in what we wanna share. Go and do it out there. The second thing is, you got a bonus not based on whether your code got into the kernel, but whether anybody's code got in that met that particular requirement. And so it moved from more of a contest to a community in terms of how they participate. It's these kind of subtleties that I really challenge this group to talk about, how do we make this particular way that code comes in and creates really interesting, whether it's commercial or government solutions, how do we make that more effective? So I encourage you to go and look at the to do group and all of the different sessions today on that. Thirdly is, how are we creating value? This is sort of the investor question, right? Which is, the question we get all the time is, well, how does anybody make any money off open source, right? Which is just such a simple, simple question. I'm gonna show you some ways that people look at that. But I think you really need to look at, what is your particular organization's perspective? Are you looking at it from building a commercial enterprise? Are you looking at it from a shared R&D perspective? Do you just have requirements at your firm that you can't get met anywhere else? So you're sort of forced to do this kind of user innovation and you wanna just share that collective responsibility with a peer that may be a competitor or not? How do we actually take and create value and then reinvest it back into these projects? These are the questions I really encourage everyone this week. We have lots of sessions on this. We're gonna have investors here from leading venture capital firms to talk about it all week. Let's dive deep into these questions. One of the questions that I wanna pose to all of you is, of these different years, which one comes first, right? In the case of Linus Torvalds, he wanted to build a kernel. He was in a dorm in Helsinki. He spent 26, what is it, 27 years now. Working on this thing, it was sort of this organic form of innovation, right? And I think that we as a movement, open source solar, has this bias towards loving that perspective. This sort of David versus Goliath, someone in their dorm room just comes up with this great code and all of a sudden the world is changed by this particular open source project. And I think that's an admirable view and I think in some cases that does absolutely happen and it's amazing. But which of these comes first, I think is a much more sophisticated question. And this sort of open source chicken or egg problem is not new to the technology industry. This has been around since computing started sort of the argument. Was it hardware or software, which came first? But I would posit that they all come first. And so let's take kind of a look at these. And I want to use this to encourage conversation throughout the week. The developer first scratch your own itch is the one that we all love, right? Somebody has a problem, they go and build an open source project. And then everybody piles on and they create this wonderful ecosystem around it. And when it works, it is freaking amazing and those communities are incredibly passionate and inspirational, right? That's not the only way this happened. A lot of times we'll see companies that are out there literally just looking to fill a gap in a particular requirement that they have or are limiting their investment to a very specific need. I think we see this where as we move for example to 5G, global operators are saying, listen, there is no commercial software out there that can help me get to the kind of latency in bandwidth and data requirements for 5G. We just, we gotta go create this stuff on our own. So you're there in creating projects to fill this particular gap, right? But it's not just that, I think one of the big misfires that all of us tend to make is not necessarily thinking about the business perspective first. But I would argue that there are a lot of open source projects that came out of looking at it from an investment thesis first. And the most typical example of this is this business value of commoditization. Martin Rikos is here who is responsible for MySQL, which was the CEO of MySQL, which was one of the early commoditizers of database. Linux came from this sort of commoditizing of Unix. MySQL was really taking the database market and shrinking it down and then monetizing that essentially commoditized component of it and capturing that somewhat smaller share. Again, JBoss, similar thing. What's interesting about that is, A, it worked very, very well. Red Hat is just a great example of that. But what's sort of also interesting about it is it's naturally capping the value of that particular organization because you're commoditizing a market, you're naturally shrinking it, so you're naturally capping what the actual total addressable market and then your particular ability to address that market might be. What we're seeing differently today, which I want all of you to discuss this week, if you are coming at open source from a business value perspective, right? You're thinking of, hey, I need this business problem solved and should open source be used for that? Is that what we're really seeing now is open source leading these sort of C changes in tech from an entire value chain. I think that microservices is a good example of this. This is a C change in tech that has maybe a little less to do with open source. And I'll come back to how open source is really leading that change. But it really was a movement towards a different way of creating, deploying, and doing ongoing integration and deployment of application infrastructure, right? Again, I think so, Mazan is here from AT&T, where you had this business driver of needing to get ready and get to market quickly with 5G, all of this incredible underlying infrastructure that just wasn't available and the need for speed and the need to create that business value is what really drove it. What's interesting here is you're no longer capping the value of these open source built components. What you're really doing is expanding into entirely new markets and leading that. And customers are requiring it and that open source is mandated in their procurement policy in many cases. And open source is getting folks to market much faster. Which is sort of the final component, again, and none of these come in any particular order, I think it just depends on where you're coming from. But in terms of what I hear from open source program offices, what I hear from engineering teams is the ultimate goal is the need for speed. When you ask someone, why do you have an open source program officer? Why are you using open source so heavily in your product development? The answer generally comes back. If I don't use a lot of open source, I'll never get to market. I had a conversation with the CEO of GoPro years ago where he just said, you saw my name badge at an event, we were both at and said, my gosh, we could have never gotten to market without Linux. We would have to go and either license or create this proprietary platform that would have taken us way too long. We just grabbed that code and we ran, right? So this is what many, many, many organizations come in from this angle. Just it's a need to speed to get to market. I choose an application framework, it's no JS, it's open source, I grab a bunch of libraries with MPM, I build this application, only 10% of the code in there is stuff we actually wrote, right? And I think that the other thing that I see is the sort of solution folks want that speed, the second thing, and I think this is an area where we all need to improve upon and I want to challenge again this week, how do we collectively do this, is how do we ensure in this speed and need for speed, interoperability, consistency, standards, the ability to be able to integrate the standards development and compliance process for interoperability with the rapid development of code. I still think we're trying to figure this one out. I personally talk with standards development organizations from all over the world in the telecommunications sector, in other areas where we're trying to harmonize intellectual property policy, where we're trying to kind of create the intersection of standards and code to happen more quickly. Let's figure this out, let's talk about it this week, there's sessions this week about this, let's try and make it work faster, because if we can get these gears to work quickly, to move faster, we're all gonna be better off. And we're already seeing how when this really works well, it is a truly amazing feat. If you look at what CNCF has been able to accomplish, if you look at the way that the projects have been set up within CNCF, the growth of Kubernetes, the ability to meet challenges as they come, as a community, right? What kind of community do we wanna be? How do we wanna treat each other? How do we ensure interoperability? What kind of standards might we deliver into the market? How do we get IP assurance across the different participants in this? How do we enable different cloud service providers and enterprise services to create solutions? Of all the different orchestration out there, how do we signal to the market that Kubernetes is really becoming that de facto standard? And it has really, really worked. In just a short period of time, Kubernetes has sort of become the de facto standard for container management, right? It's created also tremendous value. Millions and millions of dollars in venture investment. Billions of dollars in market capitalization. We're already seeing at Mobile World Congress. Was it Mobile World Congress last week? Last week at Mobile World Congress we saw an executive from Vodafone talk about how they're reducing their time to deployment and efficiency. But it was like 40%, Dan, was it? The efficiency is a 40% efficiency gain? That is huge. That is a tremendous amount of value for folks like Vodafone. The whole container and microservices and sort of that DevOps movement is opening entirely new markets, right? And it's not just CNCF. We're seeing this across other projects here at the foundation. Our automotive project is helping the car sector compete for the in-vehicle experience with a piece of Velcro and an iPad, right? By creating a collective software platform. It's now in millions of vehicles worldwide. The Hyperledger project started just a couple of years ago. Brian Bellendorf is here this week who is working on deploying the Hyperledger code base in production to manage global supply chains, to go and root out blood diamonds through the automating, through blockchain, the Kimberly process. And then CNCF, as I mentioned, just insane growth and incredibly effective flywheel. So this really, really works well until it doesn't. This is the other challenge I want us all to figure out and try and come up with new solutions for this week. Heartbleeds a good example of it. I could mention a whole bunch of other ones in terms of security problems. There's been other high profile security vulnerabilities in the news lately. Some of them choosing not to mention cuz it's just too soon. It's too fresh for some of the people. Christmas was a tough holiday this year for certain folks. And I wanna thank in particular some of those developers in the back of the room who worked on some of these critical vulnerabilities. But Heartbleeds is just a good example of where generally with this, when this flywheel is working, it's generally working the same way. We think we can all improve it as I've illustrated. But when it breaks down, it tends to break down in its own unique and sad, very Tolstoy-esque, right? Like all good open source projects are kind of working in this value chain and sustainable, and all bad ones that are having these kind of problems are miserable and unique in their own very unique way. And OpenSSL was an example of this where you had Steve Henson and Steve Marquez sort of valiantly maintaining this code base that is incredibly widely deployed and keeps all of us private. I tell the joke how not too long ago the internet was secured literally by two guys named Steve, and that's a real problem. The question I want to ask all of you is how we can go and figure out this intersection between critical shared asset and screwed up and then create processes to go and remediate, help improve those projects. So the things that we collectively depend on when they do break down can be fixed. And so that's the challenge this week. How do we make this flywheel spin faster? How do we choose projects? There are going to be conversations this week about the chaos project. I think there was a session yesterday that was in follow-ups this week. What metrics do we want to use to indicate open source health, right? How do we get the most out of an open source project? The to-do group has consistently published guides on how to run an open source program office, all the different details around deciding how you bring code in, modify, and share it back. Take advantage of these resources and there's more to come. The to-do group has an entire track this week. Go and participate and let's help create more of these guides to bring more people into this community. Finally, and this is my passion, and we have a couple of speakers this week who will be talking about cybersecurity. One of the things that I want to solve to think about is how do we create more secure code? Cyber security is a truly global problem. I would argue that it's a pan-government problem. That we're all kind of collectively in the same boat here. And what you're going to hear from one speaker this morning is these vulnerabilities by another name are simply bugs in software. So one of the things that I admire about the open source movement and the free software movement is the culture of freedom and sharing and the zeal and meaningfulness that people in communities extol. Why can't we have a similar culture and mindset around software security? A sense of inner responsibility that the code we're creating is going to put all of us in jeopardy if it has a bunch of bugs. That test coverage is a responsibility. That having responsible disclosure or fuzzing and linting code is a responsibility. Let's think about this week how we can do that. Our core infrastructure initiative has started on this with our badging program, we've got about 1,000 projects registered for the batch. But this is a way to go and show that you care about security as a project. You pass a series of questions that say you do all these things, not just theater, you really have to take it seriously. But what other things can we do? What things can we think about this week to figure out what is the most important share of software in the world? Who wrote it? Why are they writing it? Is it working? Is it worth it? Do we need to improve it? Let's talk about that this week. That's what we're all here for. So I think that if we can do those things, work together this week. This is the week where if you can unplug a little bit from your work, just sort of put yourself into a thinking space. Think of it as an academic world where we can think collectively about how to optimize these gears, that's what this event really is all about. And I think that we are all stronger together. I do believe in this concept of all of us being smarter than any one of us. But my high level hyperbole is no longer sufficient. Let's dive into the details this week. And I look forward to working with all of you on doing just that. So thank you very much.