 All right, everyone, I'm thrilled to be here and excited that our focus is for building for the road ahead, because for some of you, you may not know that I'm actually a hobby mechanic. I love cars, I love taking road trips, and many of my road trips I've been on have been truly remarkable. My cloud native road trip, however, I've met so many amazing projects and incredibly driven people whom, to me, many of them are considered open source mechanics. So I want to talk about how do you become an open source mechanic, what they are, what it is that they do, and how we make our cloud native road trips great and how we make them possible. Well, in my travels of late, I've been seeing a lot more potholes and roads closed and congestion in cloud native and in other communities, because we're not the only ones that are struggling in this regard. So what do we need to do? When we have a cloud native car, we're going on a cloud native road trip, we have to account for things that are unpredictable, like potholes, roads closed, congestion and traffic, flat tires, but there are things that we can actually do to plan and prepare that will help us consider when those events happen. Things like are you staying in hotels on your trip or are you camping? Are you taking a gas powered car or maybe you have an EV? Is there infrastructure in place for you to charge your car along that trip? There's a lot that goes into this. And you also want to bring all of your friends with you because a cloud native road trip or any journey is better with people that support you and can help you make it the best possible. But you don't want to be the one that's stuck doing all the work because then you don't actually get to enjoy any part of the trip. You're not spending time with anybody, you're not learning new things. So what we're starting to see is that the proportion of contribution to usage of cloud native projects and open source projects is actually not sustainable. If you were to consider a project Slack channel and look at how many people are in there, then you look at the stars and the downloads associated with those projects, maybe they've got an adopters file and there's a ton of folks in there, and you do a little bit of back to the napkin math around who's actually contributing. And by the way, that's just the commits. There's a lot more contributions that happen outside of GitHub. It's probably less than 5% of the people that are using these projects and applications that are actually contributing back to them. And that's pretty normal, unfortunately. But we also need to consider that not everybody in the world is capable of doing this work. And it's not that they don't want to. It's just when you have too many mechanics working on a car, it doesn't get out of the shop any faster. Sure, there are some jobs that take one or two or maybe even three people. But if you have a lot of people helping you and they have jobs to do, you can actually get more jobs done faster. So we need to consider how do we balance contributions to projects versus the usage that they're taking on? And it's going to be unique to each project in each community. What are their governance? What are their processes? But realistically, with so much adoption happening in our ecosystem today, there's an onslaught of help requests and feature requests because there's so much more adoption. We've been successful. So when this happens, we start actually missing engagements, which means we don't get as many contributors anymore, which means less contributions, less features actually being completed, and then your adopters start leaving because they're not getting what they want out of the project. And that starts to lead into project crisis. Well, with this onslaught of requests for help and assistance and new features, maintainers are getting burned out. They can't keep up. And burnout is an indicator that things are going downhill the wrong way. And when you're the only person pushing your cloud native car uphill, it's probably kind of come back down on you and you're going to need to run out of the way fast. And it's not healthy. So what I'm seeing is the same challenges repeated over and over and over again. We have people that show up. They want to help. But there's no information on how do you rotate drivers? How do you contribute to a project? Or what work needs to be done? So they leave. And then there's other people. You've probably seen them. I know I'm guilty. Hold my checklist. I got it. That's who they are. They're there. They're in everything. They're in a single project meeting. You see them doing all the notes. You see them reviewing all the PRs. They are the backbone of the project that makes it successful. But then something happens to them. Maybe they want to take a vacation. Maybe they were in a car accident. And now they're no longer available. The entire project can start to unravel if there's no one there to support them and to pick up those pieces. Or you're a maintainer. You're so busy, you can't respond and give anyone the proper time to provide a good response to the PR that they just opened, especially if they're a first-time contributor because that feedback is so essential. That means, as a maintainer, you've become your own roadblock. Contributions are the fuel of any open-source project. And they help keep your cloud-native car moving down the road. But those three experiences I just highlighted are going to slow down your cloud-native road trip like a flat tire when you've got no spare, no fix-a-flat. You certainly do not have an air compressor in the back of your car unless it's an abbreviated. So we have to prevent these experiences from happening, but how? Well, everyone is struggling in the CNCF, other foundations, and projects outside of foundations, too. We need to find a community and we need to keep it while unburdening our maintainers, or we're going to start seeing more and more cloud-native cars sitting on the side of the road abandoned with all plans for a fantastic journey left on the term pike. So find a community. They're self-forming, but they don't actually pop up on their own, which means you have to do something with them. Well, how do you do something with a cloud-native project? Check out the contributing file. How much information is in there and do they have any information about beyond just code contributions? You can also look at their ReadMe. If you remember the early days of technology, ReadMe was the thing that told you what the software that you just downloaded off of the internet was and how to use it, how to install it, how to maybe add the license to it. Your ReadMe for open-source projects is the roadmap for your potential contributors and adopters to understand everything there is to know, not only in how to use it, but how to become involved. What about your issues in PRs? It's important that you have issues, that you're using labels, and labeling things like withgoodfirstissue.dev. Shout out to Chris Anacheck for letting me know about this. If you sign up as a project and you have good first issue on there, this is a resource that will help people discover what some of those problems are. And the PRs, as a maintainer or maybe as a contributor to a project, you can review PRs, provide constructive feedback. That's what helps people come back each and every time. And there's a lot of research out there on what is that first-time contributor experience look like. So there's a lot that goes into finding a community, but how do we keep them? Well, just like with CARB, you just got one. You have to actually maintain it, which means keeping those docs, guides, and all of that great information up to date. But you also need to ensure that you are engaging your community members. If somebody shows up in a Slack channel or a meeting with a brilliant idea, don't just write it down. Invite them to take it on and champion that work. And maybe call out Hisham and Barbara to help them out. Be specific. You can see everybody that joins a Slack channel. You see their name. You see their handle. Tag them on an issue in the Slack channel. Say, hey, can you take a look at this and give me some feedback? And then check in with them. Maybe schedule 30 minutes a week to follow up with folks. That allows you to collaborate and celebrate a lot of the contributions that help make these projects amazing. It's not just about maintenance. There's a lot that goes into community management. The maintainers, quite frankly, they're doing everything. They're being asked a lot, and it continues to happen. They're building the car. They're maintaining the systems to build it. They're their own safety inspector. They're their own manual writer as well. And that's a lot for two people, let alone one person, because there are projects that still only have one maintainer. You all here are the best person to help these projects. You're looking to them for your use cases to help solve. And therefore, with your fresh set of eyes, you can file issues to improve the documentation, improve all of that information associated with the project for the next person that comes behind you. And one thing you need to remember above all else is that you all here in this room today and online are the vehicle of change that can help balance the proportion of contributions and usage that keep these projects moving down the road. You've made the decision, or perhaps somebody made it for you, to invest your time in using these projects and integrating them and making them a part of your project or product, business, or organization. And these investments, they require work. So pick up your tools, find a community, help keep it strong, and unburden the maintainers. Go to contribute.cncf.io, join a project, and assign yourself an issue. Be the open source mechanic that this foundation and this community needs. Thank you.