 All right, let's get started. Hello, everybody. My name is Jeffrey Sika, but most of the people in the community know me as Jeefy. Long story short, someone misspelled my name 20 years ago and it's stuck. I happen to be a Kubernetes contributor. I also happen to work at the CNCF. So I've got kind of an insight, both from the community perspective and also from the inside of the foundation perspective on how best to start your contributor journey, how best to give back to the community and work with projects. So the name of this talk was CNCF Landscape. That can be somewhat confusing because there is actually a project called the CNCF Landscape. So I'd like to rename the talk to the CNCF ecosystem. How best can you learn a path to contribution within the ecosystem of the CNCF? First, I like level setting. I like making sure everyone has the same kind of foundational knowledge before we start. So let's kind of talk about what the CNCF is and why. If you already know some of this, I'm sorry. If you don't, welcome. The CNCF is a nonprofit foundation under the Linux Foundation. The Linux Foundation has quite a lot of other sub-foundations underneath it, as you have seen throughout this conference. We have quite a large list of graduated projects. The one that everyone tends to know is Kubernetes. That was our first project, and also the first graduated project. Under the Linux Foundation, like I said, there are a lot of different other foundations, and they all have a different specialty. So there's OpenSSF, which focuses on security. There's CNCF, focuses on cloud. As you've seen, automotive grade Linux. We try to identify different sectors, and then usually there are open-source projects that we want to try and help enable, so there's more options within that sector. The CNCF itself has three main pillars, as we call them. There is the governing board. The CNCF governing board primarily focuses on budgetary issues, marketing, and overall governance of the whole foundation. There is what's called the Technical Oversight Committee, or what's known as the TOC. They are an elected body voted on by maintainers within the community, and they are the group that will look at projects that apply to join the CNCF and decide whether they should join, whether they might make more sense within the CNCF sandbox. We have different levels of projects, or whether it's a project that's mature enough that it should go into incubating. A good example is Istio or Knative. They joined at the incubating level. They had also been around for quite a long time, whereas some other smaller projects or projects that a company might just want to spin off so they can get contributions from multiple companies, that might just go into Sandbox. Under the governing board, there is also a small group called the Marketing Committee, and they are the group of folks that help us with doing things like white papers and use cases, case studies, and et cetera, et cetera. So one of the greatest things about the CNCF is we are meant to be a vendor-neutral home. So projects that get donated from one company aren't just worked on and maintained by that one company. They are also worked on by multiple companies. The whole idea here is a rising tide raises all ships. It's not a zero sum game, let's actually get everyone together and collaborating and then make everything better. Like I said, TOC, the Technical Oversight Committee, tends to drive the technical direction of the CNCF. The CNCF has a dedicated staff of folks like myself. We have different specialties. Like I said, mine is in community and contribution, but we also have dedicated marketing folks. We also have dedicated tech docs writers who try and help with projects to make sure that their docs are up to snuff. We have developer relations folks to try and evangelize, not just a single project, but the whole ecosystem to, again, try and grow the community as much as we can. If you're here, maybe you know about KubeCon, the same events team that puts on Open Source Summit also puts on all of our KubeCon, so they are just top notch. Hopefully you can see that here. KubeCon is like this, but an order of magnitude larger. So, like I said, there is another project in the CNCF called Landscape. It's not a CNCF project, but it's kind of an internal application. Have to show it. It kind of shows a story of how much we've grown and also how much the landscape has evolved. This was taken in late 2017. This is not just showing projects that are within the CNCF. This is showing all the projects that want to join. That's poor phrasing. All the projects that feel like they are in the ecosystem, whether they're Open Source or not, whether it is a company project, whether it is closed source pet project, you can actually submit a pull request to join the CNCF landscape. And in 2017, this was already kind of large and kind of hard to read. That was taken July 2023. So in six years, it's probably gotten four or five times as big and even worse to read. Now, you can kind of see, let's see if I can actually do this with my mouse. There are some projects that are highlighted. And those projects are the ones that actually are in the CNCF. But this is still very difficult to digest. Lots of memes have been made about how awful this is. We are still trying to work on it. We have a new version of the landscape that is coming out. Yes, this is still difficult, but the filtering ability is going to be improved. You'll be able to actually directly link to certain pieces of information. Most importantly, there's actually a search bar. I'm not trying to sell the landscape, but we're trying, we're trying to improve things. So in addition to the technical oversight committee, we noticed that there were issues or there were certain areas of expertise that we saw common across all of our projects. And it made sense to kind of collect this expertise to be able to have informed opinions on certain things like storage or networking. And if a project was coming into the CNCF or looking to apply within the CNCF, we could have this group of experts come to the project and also assess it. We shouldn't expect the technical oversight committee, though they are very well-known community members. We shouldn't expect them all to be experts at networking or all become experts at storage. So these tags or technical advisory groups formed so that the TOC could have resources on the ground, yeah, resources and people on the ground still working within the projects that can do things like assess a project's ability to match certain criteria for networking projects. Make sure that it passes the SNF test to make sure it actually is a solid project and not something that's kind of vaporware. Because the CNCF is a foundation where a lot of projects want to join, we wanna make sure that the projects that do join are of a pretty high caliber. So it's kind of, I won't say painful, but rather involved to apply to join the CNCF as a project. But what we get out of that is most of our projects tend to be of a pretty high caliber. The tags certainly help with that as well. So these are kind of the four, sorry, eight tags that have formed. Creating a tag involves the TOC coming together and identifying a new space. So this doesn't really change often. And if you work within the cloud native space, you know that each of these is something that is considered a kind of large area to be an expert in. The CNCF provides a lot of training and certifications. The CKA is kind of the exam that everyone in the ecosystem knows. It's very, very high class. It also tends to be very difficult to pass. So it helps people early in their careers kind of get a foothold into joining one of the many places that are hiring Kubernetes experts. But also not just certifications. There's also a lot of free courses that we offer to kind of get your foot in the door. Of course, we have KubeCons, yay. The next KubeCon is going to be in Europe in 2024. That will be in Paris. The next North American KubeCon is going to be in Salt Lake City in November. And I think it's going to be a Kube day is gonna happen in Japan in 2024. Not a full blown KubeCon, but stay tuned. We also try to enable a lot of meetups, not just large scale conferences, but we want to enable local meetups. I myself used to run a meetup and it's how I even got here. Like I would not have become a Kubernetes contributor had I not gone to a meetup and met a friend who was also a Kubernetes contributor. There you go. So happy to say that the cloud native community Japan who one of our organizers is here. Thank you, thank you. Well, two of our organizers are here. Thank you, thank you. Just met on Friday, packed room. Please, if you are local, look into this, join. The best way to share ideas and share knowledge is at local meetups. Most of the time, the larger scale events tend to have hallway tracks which are just essentially meetups. And so being able to meet and share the latest things every month or every quarter is super helpful and invaluable. So that's CNCF foundation. I am an employee and have to tow the party line kind of thing. Now I can talk about what I really care about which is contributing to our projects, contributing to the CNCF. Like I said, I started as a Kubernetes contributor. So I feel like I have an insight or two into how to contribute, also why to contribute, how to justify more time contributing. It is all connected. And also, communities strengthen contributors. Like I said, meetups and exchanging knowledge, telling those stories, that is super helpful. This is from KubeCon in Chicago. We have a Kubernetes contributor summit. All of the contributors get together, have a good time, but we also try and share knowledge and keep each other relevant, keep each other up to date. It's super helpful. So I wanna start with a couple key things that people who just want to submit a pull request to Kubernetes or any of our other projects, they might not understand and should try and keep in mind. All of our projects try to defer to being out in the open. Say you are interested in a specific GitHub issue or you see a pull request and you have a comment that you want to give to the author. You should probably do that in the open in either one of our Slack channels or in GitHub itself. I would defer to GitHub, but DMing someone is probably not a good idea. You want to make sure that as much of your communication is done in the open so other people can see and learn from it and also so maybe someone that you are not directly trying to contact also has a comment and can respond. It's better to be out in the open because it's also more collaborative. A lot of people talk about burnout. I am one of them. I am a major advocate of trying to avoid burnout. So the phrase that's a marathon, not a sprint, very good thing to keep in mind. Make sure that you are trying to pace yourself and not push something immediately over the line. I know that's kind of difficult and there might be external factors pushing you, but mental health is a serious thing that I like making sure it's safe and it's healthy and we are kind of good. Also, assume positive intent. Maybe you submit a pull request and that pull request happens to get a snippy or you might interpret a snide remark. Maybe the person's having a bad day. Maybe they don't have a full, like there might be a cultural difference between what you are saying and what they are saying. If you tend to always assume that someone has their best intent, even if they don't, it's a lot easier to navigate a multicultural worldwide organization. This is something that some people think is common sense and common knowledge and just generally nice to do, but it's also worth really calling out. All of our projects have a code of conduct. This kind of falls in line with what I just said, but it's actually codified. You can go and read it. It's in my slides. I'll make sure the link is available. What it boils down to is don't be a jerk. Don't call someone names. Don't say someone is stupid. Like you want to try and be nice to everyone because again, everyone working together tends to up level everyone in general. Projects have community meetings. Tags have community meetings. The TOC has community meetings and this is one of the great ways to start looking at a project and see if there is a place for you to contribute to. Say you are really interested in storage, like high performance storage, and you look through the landscape that I just showed and you see, oh, there's a project called Longhorn. Longhorn works on storage. Maybe I can work with that. You can find a community meeting for Longhorn. Might be every week, might be every month, but it's somewhere in between there and just hop in there. All of our community meetings are supposed to be in the open. They are almost all of them recorded and put online in their respective community YouTube channels. And one thing that I like to make sure everyone understands, lurking is fine. In fact, I would encourage lurking at first. Most community meetings, I say most because all the ones that I attend do this, but in the beginning they'll say, is there anyone new? You can introduce yourself if you want. If not, that's fine and you can just stay muted. You can stay camera off and you can just listen to what they're talking about. This is extremely helpful if you're trying to figure out what this project is really trying to focus on. If you as a prospective contributor goes to this Longhorn meeting thinking, I want to really improve how the CSI driver of Longhorn works with Kubernetes and then you join the meeting and find out, no, there's like these three other things that are on fire. Probably doesn't make sense for you to then want to contribute to that weird, not weird, but change that they're not necessarily focused on. In that case, maybe there's something that you can do to help all these other existing maintainers. So again, lurking is a really good idea to just start embedding yourself in the community. Another thing that I'll say is consistency. If you attend these community meetings, keep attending and then if you start, I don't know, asking questions, make sure that you keep attending. People that continue to show up do get noticed and in fact it's the people that continue to show up even if they are doing minor contributions or smaller contributions. If they show up every month, you start being kind of expected to show up every month and you start I guess not necessarily getting relied on but you build a rapport, you build a trust. I mean, this is how almost every contributor and friend I have in the community has kind of grown as a contributor and into a maintainer. They would just continue to show up. So it's again, better to do smaller incremental changes just like you would expect with code bases. It's better to do smaller incremental changes to build rapport and build a community than it is to try and do this huge pull request and then be like, I'm a contributor now. It's like, that's actually not necessarily a good way to become a contributor. All of our projects fall under a CLA or a DCO. CLA is a code license agreement. A DCO is, I don't even remember, developer certificate of origin. This is partly because we are a vendor neutral organization so if we have, you know, the Googles, the Microsofts, the Amazons, all contributing to the same project, we want to make sure that it stays vendor neutral and one of these companies, not even the three mentioned, could come in and potentially sue us saying, no, that's ours. We want to prevent that. We want to make sure that this is a safe space for open source collaboration. So like I said, CLA is a code license agreement. This is usually done at the corporate level, the company level, whereas DCO is just you saying, I am a single person, here is my email address and I am okay with this commit being part of a project. Many projects, many of the larger projects have this idea of enhancement proposals. Kubernetes is one of them, for better or worse. I will just say that but Kubernetes and things like Python, this isn't just a CNCF thing, they have this idea of an enhancement proposal and what that is is if you are making a large change, I will use Kubernetes as an example. If you're making a change that goes across multiple different SIGs or code bases or focuses or it might impact a release, you need to write a rather large document that explains what the change is, why you're making the change, how you're testing the change, how the change will graduate from alpha to beta into stable, how you are going to test the change, if the change breaks, how can we back, get rid of it, revert it, they are rather in depth and then every single area that this code might impact has to get sign off from the people that own that code. Now, that can be really frustrating. I know, I have written several but when you look at Kubernetes, Kubernetes is in satellites, it's in fighter jets, it is in cars, we actually need a certain level of stability and this is currently the project's way to make sure that large changes don't necessarily cause problems, try and get them done as or catch them as early as possible. So, yeah. All of our projects, we require to have some form of governance and that can be as simple as we maintain a markdown file of our maintainers and if a maintainer changes, we update the markdown file. So, it can be that all the way to, again, picking on Kubernetes, there are full blown elections every year for the steering chair or the steering seats, they have a steering committee and that's how they do their governance. So, that's kind of, in general, if you look at all the patterns across CNCF, ways to not necessarily just join but also gotchas you might get, I know I have heard across different communities in different regions, some difficulties in how do I join a project, what project should I join? I will say, always try to stick with what you are strong in and also don't necessarily immediately try to work in Kubernetes. I think I say this again later but it seems like something worth repeating. A good example, if you're learning guitar, you're not gonna immediately start playing in Metallica, right? It's going to take time for you to develop your skills, develop how you interact with the community, also develop your technical skills, even if you think you are the greatest engineer in the room, you're going to find someone that is better and is going to critique your code and that's okay but being able to accept that critique and know, oh, this is something I should do in the future and learn from that, it's usually easier to do in the smaller projects where you can have a more intimate, more I guess community feel, whereas if you just start working in Kubernetes, it's kind of like trying to jog along a freeway, it can be very frustrating as some people know. So why should you contribute to open source? Why should you have your engineers contribute to open source? And also, how can you justify more of your time in open source? I came up with this story. This is not just a G-Fee made a silly story up, I have seen this directly happen twice. So I didn't come up with any witty, fun company names, I just, company A and company B. They both use an open source project. I'm not gonna name a specific project because I don't want to pick on Kubernetes anymore. Their business depends on the stability of this project, but they're not like reselling it at all, it's more a platform for their product. And we'll just say this project is Lama Pack. Unfortunately, Lama Pack recently released 1.7 and there is a major regression bug. If it gets too much traffic through its service, it unfortunately crashes the Kubernetes cluster. That's probably a bad thing, especially if company A and company B are doing anything to do with networking and they certainly are. They are also both unfortunately affected. So company A does not regularly contribute to Lama Pack. In fact, they do not have any in-house expertise aside from one person, maybe two people that manage their Kubernetes cluster and installed the Lama Pack Helm chart, shall we say. So they are unfortunately not really invested in a project that their company relies on. Company B actually has a maintainer within the company. They give them 50% of their time to focus on Lama Pack because that company recognizes we rely on Lama Pack. Lama Pack relies on Kubernetes. We should probably foster some sort of expertise in-house. We should also make sure that contributing to Lama Pack is something that we are, I guess, focused on and hey, we're giving back to the community. So what does company A do when they find out there's this major regression that their cluster crashes, there's a huge problem? Besides flailing and freaking out, we'll just say company A will probably go back to an earlier version of Lama Pack, assuming they can. Maybe this project doesn't really gracefully allow rollbacks or maybe they're going to have to spin up a whole new Kubernetes cluster, go and reinstall Lama Pack 1.6. whatever and then wait until there's a new patch. That could take weeks. We don't know Lama Pack's release cycle. We don't know this. I also didn't think about that in my little magical story. But the point is company A is completely on their own. They have to wait for this open source project or a company that they may be using for hosting to fix the problem. That's not bad, but that certainly means that you don't control your own fate and that is problematic in my opinion. So what does company B do? Well, they have a maintainer of the project. They can have that maintainer file an issue, an existing maintainer, unspoken thing that I will say out loud, an existing maintainer files an issue. Most other maintainers will read to that issue first. They will give that issue more weight. They will actually say, oh, this is a problem, we need to fix this. On top of that, you know what an existing maintainer can do? They can pretty easily take the raw source code, package it and then they could have their company run a fork until an official release comes out when that patch instantly dropped or when the code is patched but they haven't cut a release yet. So company B is in a pretty good place. They are fine. They may have some downtime. Everyone should expect some downtime. That's a disruption budget, but honestly, that they're gonna have a lot less downtime and they're also going to be up much faster. They are going to be able to have also a greater impact in the community as well. So like I said, benefits, if you were looking for reasons or ways to contribute or justification, it's actually de-risking your company's reliance on open source software. I am happy, fuzzy feeling guy. I like building communities. I like the technology, but I also recognize that businesses need to make money and justify spending money. So this is one of the biggest things that I think you can take back to companies and say, allowing me to contribute to open source, especially projects that we rely on, it makes sure that when we have problems, we can address them faster and get back up sooner. And also we are giving back to a large community because open source is a large community. On top of that, when you have maintainers in-house, you are also developing that in-house expertise and I'm not just talking about the open source project. I'm also talking about the programming language that the project happens to be in. I'm also talking about different build systems that the project may use. Like all of these ancillary third party systems around the project, your developers wind up getting to learn. And again, you're fostering community relations with that project. If company B files an issue, even if it's not necessarily from that maintainer, other maintainers within that project, no company B is actually contributing back. And so they're going to get their issues looked at sooner. Again, unspoken, quiet thing out loud, but it's still worth saying. On top of that, you are just up leveling engineering talent in general. By that I don't mean you're in-house engineers. I'm also talking about recruiting. If you were contributing to open source communities, it's a lot easier to find really talented people because the open source community tends to bounce around companies, but all the companies that actually do open source, not closed source. And lastly, kind of hard to quantify, but tangible marketing benefits. Company B can run around saying, we helped fix this bug. We contribute open source. And all they have to do is have an engineer work with an open source and they get larger marketing benefits and they get fuzzy, warm feelings that they can kind of shove in other people's faces. And everyone really likes that. I think everyone that wants to say that they make the world better, that's a pretty good line to put in marketing material. We help build open source projects. So what's interesting is if you look at Japan, Japan really likes open source projects. Actually, yeah, this is starting 2020 and looking at, this is public GitHub data and this is not just the CNCF. Like this is me with my open source contributor hat on not CNCF shill. You can see that open source in Japan is just continually growing. And not only that, it is projected to grow even further. I think it's super hard to read. Right now in 2023, Japan is ninth and come 2028, you are projected to be sixth. That's crazy. And this is like global data public but global data for all of GitHub's public commits. Like open source in Japan is crazy. And I think unofficially, but it was like projected to go even higher in 2029. But I mean, this is looking at previous data, who knows? But still, the hard fact is year over year, Japan is contributing to open source 33% more year over year. So back to where can you start? One project that the CNCF has built is this kind of search portal called cloattributor.dev. Each project has GitHub issues and they can flag an issue as a good first issue. This is something where if you have some technical expertise or if you were good at writing docs, pretty entry level issues that you can work on. You can also visit this website, put in something like Rust or Golang or search for different criteria to find something that you were not only interested in but also pretty strong at. But that's kind of basic. Where I would suggest most people go is look at the glossary. The glossary is a set of terms that if you are not within the cloud native community, it can be rather frustrating to navigate. Also, there might be translation help that needs to happen. So if you happen to be bilingual, that is super helpful. But I already know that there is quite a lot of work being done just to translate from Japanese to English. But I'm also talking about other languages because again, I'm not just focused on a single community or region. I want to see this get as global as possible. Like I mentioned, maybe don't start in Kubernetes. Look at some of our smaller projects. It will be a lot easier to enter into the community, become a contributor and even become a maintainer if you look at the Sandbox projects. And incubating as well, but incubating is kind of, some can be very difficult, some can be very easy. Sandbox tend to be smaller projects that are also easier to run at home, run on your laptop and develop with and maintain. Lastly, another link to local meetup. Local meetups, again, are not just a way to share knowledge about what I did at work. It is also a way for contributors to meet other contributors or contributors and maintainers to meet other people that happen to be interested in contributing and have a very good idea of, oh, well, I read this issue last week about this network thing and you said that you're really into networking, let's look at this together and you might be able to make someone's day and make them a contributor. Lastly, I was never a Boy Scout, but Boy Scouts have this idea of, you know, leave the world better than when you found it and that is open source in a nutshell. It really is trying to make everything in everyone a better place, just by kind of being yourself and doing things that you're interested and passionate about. And the last two slides have had a video game series template because that video game series has a thing called social links and really open source is all about building communities and friendships and so I felt like it was kind of relevant and on the nose, so that's pretty much it. Thank you, I don't know how much time I have for questions, but if there are questions I'm happy to answer them, if not, happy to reach out to me. Questions. Questions, I prefer questions, I hate just talking. Are there any requirements for the projects to become a sandbox or incubator, you know, add it as an incubator? Sandbox, no. When a project applies to become a sandbox project, the thing you have to know is this is the, oh, so the question was are there requirements to become a sandbox or incubating project? Not really, but the process has some very specific things that projects should be aware about. You are donating a project, once you go through the application process and it's accepted, that project become the IP, the trademarks and all of that become Linux Foundation and CNCF. So you need to understand that if, say you're a startup and you're like, this is a really cool project and I wanna make it a CNCF project, that's no longer that company's project, that is that you are giving that to a foundation and the community, so making sure that they're aware of that is good. Otherwise, make sure that it's in like the cloud native space. If you're developing a terminal, maybe don't donate it or have it apply to the CNCF, but no, there aren't really any other requirements. The biggest thing is to eventually become a CNCF project, you need to have the things like governance, code of conduct and the other things that I mentioned, but like required language, no, nothing like that. Any other questions? We have an example of company A and company B. So in case of company B, they are using any open source in their project and what if the expert at company B don't know the solution in the new updates? So is there any chance or any team in the open source project who can help in the company B or that company and that open source project team might work together to solve. So is there any platform or something like that? So you're asking, say the maintainer and company B doesn't understand the problem that, in that example, I'm actually assuming company, the maintainer might not know the answer, but part of the benefit of having a maintainer even if they may not know the answer is when you file an issue, you might also know one of the other maintainers that does know the answer. So they can kind of reach out via Slack and go, I've noticed that our Kubernetes cluster is crashing because of this thing. Do you have any other info on that? So part of the benefit of having that maintainer is also their kind of social network and their ability to reach out to people directly. Cause if someone from company A just reaches out in a Slack channel, depending on the size of the project, that Slack channel might get missed or ignored, unfortunately. Whereas if someone that is a maintainer shows up and asks a question, they also know where to ask that question. They know who to potentially add. And also they might know who to assign the issue to in GitHub. There's all of that insider knowledge. It's super helpful when you have a maintainer and you have something that is causing an issue. So it's like, when... Yeah, having insider info on how to debug the issue, how to phrase the issue. If there's an issue template, they don't have to navigate it. They just know how to fill it out. There are very tangible benefits to I have run into a problem in my company and it is because of this open source project. I should probably ping person A, who is a maintainer. So it's like win-win kind of intuition. Yeah. Thanks. One minute left, I think we'll call it there. Thank you all. If you need or want to reach out to me, my name is Jeefy, J-E-E-F-Y. Pretty much everywhere on the internet. LinkedIn, Twitter, happy to chat. Like I love this stuff. This is kind of my passion. So I'm kind of happy to be here. So thank you all.