 Hello everyone. So just going to quickly introduce our two speakers. Tabitha is a SIG Security Chair and a Security Response Committee member. Paris is a Kubernetes Governing Board representative, a Steering Committee member, an Emeritus Chair for SIG Contributor Experience, and TAG Contributor Strategy. They're both permanently online, so I'm sure you can catch them all on Twitter. Now onto the show. Who here has heard about the Detroit Water Project? Show of hands. Better yet, who's donated? Anyone? Well, this initiative was created by Tiffany Ashley Bell and Kirstie Tillman to answer an extremely large community need, as families and many other at-risk groups here in Detroit had their water shut off here several years ago. A direct quote from Tiffany about the situation to sum it up. So it turns out this whole water crisis thing goes... Oh, hold on. In the city... Sorry. Hello, Lou. Alright, we're going to do this one more time. A direct quote from Tiffany about the situation. It turns out this whole water crisis thing goes back a while. In the city of Detroit, the water company is the one thing that still brings in money every month. There are a lot of people who still pay consistently, but the city has taken out billions in bonds, so they owe Wall Street a lot of money. They see the water company as the only place to try and get that money back. Once you're behind on your bill for two months, and the water's been turned off, there's a $30 reconnection fee to turn it back on. If you're already behind on your bill, the chance you can't afford it. Tiffany figured out a way for me and you to make money directly to unpaid water bills so that those without this basic human need have clean water. They wrote postcards and canvassed on the ground once they figured out that it was possible to take direct action. In the first 16 months, they helped 950 families here in Detroit. Today, it's now the human utility with the same mission plus additional locations for instance in my hometown Baltimore. Tiffany has also evolved into fighting for policy change at the root. This is an example of a mutual aid project where people come together to help others who are directly affected because no one's saving us but us. 2014, another open source project that you probably use every day took over a year to fundraise $20,000 to pay the electric bill on their self-hosted build infrastructure. That same year, the OpenStack Technical Committee was forced to address unsustainable project growth and insufficient infrastructure support from their member companies. 2015, one of the developers of Hypothesis quits the project abruptly and leaves us a note online explaining what the situation was that forced him to have to step away. I could keep going with more examples but let's get forward to today. This happens in our own ecosystem and community. That's right. These are open source issues and it's not an us or them problem but it's a matter that we need to solve together. In Kubernetes, we ask for full-time headcount all of the time in places that don't see productized feature development like infrastructure, testing, docs and community and heck we even ask for the places that have features as well. XED also has a need for full-time maintainers to shepherd everything including features. Their community isn't as large as Kubernetes to distribute the load but they're raising flags and asking for help. After several months and even years of asking though XED still needs maintainers. Kubernetes still needs testing and infrastructure support. This is just one example. But we carry on until we break down. The proof can be seen over online as Tabatha just mentioned through blog posts and things like that and I'm sure there's a ton more examples that you're thinking of in open source history. We could have a whole talk just on this part alone. There were some notable clusters though of years that received a lot of press and hot take, some blogs and things like that. They all surrounded security incidents and open source natural disasters like Log4J, Heartbleed, OpenSSL, etc. They strain our time and energy breaking down our ability to engage at the same levels as before. Sometimes we advocate for change with blog posts some with conference talks like this one and others with fundraising campaigns. Sometimes we just walk away. I'm scared of the idea that I might break down or walk away myself. I don't want to live that story. In principle, some open source disasters like the abrupt loss of a single maintainer can be prevented by offering more support to each other. Others, like the onset of a global pandemic or the stress of a major security incident are totally out of our control but we can find ways to support each other when they do happen. So this is what I'm thinking. How can we be inspired by the success of mutual aid projects like the Human Utility? How can we come together in new ways to support each other through everyday and open source? Paris and I have been blessing on our time in local communities and we'd like to share some thoughts about mutual aid and about two broad categories of action that we have seen improve the lives of our colleagues. The first step in building any kind of mutual aid project and changing things is understanding the structures around you. Dean Spade, a lawyer and activist, lists three key elements to mutual aid in this book about building these programs in the times of crisis. The first element is knowing why you aren't getting what you need is a critical first step. Knowledge is power. As a future or current maintainer, how do these power structures around you work? How do you ask for help or resources and what do they do with that? Who makes decisions about the priorities of your needs? For instance, how does your project's top governing body hear and take action on your needs? How do they interact with the CNCF? Step farther, how does the CNCF work? The foundation itself offers services to maintainers like paid security audits, design services, cloud credits, and more and other programs that many open source foundations don't offer. But how do you get them? Do they offer what you and your project need? What about legal counsel in the time of an export control issue, or does that require your own attorney? Who holds insurance for you when leaders get into code of conduct lawsuits? These are things you probably don't think about as a maintainer until you need them. So how do you escalate when those needs aren't being met? There's multiple bodies at play here and they range from the technical oversight committee to the CNCF governing board. CNCF projects have representatives that take your escalated needs in the form of risks, opportunities, and updates. The governing board is comprised of the largest donors to CNCF and they approve budgets that are set by CNCF staff and hear license matters and more. I'm the rep for Kubernetes. Richard Hartman is the rep for all of CNCF projects. Reach out to us if you need anything. And now, what about the orgs, though, that we're asking things from, like most notoriously full-time engineering support? How do they work? Well, businesses invest money to gain value and or reduce risk. So how does your employer approve headcount now? What's the value for them in hiring someone specifically for your project? Do they want to get desired features in upstream or need influence? Do they need the reputational benefits of open source? Are they worried about the future of technology that they depend on because of all of the security incidents and things that they hear in the media? How much does the support you want cost them? It's been my experience that it's a lot easier for businesses to write an expense in the form of a check than it is for them to get headcount with benefits. They're two different accounting items. Understanding these power structures reduces the time asking for things that you won't get. It sets your expectations appropriately and it helps you ask in ways that will be heard and acted on. All of this is power. To make this a little more concrete, remember that the leaders of a company need to... tension... community-oriented only happens when somebody personally sees the... indicates for it. The investment needs to be constantly re-justified without warning. Part-time work within the schedule of an existing team, filing bug reports, upstreaming patches instead of carrying them over time, and those contributions are super, super valuable, but we can't expect those contributions to make all of our problems disappear. Even as individuals, we need to recognize that we can't carry a project single-handedly. I work with you, and so I know you're brilliant. You have health... enough by yourself. Our projects are too big for that. Your hard-working brilliant can hurt up-and-coming... too. They see the superhuman effort of some of the heroes in our projects, and they know they could never reach that level. It's really dispiriting. And prolific fixes coming from a few hero devs can starve all of the new contributors that might like to help of good first issues. No one of us can save a project by ourselves, but we can really hurt it by trying. So I wonder, do we want to persist in making heroic individual efforts? Do we want to keep asking our business partners for help and being angry if they don't give it or disappoint it when it goes away? I want better than that for us. Instead of being mad, let's mobilize our people, expand solidarity, and build movements. We can do this by holding space for each other's joy and pain. We can share stories and learn from each other. One such group that we actually have already is the CNCF Maintainer Circle. It has all of the maintainers, excuse me, rather all of the maintainers can join this. And with more than a thousand maintainers and billions of dollars in this industry, we have the power if we come together to use it. This is a mutual aid project in and itself. I created this group, but I'm not the leader. That's not what the intentions were. It's not supposed to be led by just one person. All of us are the leaders here. One can host a circle. Since the group's inception, we've brought speakers in for deep dives on topics like code reviewer growth, burnout, and more. What about topics like what we were just discussing with asking for support from our employers or helping each other clearly articulate our needs? Join the CNCF Slack group for more, and I'm really looking forward to you all hosting your own circles. Let's sum up what we've heard about some of these mutual aid elements. One, knowing the structures and understanding how to put them into action is important. Two, saviors continue the cycle versus break it. And three, holding space for each other is really important like a maintainer circle. So the first rule that Tabitha and I have seen work is saving yourself. As a future current maintainer, a healthy and not overwhelmed you is helping you end the project. Burnout is a topic that we hear too frequently in industry circles. You might hear some say, quote, project first, and I want to challenge you with no, it's you first. You can't pour from an empty cup. Fill it up. So how can we start by saving ourselves? One, we can start by writing down what we do and thinking about onboarding more people before we need them. How many, you have no idea how many maintainers ask me, Paris, how is this really going to help me? It sounds a lot like busy work, but by the time you're burnt out and or overwhelmed, it's going to be busy work. If that is the case though, I'd like you to stop all of the regular work and the PR reviews that are coming in and onboard more people who can help you because people can't help until we understand what the job is. So it's also how you grow your contributors and what you can point to when current maintainers of your project or maybe even your dependencies or the ecosystem can jump in and understand what the infamous jump in and help phrase means. Help wanted tags are a proven good way for folks to jump in, especially on tactical issues and PRs, but I want you to think bigger. I don't often see new requests for maintainers in issues and things like that, but the people you don't ask can't help. So what other needs are you struggling with? This seems like an intense word to use, but don't let it get to be a disaster. And if it is, don't be ashamed to say what's going on because suffering and silence begets more suffering or behind closed doors, it's the same deal. Be loud and be public. This is one of my biggest regrets on the Kubernetes project. Why? Because my role as a governing board member functions solely behind closed doors because that's how it works. When I bring issues to the table, like needing more support or funding, it's usually the first time that they're hearing about it, and this doesn't help our cause. What helps is detailed issues and annual reports, stating what we need and what happens when we don't get it. That last part is so important. I've been advocating for CNCF budget transparency, more participation from member companies, funding for our infrastructure and legal support for our committee members, among many other things. But I promise it's not all drab out there. There's so many projects and teams of maintainers that are doing what they need to do. And a good success story here is within the Kubernetes sig docs community when they needed to rotate out leadership. And they did so by clearly articulating their need on their mailing list and asking for support. And not only that, then using the Kubernetes mailing list, the developer mailing list that has over 5,000 people, and not only that, then tweeting about it, getting the Kubernetes account to tweet about it, over a million eyeballs saw their outreach. And they eventually did get new leadership to group mentor and successfully onboarded new leaders. They really got the word out. So what the moral of the story is, what the moral of the story here is, is use the damn mailing list. So when the struggle is too much though, or when you're ready for new exciting opportunities, it's time for emeritus. The word emeritus is an honor, and we need to use it more. It's an aspiring level that can be used no matter what the situation is. And consider this the top of your contributor ladder. That should be achieved so that others can grow behind you. If you have this mentality from the start, kind of like what we have at our day jobs with retirement, it's easier to save yourself and grow others behind you. Even your CI is going to thank you for not having to constantly remind you about PRs that you need to review. Be an example for others. Show them a positive outlook. So many people look up to you. So the next rule that we've really identified is the next step, which is lift each other up. That means when your cup is full, share from it. This is a thing where we need to use empathy. We need to use consent to meet each other where we are, because the right approach depends on the situation. Sometimes there are challenges, and the folks who are having those challenges are able to clearly identify what they need help with. They're able to ask for help in a way that is very straightforward, and you can see that. Other times a project is struggling and there isn't so much understanding as that. Maybe they don't know how to ask for help. And these different situations, because they need different approaches, will go through them one by one. The one that's a little more straightforward is when there is a clear ask for help. Contributors and maintainers are really the ones who know best to ask for what they need. The folks who are on the ground living their lives know what is best for them, because you're describing your own experiences, your own lives. So when someone, like a contributor or a maintainer, or a project asks for help, you can help them. They're telling you how to do it. You need to believe them, and don't let your fear of being imperfect or of not having the expertise, they have stopped you from helping. They have given you the plan already. If the job is well documented, like we talked about earlier, then you can start with that documentation. You can use it to get yourself more up to speed to be able to step in and do the things that they're asking for. But even when the documentation is slim, when they're asking you for something, that's because they know they need it. That's your permission to try it, to do it, and to work with them to fill that gap that they've identified. You can't always help with everything yourself, and so an important thing to note here is to spread the word, boost the signal, use your voice. So, all of us here, how many people have you told about the problems in EtsyD? I got to reflect on myself. How many people have I shared the struggles with EtsyD with? It's been some, but it's not as many as I would like. It's not as many as really could have helped them the most. The other situation is the more challenging one, but it's a good opportunity for us to build relationships. It's a good opportunity for us to practice our empathy, practice our ability to use consent. So, when there's a person, a maintainer, a contributor, or a whole project that's really struggling, and you see that, and they don't know how to ask. Maybe they're just saying, help, maybe they're not even saying help. Maybe you just notice that PRs are piling up, or issues are piling up, or something like that. Then put on your hat, and you know what's overwhelming to you. You know what's hard for you, what you struggle with. Think about those challenges that you face in the context of their work, in the context of their project. This can be a good way to guess at things that might be helpful for them. And that's an important first step. The second step after that is even more critical, asking their permission to try to help them in the way that you've identified. That could sound like, hey, I notice that there are a bunch of PRs that are piled up and reviewing here. I would like to help. Would it be helpful to you if I read through some of these PRs and make my comments about them? Would that be helpful to you? Or there's this backlog of issues. I know that you triaged them in this way. Would you like me to do some of that for you? Would you like me to do some issue triage? One perennial difficulty for maintainers is meeting logistics, scheduling meetings, facilitating meetings, starting on time, managing the notes. So that is often a way that you can help, especially when people or a project are overwhelmed. You can help the experts to focus on sharing that expertise with new folks in order to get themselves into a more sustainable place by asking, would you like me to come and facilitate some meetings for you? Pulling this all together, there's a lot of ways that we can help ourselves stop struggling alone. We can create communities of care by asking for help when we need it, by offering each other help when we can, and by using our voices to share those needs. We can use the power of our knowledge to get more practical assistance from the companies and organizations around us. In this morning's keynote, we heard some great promises of concrete support. We can connect those promises to the real needs that we know we have, and we can follow up to make sure that that support is truly helpful. No hero can come and save us, but we can save ourselves together. We take care of us. Thank you so much for coming, and your time here today. At the end of the slides, there is a bibliography with a ton of resources, including the link to the book that we referenced for Mutual Aid, and I promise if you put your contributor or maintainer hat on while reading it, it will make so much sense. There's a whole section on there on how to reduce burnout within your teams. Also, consensus-based development that all of you will take interest in. Thank you so much. I'm Paris. I'm Tabitha. I've been grateful to be here. Go take care of each other.