 the state of Linux and research and development. Now, I know this talk was originally entitled The State of Linux, which you guys see me give the annual State of Linux talk every year. And this year in particular, as I was thinking about how to talk about the State of Linux, I faced a real challenge. And usually I say that the challenge is, how do I come up with a new way to say Linux is great every single year? And that wasn't my challenge when talking about Linux this year. The challenge that I'm having when I talk about Linux lately is how to talk about Linux without sounding like a real jerk, right? You might ask, why is that, you know, why do you sell it to, you know, because Linux has now done so well. It is so pervasive in every single sector of tech. You know, you've seen me before talk about 1.5 million mobile devices are sold every single day running like in Linux. 700,000 televisions every day are sold running Linux. 90% of the world's stock markets, you know, 95% of the world's supercomputers, you know, it's just, it powers everything. And the point being is, how do you explain how well Linux is doing without making a comment like, it runs most of mankind. It runs most of modern society. How do you say something like that without sounding like a huge jerk, right? We're so good, but that really is the state of Linux. But what's interesting and what I'd rather talk about today is how Linux as an existence proof that this form of development is so powerful is really ushering in a new era of how the tech industry in particular collaborates, not just around Linux, but really around every either existing or in particular new layer of the technology stack. And so today we released a report. We went out and tried to figure this out. How is collaborative development working within the tech sector? If you go online to the Linux Foundation website, you can go download this, but we surveyed 19,000 individuals to get an idea of how people are collaborating, how they're managing sort of collaboration both inside and outside of their companies. And I think the results were really, really interesting. And what this all comes down to is sort of how people are spending their research and development resources to innovate, right? Linux being one of the great innovation stories. And so when I started thinking about this, I asked myself, what are people spending on research and development today? And the answer is the top 10 tech companies in the world spend about $63 billion on research and development. This is just in tech, right? I didn't include life sciences or automotive or aerospace and defense, but really just the traditional tech companies that all of us know about. Companies like Microsoft, Samsung, Intel, Nokia, all the companies you see here. And this spend, this $64 billion is primarily spent on internal research and development. Traditional research and development projects where you have your R&D labs, you have really smart people that you're hiring and attracting to come into your organization, perhaps partnering with academia to come up with interesting ideas and then try and of course monetize those ideas in the business. And when you talk to people and ask them about R&D, there's one question that I think not enough companies. Even the companies listed up here don't ask themselves that much. And I would posit that some of the companies up here actually do ask themselves the question I'm about to ask, but certainly as you sort of go out from these core innovators in tech, very, very few companies ask themselves this question, which I think is important. And the question is, what about external research and development? How are you working on and managing your external research and development? The development that isn't your internal R&D and the billions of dollars you're spending on that right now, again, billions of dollars. But I think a lot of organizations sort of think of the R&D that's happening outside of their walls as sort of an afterthought, right? And often cases don't manage it all that well. And so one of the questions that we wanted to ask people is how important is collaborative development to your company? Just to see, as they start thinking about externality, do they even, R&D, do they even think it's important? And the answers that we got back were overwhelming. It is critically important. Collaborative development is a critical component of how we make things in our organization. This was the overwhelming response. This is the idea that, you know, probably comes from the idea that nobody makes anything these days without open source software, right? You can't build a phone or a television or anything without leveraging a lot of open source software. And I've talked before about even Apple, if you go into an iPhone, and many people think of Apple as a very closed and proprietary company, but if you go into the general settings section of an iPhone and go scroll way down into legal notices, you will click on that and see the GPL license and just dozens and dozens and dozens of open source projects and code that's being used in every single iPad and iPhone that's out there. It really is important to business. And our survey results reflected that. The next question we ask is, why do you participate in external development? Why do you, why is collaborative development important to you? And these answers were actually kind of interesting to me. So we asked both software developers sort of as individuals and we asked organizations why this type of development it's important, but why do you participate yourselves? And for software development developers, this answer actually kind of surprised me, which is most people think, well, you know, the open source movement and, you know, doing this form of collaborative development is sort of a passion and a hobby and people do it because this whole hacker ethos is something that's fun for them to do. But really what we're seeing is, it's my job. It's the number one answer that we get from folks, which is I am required by my company to do this form of collaborative development. The number two reason was, I started doing it in my free time, right? I think, you know, maybe five, six years ago that could have been flip-flopped, but today what we're really seeing is sort of a professionalization of collaborative development and open source development. And for organizations, normally when people think of collaborative development and open source, they think, well, the reason that we're doing it is because it's free, right? Cost, I'm gonna save money by doing collaborative development. I'm gonna leverage all this free software in order to make the products and services that I will make money on. But that also turned out to be incorrect in our survey. The number one reason, and in fact, it was a pretty big number, was this idea of faster time to market. That by just grabbing open source code, integrating it into a product or service, you can just get to market so much faster than you ever can. And this obviously makes sense, right? Who wants to go out and write their own kernel? Who wants to go out and write a database? You don't have to do any of that anymore, and this clearly gets you to market faster. And then it was the ability to modify the code, sort of control over that. Things that we all understand, but we thought would be lower on the rankings than the third one, which is cost reduction, right? So I thought these were pretty interesting. Then we asked, where are you heading with collaborative development? Is this something you've been doing for a while? You're gonna do more of it. You're gonna do less of it. You're gonna stay the same, don't know. And again, the answers came back from business managers and executives overwhelmingly. 91%, we are going to do more of this. This form of collaborative development is how we are going to run our innovation practice. And I think that's really interesting in terms of how this is proceeding. One of the things that we're seeing is that collaborative development, actual joint code development through open source, is starting to usurp the sort of traditional way that technology companies have collaborated. If you go back even five, six years ago, most of the traditional collaborative work that companies in the tech sector did together was around standard setting. People would get together at IEEE or ISO or Oasis or one of the standard setting bodies and they would write a specification, that specification would provide interoperability and you need to collaborate in order to provide interoperability. And then you would take that 600 page specification, you would hand it to people and everyone would go and implement it. And this was really for, not just five years ago, but for decades before that, this was the primary form of collaboration in the tech sector. What's happening is that that form of collaboration is now turning into open source development. Where instead of, and I think our next speaker is a classic testimony to this, instead of handing, for example, on the internet of things, a light bulb manufacturer, a 600 page specification and saying good luck with that, you hand them the source code and they can implement it immediately and you get better interoperability because you're all using the same code base and you really create the standard that you want because of this form of collaborative development. And so as you can see, this is really a big shift in the industry and it's only going to get bigger. And so the question that I think all of you should ask and people sort of beyond the tech sector should ask is how are you managing your external research and development? This is the point that I want to make to organizations who aren't thinking about this in a systematic way. If you're spending a billion dollars on research and development inside your company, don't you think you should have a semi-systematic way, maybe just a little bit of order to how you actually manage your external research and development? And when I thought about this, there are organizations who actually are doing this well. And many, I think some of the people who actually do this well are here at this event. But it's not nearly enough, I think, across the broader industry to really effectively do this form of what I call external R&D. But I want to show you a few examples of folks who are actually doing this well. And these are what I call the external research and development managers. Does anybody know the people who are on this screen here? All right, this is a really unique crowd. And with all due respect to these guys, most people would never have heard of Dan Fry or Chris DiBona or Eileen Evans or Amon Sussu. Most people don't know these folks. But these are the people inside of different organizations, Chris at Google, Dan at IBM, Ibrahim Haddad at Samsung, Ahmad at Intel, who essentially are professional external R&D managers. They run groups inside of these organizations whose purpose is to manage the participation, consumption, use of open source software and external R&D within their organization. And these folks are running organizations that are pretty substantial. They're hundreds of people work in some cases in these people's organizations. And they do all sorts of things to systemize how they develop and participate within the open source community. I'm really calling this the professionalization of open source, not just that open source developers are getting, people who are working on open source are developers who are being paid to do it in their companies. It's a second layer of professionalization on top of that. It's really sort of creating business processes within a company in a systematic way, creating wholesale organizations to manage this process. These folks go and have people who look at open source projects, whether they're early projects or late-stage projects, whether it's the kernel, which is 20 years old, or all seen, which is just a few months old, and decide, is this something that our company could take advantage of? What open source licenses is it under? How are we gonna consume that? How can we take external code, bring it into our company? How can we share changes we make to that code back? Most importantly, a lot of these folks who have been in the open source community for a long time ask questions like, how do I share what I want to share? But equally importantly, how do I keep what I want to keep? They're the folks within companies who are telling their executives, just because you participated in an open source project doesn't mean you have to give away your entire IP portfolio or everything you've ever done since the beginning of your company. And you would think that's something that is simple for folks to understand, but it is not. And they have very systematic processes within which to do that, which licenses work for our organizations versus not. How do we bring code in? How do we comply with the licenses when we distribute code out? Again, this is professional stuff. These are dedicated folks. This is all they do. And it really is a testimony to how the best tech companies take seriously this external R&D and manage it professionally and give it tier one status, just like the internal R&D that they spend billions of dollars on. And so what are the results? Well, the results is that these folks get billions of dollars of free software to power the products and services they're creating. They may be spending a billion dollars inside the company, but they're getting billions of dollars worth of value by harnessing this open source code that is out there and bringing it into their company in a uniform way. They also get alignment. These organizations are doing really interesting thing. They're watching upstream projects and as they're pulling open source code and refactoring it and getting it ready for a product that they might be releasing, at the same time, they're getting the patches ready to submit to the upstream projects that they created in order to productize whatever they're doing and do that in a way that in some cases, the upstream patches get submitted to a project before a product even comes out. They're doing it just in lockstep with their product development cycles. It's a tricky thing to do actually. It sounds kind of simpler than it is, but it's really important if you wanna stay in sync with all of these projects you're consuming and not have to go fork a code base and maintain it on your own. Again, this is a sophisticated process run by professionals to manage that external R&D effectively. Again, a clear process of sharing and not sharing, understanding how people can participate in open source projects within their organization and outside their organization setting some boundaries in some cases for certain individuals or certain people and all of that matters and all of it needs to be taken seriously. And then I think the final thing that did surprise me when talking with a lot of these folks is that they tend to be the organizations that are most helpful in recruiting top software talent. Being an open source friendly organization, having these systems in place so that an engineer doesn't come to a company and hit his head against the wall all day saying, why can't I participate in this open source project I've been participating in for 10 years? Why won't the suits let me go participate, bring this in, I know the value, I know the engineering power. If you have processes in place to let people do that efficiently and smoothly, you're gonna attract the best talent into your organization. And that's why I think all of this is very, very important. There's a lot more results that these folks muster by managing this effectively, but certainly it's important to do. So if your organization is not doing this now, I think you should take a lesson from these folks because they are really on the leading edge of this professionalization. Another aspect is the professionalization of open source projects, which sounds a little weird too, right? But in the last couple years, we have definitely seen the rise of foundations, right? The OpenStack Foundation, things like Open Daylight, you know, the Apache Software Foundation Eclipse. These are foundations that play important roles providing the home for this form of large scale collaborative development. They provide a neutral place for people to invest and do collaborative development at industrial scale. Even at the Linux Foundation, we've started to become sort of a foundation of foundations as we host the different efforts that you're seeing, many of which you're seeing up here, one of which you're gonna hear about in a second, all seen, to come in and invest and really do very large scale collaborative development. Again, this is a shift from sort of the ISO of 20 years ago or the IEEE of 20 years ago to a new form of professional, systematic collaborative development that is a new thing for the tech sector. We will see more of these, I guarantee it. I know of many that are coming your way. And it is a shift in terms of how the industry collaborates. So what is the future whole? What does it mean for software as software becomes more pervasive as we use more and more of it throughout our lives? And as this professionalization takes place, what does the future hold? Well, I think what's going to end up happening here is a new sort of Pareto principle in software development. Does anybody know what the Pareto principle is? Yes, it's the last one. I had to Google it too. I did, I looked it up and we, this is the 80-20 rule. It's the concept that sort of 20% of the work represents sort of 80% of the results. In sales, it's a common principle where sort of 20% of the sales people are responsible for 80% of the revenue in a company. The 80-20 rule, you hear it in business all the time. But I think this is also going to be applied to software at large, which is two things. One, I think 80% of the software that people use to create products and services will be open source. Sony, if you ask Sony Mobile, they'll say 80% of the software in our mobile handsets is open source. And then 20% is, whether it's open source or proprietary, it doesn't matter, but 20% is the part where you really emphasize your unique value. Whether that's the 20% that makes sort of, let's say, a platform as a service open source project that you might bring in, tailoring it to your business processes through some form of development, it's that 20% that's going to make the difference and add all the value in where big business opportunity comes from. And I think really that is the future of how software is gonna get built. This is professional, it's big, and I think that's not going to change. And it's a big difference for many of you who've been in a community that started off as really sort of a hobbyist movement and something that everyone's passionate about.