 Yeah, so as Jim and Norison mentioned, I want to talk a little bit more detail about how we bring projects to the Linux Foundation if you're curious to do so and also how we kind of support and sustain these projects within the Linux Foundation. Jim did a pretty good job of introducing what the LF is, but in terms of who I am, I spend probably most of my day job working on the Cloud Native Computing Foundation, which is the home of Kubernetes. I also helped start the Open Container Initiative, which standardize a lot of the Docker Container Standards, and I essentially run DevRel all throughout the Linux Foundation by supporting initiatives like To Do Group and so on. So in a previous life, I was a person who worked on Fedora and Gen2 Linux, read a lot of the Eclipse part of the Eclipse IDE, spent a lot of time working on engineering at IBM and Red Hat in early days of my career. So yeah, today I'm going to talk a little bit about, you know, I'll skip a little bit faster about what the Linux Foundation is because Jim did a pretty good job about that. I'll talk about how we operate as an organization. A lot of people still think that the Linux Foundation just supports Linux, but we support a lot of different types of projects and organizations. We're essentially foundation as a service, which is how I like to refer to as an organization. I will then answer the question of if you have a company or organization or project and you want to, you know, bring your code or project to the Linux Foundation, how to do that with some examples. And then I'll kind of end things with some basic tips and then kind of open it up for Q&A. So what is the Linux Foundation? I think Jim already did a good job about this covering this. I'm not going to go into detail, but a couple of things is we essentially have foundations that are either split by technical focus area or industry vertical. And some of the new ones that we've done this year, I tried to highlight in red actually just to remind me that we actually have an energy one that I need to add in this damn diagram, or damn diagram. But some new stuff that we did this year is like, you know, we brought the RISC-5 Foundation and Open Power Foundation under the Linux Foundation, which gives us, you know, kind of a play in the more important open, you know, instruction set space. You know, that's going to change the whole chip industry in the next decade. I was involved in setting up the continuous delivery foundation, which if a lot of people, I'm sure you have used Jenkins, I'm sure everyone in this room probably has used Jenkins once in their life, but it serves as a neutral home for continuous delivery projects. And of course, we've kind of rebooted our AI efforts under something called LFAI, and I think later today I'll hear someone talking about Onyx and other AI things. So we're, it's a large organization, you know, there's many, many projects and we support a huge swath of the open source ecosystem. So, you know, like I say, we're a federation of foundations. The Linux Foundation does more than just Linux, so for the, for the star, you know, star folks. So, yes, you know, typical thing, open source is continuing to grow. I think GitHub said something like there's 50 million or so projects that they have that's continuing to grow, it's just absolutely bananas. You know, the LF, we're very different compared to other organizations. So things like the Apache Foundation basically welcomes, you know, any project, right? The LF, we truly really care about a small segment of projects out there that we really want to grow and build sustainable ecosystems on. We're not a place to just dump open source projects. We're here to actually truly build commercial ecosystems around them to sustain them. And we kind of have this model, we call it, you know, we host projects where there are members associated with those projects. Those members build products that make profits. And so what happens is you kind of have a healthy ecosystem where we're the neutral home to projects. We don't do products, that's what our members do. Those products produce profits and it gets reinvested back in the ecosystem. So like CNCF, we have 500 plus members. Those members do a lot of Kubernetes related products. Those make money, those get refunded, those get funded back into the foundation to kind of build this nice, healthy ecosystem. This is basically the best way, in my opinion, to sustain open source projects. So this type of work of like what the actually LF does for projects, you know, we provide a neutral home, which is super important. We provide a lot of developer tooling to kind of assist our projects. Infrastructure, you know, sometimes CICD services, security scanning, like Jim mentioned. We do a lot of ecosystem development. We're all here today at the open source forum in Japan to learn a little bit more about open source. But we do this all over the world. We do it in North America, Europe, other parts of APAC. We just did a Kubernetes forum in Sydney recently. So we're truly kind of global in what we do. And of course we provide a lot of IP management related tooling and services to ensure that when these corporations and members build products, they need to ensure that the IP is clean and so on. So that's kind of our really fundamental job in the organization. So, you know, one thing to note about sustainability is, you know, really it's all about how to kind of build an ecosystem that becomes diverse and manageable over the long term to basically ensure that not one company or entity is truly responsible for its success. And, you know, this is a typical diagram you see if you ever, you know, have done product management or, you know, had a chance to go to business school. But essentially, all products have a life cycle, right? You go in the beginning, you build them out, you invest in them to try to grow them and eventually things become stable over time. You have some type of growth and things kind of sunset over time into whole goals. You invest and then you reap the rewards over time. And the important thing to note is there's no difference between an open source project and really a product per se when it comes to this life cycle. They both share some other thing. Open source projects grow and eventually they, you know, get used widely or they die and then things eventually get, you know, kind of sunset or sustained over time. And the Linux Foundation, our role is to kind of guide these projects and support these projects through this life cycle. So, you know, there's really different phases here in terms of, you know, things you do at launch, things you do when you commercialize an open source project, maintain it and sustain it. The LF has services for all these different types of phases. I'm not going to go too much into detail, but the kind of core I have here is, you know, things like, you know, Linux, Kubernetes, you know, all have, you know, different life cycles, right? You know, arguably I think Jim still, like Linux is still going up on its graph. It's not in sustained mode, necessarily per se. But we have other projects that may be, you know, kind of in the more mature side house. But the LF, we basically act as kind of a, you know, mutual fund or index fund is kind of the analogy. I look for open source projects because what happens is if one of these things becomes, you know, maybe boring or less relevant to the industry, it doesn't mean the organization suffers because we have different, you know, kind of place here. So that's kind of how we work. You know, I'm not going to dive, but like, you know, when you launch a project, you're all about investing in building a brand, trying to attract as many companies and organizations to the initiative. You know, recently, you know, early this year, we started the Continuous Delivery Foundation, which brought, you know, Jenkins, Spinnaker and Tecton together. And we invested a lot in building this brand. It's a very, you know, website. We've done conferences. We've done CECON and so on. So we invest a lot to kind of build out a community at that launch time. Then we go out and commercialize things. So what we mean here is basically trying to diversify the maintainer base, you know, maybe launching some type of like conformance programs like Kubernetes certified, maybe some training. And then eventually you get to the maintain and sustain aspects of life cycle, which, you know, naturally, not all projects continue to grow forever. So you kind of make sure that, you know, these things are healthy enough that companies could depend on them even though if they're not the most, you know, attractive or popular project these days because, you know, just like products and open source projects, everything has a hype cycle to it at the end of the day. So skip that. All right. I'll talk a little bit about different projects at the Linux Foundation. I think a lot of people don't realize how diverse of a set of projects we have. So this is kind of like a graph, you know, that I use or diagram. I guess the better way to describe it is I kind of divide it into two different axes. So the wide axis is we have projects that are code-based, right? You know, software code. And then we have stuff that are spec-based, kind of like standards. You kind of think of that. And then on kind of the x-axis, we have what I call single-project communities and then umbrella-project communities. We're essentially things like CNCF where you have lots of projects, part of them. And so here's just some examples where, you know, for example, Let's Encrypt, I guess Node is kind of now under OpenJS, but these are kind of like singular standalone type projects. And then we have umbrella projects that host projects under a particular theme, vertical or technology, you know, focus. And so we have things like CDF or continuous delivery, LFAI for AI, OpenJS for all JavaScript. And on the spec front, we have a variety of spec projects. A lot of people don't realize that Linux Foundation hosts spec projects. We have our singular specs, things like OCI and OpenAPI Initiative, which is home of kind of the swagger folks back in the day. And then we have our new kind of organization called the Joint Development Foundation, which is really an umbrella project, umbrella organization for spec-related projects. So, like I mentioned, you know, we have, you know, these kind of code plus single community things. These are generally kind of focused on one particular project. Sometimes they're funded, sometimes they're unfunded. It doesn't really matter, but here's some examples that we have. Umbrella, I think this is really kind of where the core growth for Linux Foundation is. We prefer to kind of bring organizations under one particular focus area. It's the best way to kind of raise money and sustain things versus kind of having just singular things on the side. And if you look at this, we almost have umbrella organizations for every kind of major technology, a vertical out there. There's very few that are missing. So we have things for film, automotive, blockchain, AI, cloud, networking, JavaScript. You know, these are huge organizations that really make up the kind of, you know, brunt of the Linux Foundation as an organization. So, you know, one example for CNCF that we kind of like to use, like, you know, what has the LF kind of done for these projects? Well, when I helped start CNCF in, you know, 2015, it was a very small organization. We had less than 30 members. We all met in this, it's actually, it's our fourth year anniversary. I remember this, we met in a small meeting room in New York City to kick off our first board meeting. It was maybe, it was less than 20 people in that room. It was very tiny. And now, you know, four years later, it's hard to at least get away from Kubernetes. From my perspective, it's basically, you know, every cloud with public-private offers it as a service. Everyone that's building distributed applications is finding some way to support Kubernetes. You know, even like the Hadoop folks are completely refactoring everything. Any distributed system that had its own way to kind of, you know, to consensus and deploy these was all refactoring to rebase it on Kubernetes. So, yeah, those are kind of results. I mean, the other kind of thing Jim very much likes this diagram is Google Trends for what it's worth is good and bad, but you could see, you know, CNCF when it was founded, you know, kind of December 2015 type timeframe, you know, the comparison between OpenStack, Kubernetes, Mesa, I just threw Lambda in there because it's kind of interesting to watch is, you know, once we kind of started getting the flywheel of supporting the organization, building an ecosystem, convincing the other clouds to get involved, launching conformance program, you know, about two years in, a little less than two years, when you notice we basically surpassed OpenStack, you know, Lambda and all that stuff there, and now it's just, you know, quite crazy how different things are these days. And this is truly the role of Foundation to kind of build an ecosystem, build a brand, build excitement and sustain these projects. Hyperledger is another example. I'm not the biggest blockchain person, but, you know, there's a huge amount of community out there, people trying to build really interesting products and solutions on that pop blockchain. You know, the big issue with blockchain at that time was it was inherently tied to kind of a lot of the crypto-related, you know, folks, and what you really needed is a neutral organization to bring together the people on the business side of the house looking to build serious products and solutions, and so Hyperledger accomplished that, and they've grown to over, I think it's got to be close to 300-something members, they have about 350, I need to update that, so Jim knows, he's probably logged into Salesforce recently, but so it basically has almost every financial institution and startup in the blockchain space involved under this, I think, and they're actually building serious things that are actually being used, you know, throughout the industry. I give them a hard time, like, let's use a case of blockchain, and then, you know, Brian Belford runs it, we'll, like, go right off some kind of, oh, it's using to manage, like, the supply chain of, you know, flood diamonds and all that, that was super cool, so, but these are the type of things that, you know, the Linux Foundation helps accomplish in different sub-foundations. Here's our kind of single-spec things. We have a lot of people that realize we host a lot of specs, so, you know, we have OpenAPI, there's the GraphQL Foundation, which I helped launch earlier this year, so these are just kind of samples of what we have built on the specs side of the house, and of course, earlier this year, we also announced the June Development Foundation, which is kind of our umbrella organization for specs, so some of these specs may potentially roll under JDF or kind of interface with JDF in the future, because as an organization, we truly prefer umbrella, you know, foundations if we can. So, one interesting kind of question I get a lot from folks is, like, you know, what's the value of a foundation, right? You know, what do I get out of them where I can't just, like, why can't I just host my project on GitHub? That should be good enough. Well, you know, I think the most important thing you can kind of think about is there really is a value to neutral ownership of assets, you know, like transparency and open governance helps build trust, and if you have a lot of partners you work with, you know, they're going to need that in order to actually build the ecosystem. The reason Kubernetes and CNCF have been successful is because the organization neutrally owns those assets. We as a community come together to build a fair conformance and certification program that everyone agrees to. That type of mindset of transparent, neutral, openly governed organizations, you know, truly enables a positive set, positive sum thinking amongst everyone, in my opinion. No one is fearful that one organization or company will take advantage of them because you kind of have this community of folks working together in a neutral fashion. So, you know, earlier this year we started to produce these what we call project journey reports, which basically try to, like, you know, take metrics, like a matrix of data-driven approach of the value of the foundation, so we did this for Kubernetes recently, and, you know, as you can see, when most open source projects start, it's almost, they almost start where there's like a single progenitor, a single owner, they created it, right? And so if you look at Kubernetes, in the beginning it was mostly all driven by Google, right? And if you look, if you shift from kind of the start in 2014 to five years later, Google now does about 25% of the overall contributions to Kubernetes, and it's a fairly diverse, healthy ecosystem now. What is crazy about this is Google actually did not slow down their contributions, their cumulative contributions to the project have only increased. So they actually have done more work, but the overall slice of the work is only 25%, because what's happened is more people showed up, everyone started to do more work, and to me this is like a core value of what a foundation helps support and provide, and we've started to do these project journey reports for other projects in CNCF, our highest level graduated projects, and this is just an example, when Envoy started out, which is a popular service proxy, it was all Lyft, right? And now it's diversified, where sure, Lyft is doing a lot of the work, but Google came up out of nowhere, started to throw a lot of resources into a bunch of other end user companies and Ali Cloud and so on. So these are the types of ecosystems that we intend to build as an organization. So I highly recommend that you go through these reports because they're very entertaining and it provides more of a data-driven approach to how we look at things. So like I mentioned, why bring your stuff to a foundation? Why not just throw it on GitHub and let things work? So one thing that we do, we actually provide a high level of services for our projects. A lot of people don't realize that the Linux Foundation, we actually have professional staff outside of just like me, we have technical writers, we have people that work in different regions in the world if you wanted to open or reach out to members in Tokyo, in Sydney, in China, all of them work truly a global organization. We help them with infrastructure, we help them with certification and training. So essentially, I think as a foundation, you have to offer more than just purely a neutral home. And the Linux Foundation, and the Toll People, is truly the professional open-source organization where we actually provide professional level of services. We nearly have 200 employees worldwide that work for the organization providing support for our projects. And you can poke around, we've kind of documented what CNCF offers. There's other projects like LFAI that documents it also. So all right, say you want to bring an open-source project to the Linux Foundation, what do you do? Generally, what happens is most projects, when they start, they usually come to us and like, hey, we want to add more developers to our projects. How can you help us do that? And so we have a bit of a process that we have in place. So a couple reasons are, there's like, add more developers or hey, can you help us host an event? So a lot of people don't realize, Linux Foundation, we kind of have events as a service, right? So if your community like GraphQL, Node, Presto, Kubernetes wants an event, we host an event for you because guess what? Events are some of the best ways to kind of build communities. You get a bunch of developers in the same room with new people that may be interested in the project and kind of magic happens. KubeCon started with, you know, a few hundred people in a room and now, you know, was it like a month ago, we hosted KubeCon, there was 12,000 people so building these type of communities through events is super useful. And of course, we were a neutral host for intellectual property. So this is another way, another advantage to the LF, you don't know how people from there are told story, but essentially like what actually for my career where I realized I've been involved with Apache Foundation, Linux Foundation, a bunch of these and the LF way of doing things is, you know, I'm a firm believer in the source project. The project out there is kind of unhappy in their own unique way and there's truly like, you can't just have one way of doing things. You have to customize each project for what it wants to accomplish. And the LF really does that. We don't have this cookie cutter one approach to build the foundation or ecosystem. We personalize it for each proper project. So that's kind of my, the LF way is that there is no way to work with each project individually. I don't know if Jim likes that, but that's not what I would say. That's great. Classic. So what are the basic hosting requirements if you wanted to bring a project to the LF? One, you know, you have to have an OSI approved license, right, stuff, no I won't. Supported by the Linux Foundation member, you know, we have 1,600 members, sure you could find someone to support a project. Complete neutral ownership of all assets. The trademark, GitHub accounts, CICD services, domain, these all become managed by the LF IT organization, right? Because if you don't give that up into a neutral entity, you could have one company, you know, for example, I don't know, you know, Google, right? You know, Google owns the Istio project, right? So they get to decide how that trademark is used. So if you depend on them, you got to be careful. So the trademarks are very important to the community. The most important thing that we kind of stress is, you know, we live by the technical democracy model and what I mean here is anyone is welcome to contribute to the technical projects. Membership is never required. All membership is for is to raise funds, to help sustain the project, to host events, pay for security audits, whatever. So membership is completely orthogonal to communities and so we require this on every project that we host. So like I mentioned before, the LF way is that there is one way, so all of our projects come in all shapes of different sizes. Some are very small, you know, and some are very large like Kubernetes. We don't really dictate one size. Everything is different, so we kind of customize to kind of work with you. Trademarks, like I mentioned, a lot of people don't understand this fact that, you know, if you don't have the trademarks in a neutral organization, they could basically prevent potential people in the ecosystem to use that name, especially if they're building Kubernetes as a service. You know, hey, you know, Microsoft is your Kubernetes service. If that trademark was not owned by CNCF and government in a neutral way, Google could just say, you can't call that, right? That's not fair. That's not how you build a good neutral ecosystem. Ownership is good, and this is something that almost all open source foundations do is do a neutral ownership of those trademarks. You know, I'm not going to dive into this kind of detail. You could go look at this either, you know, by yourself if you actually wanted to bring a project to the Linux Foundation. Like, here are usually a step of, like, project preparation we require. It's like, identify your internal stakeholders, ensure your IP is clean, and then so on. So this is just something we work with when we kind of work with each project on a neutral basis to figure out what's right for them. Like I mentioned, we try to push people a lot to move projects to umbrella organizations because, you know, think about it. If you have an AI project, you know, why do your own thing when there's already something called LFAI? Or, hey, you have something for the automotive sector? Great. We have the Automotive Linux Foundation. So generally, we are pushing more of our projects under these umbrella things, and the way that organizations work is they usually have lots of members. They all pull their resources under a single thing to support all of our projects across that specific umbrella organization. We have standalone projects also don't necessarily always like to go this route, but, you know, we work with each community to figure out what's best for them. They generally have a very lightweight structure. They just document their governance via a technical charter and they kind of go out on their own. The important thing that I mentioned that, like, I have to sometimes correct people is, you know, all of our projects and you want to contribute technically, the membership dues are only there to pay for, you know, events, security audits, things to sustain the project. So, you know, some people say, oh, you know, you have to pay to play to participate. I'm like, you know, you could just contribute code. There's no one preventing you to contribute code to Kubernetes. You don't have to be a CNCF member. I have plenty of members. Like, for example, Lyft, that diagram I showed you earlier, is not a CNCF member, but Envoy is literally one of our most projects. You know, they contribute heavily. Like, there's no membership gate ever to contribute to our projects. Members join to sustain the overall ecosystem. Lyft doesn't member absolutely, but it's not a requirement by any means. So, for me, I say it is a pay to sustain model that we employ at the Linux Foundation. Bootstrapping a community project. I'm going to dive into details about the kind of a process of trying to bootstrap a project where we work with internal and external stakeholders to make this happen. A lot of people ask, all right, Chris, you've said a lot of things. What is this simple flow chart you could show me to like bring a project to the Linux Foundation? It's basically this. So, if you can already fit under an umbrella organization, go put your project there and try to put it there. If not, come to us and we'll see what we can do custom. A lot of our organizations have these landscapes. So, I don't know if you saw the CNCF landscape or CDF landscape. Almost every umbrella foundation has some form of landscape. If you see your project there already, that's probably a good natural home for it. Here are some examples of, you know, two CNCF projects Work and Helm came in. Almost all of our umbrella organizations have some kind of technical steering committee, technical oversight committee. We have a group of independent people that are responsible for the technical direction and which projects get in or not. So, they all have different processes, but everyone basically submits a project. People vote and eventually gets accepted or rejected. Onyx joining LFAI, they have a very similar process. People propose and they vote on it. OpenJS Foundation recently had Electron joined. There's a whole process and people vote through some technical body. That's just some examples. So, here's a bunch of umbrella organizations as I mentioned. You could go look this up when I give out the slides, but any types of projects for specific verticals or technology areas please start there versus trying to do your own thing. Alright, some basic tips to kind of before I kind of end things and I'll open up for any questions. So, very simple. Choose a freaking reasonable license for your project. Don't use any custom licenses. There's been a resurgence of these kind of open core licenses out there. Avoid those at all costs. Just use an OSI. Approve license. Preferably permissive in my opinion. License scanning. Use things like physiology, FASA, SNCC. The tools are so much better these days than they used to be. Please take advantage of them. Anything that helps us have more clarity into the licensing of your software supply chain makes all of our lives significantly easier. It's so much better than it used to be. DCOs are always good. I'm going to go too much in detail. One of the most important things that I think the Linux Foundation provides that a lot of people don't realize makes you require this for CNCF is there's something called the best practices badging and it's like it's like a checklist. I don't know how many people read this. There's a great book called the Checklist Manifesto out there where essentially what doctors and medical professionals do to make sure they don't leave a scalpel in someone. This is kind of like a similar thing where you have a checklist for good things that you should have for your open source project. Like a mailing list. A clear licensing how to report security issues and so on. You kind of go through and go like a checklist. It works pretty well. You get a badge. We require this for all of CNCF projects but we would like to see all projects throughout the industry use this because this is a really good set of practices. Yeah, I mean you know it's not just code. You need to build inclusive communities so you know my advice is make sure your communities are inclusive to people who do community management, host speedups do technical writing design to great ways to contribute to build our community. We have some examples in CNCF you could learn of in terms of how we do our meetups. So just like the licensing scanning tools out there. Holy I know the security scanning and disclosure tools have greatly improved. GitHub even recently announced built-in security disclosure and advisory mechanisms inside of GitHub itself. Please have this process for your projects. This is like a high quality important thing to do on your end in my opinion. And then finally Jim mentioned this so I'm not going to go over it. I spent a lot of my time to help co-found the 2D group. The best way to learn about open source program management is through your peers. And we have a great peer network. A set of materials these are even translated into Japanese so if you go to linuxfoundation.jp slash resource open source guides you get the Japanese translation of these guides. And other than that so final thoughts here linuxfoundation is more than just linux you know we host so many different projects of all sizes from spec code. I truly believe there is no one way to build a community for a project it has to be very custom based on the needs of the organization. And the linuxfoundation is one of the premier open source foundations that does this type of work. There are others but I think we are probably the largest out there and most professionally run in my personal opinion. So if you're interested in bringing a project to linuxfoundation there's a great URL and you can feel free to find me or email me and I'm happy to answer any questions so thank you.