 Rhaid i chi ddweud ymlaen i'w Liz. Rhaid i chi ddweud hynny, hi. So, hwyl, rhaid i chi, rhaid i chi. Aeth gafodd yma, rhaid i chi'n Liz Rhyth. Rhyw ymddi'r ysgol o'r ofis yw'r cymdeithas iawn i'r cymdeithas iawn i iso gyda'r cymdeith y cymdeithio i ddiwyd iawn, felly rhaid i chi wedi'u gwneud hynny. Rhyw ymddi'r ambasodyr hefyd i'r ysgol ym Mhwytau Oesiannol I chair the Technical Oversight Committee at the Cloud Native Computing Foundation, which is the sister organisation within the Linux Foundation. It's the home of Kubernetes and lots of cloud-native-related projects. Can I get a show of hands? How many of you here are using Kubernetes or containers in production? Quite a few of you. Maybe keep your hand up if you were amongst the adventurous set of people who were using Kubernetes in production in, let's say, 2017? OK, we have one, two, three. Yes, a few of you out there who were very adventurous. Since those early days, 2016, 2017, we've seen a huge growth in adoption of cloud-native. But I think since you're all here at an event about open source, I probably don't need to speak to you about the benefits of using open source. I want to talk today about the reasons why end-user companies are contributing engineering time and resources to open source projects. I'm going to talk about some cloud-native projects and contributions made by some of our end-user members. Those are companies who are not primarily in the business of selling software. They might be selling shoes or movies or music or, like many of you, financial services. So, as an example of a project that was contributed by an end-user company, I'm going to start with Backstage. This was developed inside Spotify as a developer portal, a platform for developers to create and ship applications within Spotify. And it has nothing really to do with streaming music, so Spotify recognised that by contributing it to the community, it would have benefits for them and for the project itself. Backstage is just one example of a project that's been contributed to the CNCF by an end-user organisation. We have projects from another music company, SoundCloud. We have contributions from Lyft, from Intuit, from Capital One. But before I talk about the reasons why these companies have contributed these projects, I want to talk about the nuts and bolts. I literally want to talk about nuts and bolts. So, nuts and bolts are part of the common fabric of manufacturing. If you have a nut, you can go to any hardware store and you can find a compatible bolt to fit that nut. It wasn't always like that. Until the end of the 18th century, if you had a nut, it was a unique piece that had a matching bolt that they had to be used in a pair. If you took something apart, you had to keep very careful track of those pairs of nuts and bolts. I've got a great quote from the time. None can form an adequate idea of the annoyance, delay and cost of this utter want of system. Along came a chap called Henry Maudsley. He developed the idea of precision screw-cutting parts for lathe. He made it such that you could reliably recreate the same dimensions of screw thread. Reproducible builds for nuts and bolts, if you will. We have the same situation in software. Like all those thousands of unique nuts and bolts before Henry Maudsley's time, we have thousands of lines of code in organisations doing roughly the same thing, but in slightly and annoyingly different ways. In open source, we've recognised that if we can standardise on a smaller set of common tools and common projects, that's going to be much more efficient. Take Kubernetes, for example. There are dozens of different distributions of Kubernetes, but they're fundamentally compatible. Kubernetes and containers are great examples of infrastructure software that aren't differentiators for the business of end users. They're kind of commodity software. BlackRock recently opened source a project called OCI Builder for building containers. They recognised that to make that project successful. They needed high levels of adoption to make it sustainable. They've developed this tool because they needed some innovation in the way they wanted to build containers. Perhaps the reasons why it's necessary for BlackRock might also apply to other companies. Perhaps OCI Builder will become a de facto standard. I say a de facto standard because, like nuts and bolts, we don't have to settle on one tool, but we probably want to settle on a small number of standardised approaches. Another reason to standardise is for safety and security. We don't all have to sacrifice someone to electrocution to recognise that having fuses in plugs is a really good idea. Collaborating on security makes life and software safer for all of us. Speaking of someone who's worked in security for quite a few years, I've been involved in container security for quite a while, I firmly believe that software is safer and we are more likely to uncover vulnerabilities when it's open and the more eyes on it and the more people using it, that's the way we find and can then fix software vulnerabilities. It's hard to measure, it's hard to know how that applies in proprietary software because we don't have very good measures of the level of security vulnerabilities in proprietary code. But I think it's pretty well recognised that by opening code to open source communities, by sharing it, we're more likely to uncover those vulnerabilities. So, what should you do if one of your teams discovers a vulnerability? Well, I hope that you will be responsible users and you will report that vulnerability to the project. You report it without disclosing it publicly so that the project can come up with a fix and deliver it to users before that vulnerability can be exploited. Now, maybe you're thinking, ah, but if I know how to fix that vulnerability, I could have a competitive advantage or my competitors would be vulnerable and I wouldn't. Well, that would be a very dangerous game of prisoner's dilemma. And more practically, it's going to give you a problem. It's going to require you, if you have your own fix to a project, you would have to maintain your own fork. Now, maintaining forks is, in my opinion, a giant waste of time and effort. In general, maintaining forks, particularly private internal forks, doesn't end well. Your team end up having to merge fixes and features for forever. I've spent enough of my career on time merging fixes to know what was that quote about. A utter waste, you may have formed an adequate idea of the annoyance, waste and cost of maintaining forks. And only last week, Oracle talked about how if you don't contribute back to upstream, if you maintain a fork, you are essentially screwing yourself. Another reason to contribute to upstream is to get features. Your engineers understand why you might need new features or new extensions to a project. Your engineers, your teams understand the context of your requirement better than anyone else. So if they can be involved in contributing that feature to a project, that feature is more likely to meet your precise requirements. It doesn't necessarily have to be a contribution from your engineers alone. This could be a collaboration. And even just reporting issues is a form of contribution. The more involved you can be with a project, the more you can actively contribute to a project, whether it's with engineering or other forms of contribution, the more likely you are to be able to influence the direction and the roadmap of that project. In order to contribute fixes and features and codes to projects, your team is going to need expertise. But the good news is that it's very popular with engineers to develop expertise in open source projects. We can see by looking at the tens of thousands of people who have registered for Kubernetes-related qualifications from the CNTF. It's really popular. People want to get involved with these open source tools. They want to demonstrate their knowledge in these areas. At the other end of the scale, there are some areas of open source that require where there are really just a handful of experts around the world. The Linux kernel is an area where there are a lot of developers, and individual parts of the kernel are really maintained by small groups of people. An example of that is an area that I'm involved in called EBPF, and some of the leading experts in the world who work on EBPF work for Facebook and Netflix. At their scale, EBPF has been really, really useful. They recognise that EBPF is not a competitive differentiator for them. They allow their engineers, their specialists in this field, to collaborate with those of us who are software vendors. That raises innovation across the whole field. Open source is an attractive field for a lot of engineers. This isn't about the cliched idea of developers, working on their pet projects late into the night. Often it's actually the complete opposite of that. It's engineers who want to collaborate with their peers. They want to be involved with the community. They want to learn from and get recognition from their peers. By encouraging or allowing open source contributions within your organisations, you can leverage the attractive nature of working on open source. By allowing people to contribute to open source, you can make your engineering teams an attractive place for talent. By increasing the pool of expertise in these different standardised tools, by having tens of thousands of people who have demonstrated an ability to run applications in Kubernetes, we reduce the training burden on our individual organisations because these skills can be shared amongst this pool. If we come back to Spotify, because more and more companies are adopting backstage, which is after all Spotify's internal development environment, it means that Spotify are now in a position where they're more likely to be able to hire engineers who are already familiar with the environment that they use to develop applications internally. By contributing to open source, you can have happier engineers. You can develop a greater range of expertise and you can get new features into production more quickly. It would be unthinkable for manufacturers to be having to make or commission their own nuts and bolts. In the same way, we're going to look back on this age as the time when we recognised the nuts and bolts in our software, we learned to collaborate on the infrastructure that we all need. Thank you very much.