 Good morning, everyone. One of my favorite videos on the internet is one where Kurt Vonnegut describes the shape of stories. It's amazing to hear how he imagines and can categorize all the various types of stories that we tell in our day-to-day life that we're familiar with from Hollywood or from reading books or whatever. And what I want you to notice is on the x-axis going across is time and on the y-axis going up and down is happiness or unhappiness. So he theorized about eight different story types. One of them the man in the hole, the boy meets girl. Excuse me, one second. Lost my notes there. There we go. From bad to worse, which way is up? And as you think about these different stories, you can perhaps map them to different ones that you're familiar with in your own life or enjoyment, but they have some examples down there for us. And then the last set of stories, he spends a lot of time talking about the Cinderella story, which once you hear him talk about it and see the similarities, you see it pop up in a lot of different places. I've linked the video there for you all to check out in the notes so you can see him describe it much better than I can. But the question that I have is what is the shape of the open source story? If we can allow us to stretch finding its metaphor a little bit. My talk is about breaking out of the open source burnout cycle. My name's Nigel. And honestly, this talk started as advice from me to me. So if something doesn't resonate with you, just assume that I'm talking to myself with extra steps. I'm a senior developer advocated into it. I focus on cloud native and open source technologies. I am an open source enthusiast and most importantly for this talk, I am an experienced burn out or expert even. So I want to start again with this with this person in the whole story and allow me to make a small modification. So I've drawn in a little line at the beginning and it we can't forget the honeymoon phase. You get nerd sniped. You find an interesting project a problem. It's going great. Then life sets in priority shift and it's easier. It's harder to make time for your project and you feel some resentment. Your users are complaining. You've kind of reached your limit and poof burnout. But what I want to point out is that the way that Vonnegut talks about these stories is that it's like a linear thing to have a beginning and end. And my point is that when we're doing this kind of work, our lives aren't super linear in that way. We find ourselves in these cycles over and over again. So instead of the character getting in trouble and getting out of it again and ends up in a better place, we end up in the same place again and again. I'm not a very good artist, but yeah, this is a bit more representative of the cyclical. You find your way out of it just to set back on that roller coaster again. I do anyways. I can't really speak for you, but this is again, this is me. Let's annotate the graph a little bit. So burnout very clearly when you hit the bottom there. Recovery, getting back to the top. And then when you've had more than enough, you take up beekeeping and then that line goes straight up. One of my favorite Super Bowl ads was a Snickers one where they talk about you not being you when you're hungry. And I think that metaphor extends to when you're burnt out. Don't read this as a WebMD article, but exhaustion, obviously. So irritability. That's one of the first ones that pops up for me and procrastination. And I know a lot of people like I'm a procrastinator. I wait until the last minute. I can assure you when you burn out, you will find there is a last minute. Ask me when I finish these slides. Sorry, Julian. So these things are antithetical to our goals. They turn people off of us and of our projects. Our body will go into open rebellion if this carries on for too long. I had to take an extended period of time off of work last year because I wasn't paying attention. And so, yeah, trying not to barrel back into that place again and hopefully what I can share with you will help you as well. So the first thing, what can we do about it? Step zero. Let's recognize the effort that you're putting in and the progress you're making and then celebrate it. So the reality is that the mindset or grind set that's prevalent in this industry and especially in the U.S. does not incentivize your health or rest. Subvert it. Take a nap. This talk is about breaking out of that burnout cycle. So let's practice. You've earned a break as a treat. I've been up here talking for five minutes and I've earned a little break too. So I want you to think about something that you have done accomplished in the last couple of days that you're like kind of proud of. Maybe you've had stressful time getting here. I've had flights canceled and flights delayed. It's been a pain, but you made it here in one piece. Or maybe you got a full night's rest last night, or maybe you didn't and you're very proud of yourself for being here this early to listen to a talk. Whatever that is, I would love for you to just internalize it, recognize the effort that you made to be in this moment right now and then celebrate it. And if we're able to interject these moments into our daily lives into the work that we do into the open source that we are contributing to, this will help us break out of that cycle. On to some more specific advice. What can we do. And the first slide is for ICs, individual contributors. And I think the first thing that we can do importantly is to time block and to task block what it is that we're working on. My friend Natalie pointed out that an open source your work is never really done. And I feel that your notifications come in at all hours of the day. You never really feel like you've done enough. So setting time limits for what you're going to be working on or setting task limits, being able to break up what you have to do. Oh, I want to squash this bug. But if you split it up into more manageable tasks, I want to understand what's going on. I want to reproduce the issue. I want to so forth and so on. When you have these little manageable bite size pieces, then you can more Then you can more specifically chart out your day and your schedule to be able to block out what it is that you're going to accomplish in the time that you've set aside. The next two are more for maintainers. Oh, no, not yet. Manage up effectively. This is something that I'm still struggling with. But if you want to be good at what you do, one of the most important things is to be able to manage up. And what I mean by that is to go and get help from your manager and at a timely fashion and be able to describe effectively what it is you're doing and to make the business case so that you get to keep working on the things that you want to work on and your manager can support you in the times that you need it. So these next two are more for maintainers. And the first one is to delegate and to create paths for mastery for delegation. You want people to be able to help you out. And a lot of times people want to help but don't know how to get there. So in the way that we set up our projects and the way that we write our issues and the way that we set up our sprints. We can create ways for people who are on the path to figuring out how our project works on the path to mastery be able to put them in a place to help us out when we need it. And then the other thing that's very important is to do project health checks. So when I was at VMware, Jonas Roslin, the open source community manager there had these health checks that we would do for our projects and I've linked the open source repository where all that stuff is. Some of the important things that they have there are things that would lead to maintainers or contributors burning out. Being able to see what the lottery factor is of your project, if so and so wins the lottery, like how damaging would that be to your project if they just didn't work on it anymore. Or how much churn are we having from our new contributors? How many repeat contributors do we have? How big are the contributions that they're making? When we're tracking these source of metrics and sensitive to the changes in our projects, we can be better set up to delegate tasks to recognize when our project is on the brink of having maintainers burn out and help set up healthier projects. And the last piece of advice that I would give to you is to enjoy every bit of it you can. And this is where I've been trying to focus a lot of my time and energy on because I found that one to be a little bit easier than some of the other other tasks. And what I mean by that, there are a lot of photos that I wanted to include, but I didn't want you all to just sit through my photo album. But what I'm showing here are two photos of taking advantage of being able to go to conferences like this. So with my work, they're saying, OK, if you want to go early or stay late, that's fine. Get to where you're going. Go to your conference. So instead of coming straight to Bilbao, I went to Munich this weekend and went to Oktoberfest and I had a really great time. And then when we had KubeCon and Valencia, I took some time and traveled around Barcelona. My strategy is to go somewhere near the conference usually ahead of time so that I can get used to the jet lag. And then take some vacation or work through it. I definitely recommend the former if you can. And see places that I've only read about. Get to experience these kinds of things because that's what energizes me and gets me back on to wanting to be able to continue doing this kind of work. So yeah, I've gotten to see places that I've only read about only really started traveling in the last year and I'm really, really grateful for it. If anyone from CNCF is listening, I have some suggestions for other conference locations from my bucket list. But I wanted to share one more quote from Vonnegut if you'll indulge me. He's talking about someone who passed. He says, my uncle Alex, who's up in heaven now, one of the things he found objectionable about human beings was that they so rarely noticed it when times were sweet. We could be drinking lemonade in the shade of an apple tree in the summertime and Uncle Alex would interrupt the conversation to say, if this is a nice what is. So I hope that you'll do the same for the rest of your life. When things are going sweetly and peacefully, please pause a moment and say out loud if this is a nice what is. And I think that translates to our life to the things that we're doing that are fun that give us energy, but it also transit translates to our projects. Like when something great happens when we have someone make a big suggestion or add a feature to our project like these are the things that I look for that I'm looking forward to that I like to see in my project so taking a moment before getting into the drudgery of working on it to say man this is this is kind of cool. I had this idea and other people think it's cool and they came and did it and even right now for me like I had this idea for this talk and a bunch of people showed up like before lunch, you know, so I am, I am enjoying it. This is very sweet. Thank you all for coming. I really do appreciate it. I'm not done yet. I'm not saying thank you leave from saying I'm saying thank you for being here. I'm almost done. Don't worry. So back to what we can do about it. This one's for the managers in the room sets and boundaries, not just with yourself, but you give your all to your ICs, but for not just for yourself and how much you give to your IC so that you're protecting yourself and your energy and making sure that you can continue doing the things that you're doing, but also for your ICs in relation to the open source work. I have a bit of starry eyes when it comes to things and I just want to work on them all the time keep going but there are other priorities and having an understanding manager this like okay, here's how you've done, you know, here's what you've been working on lately. This is great. We need to make sure this is sustainable so being able to set boundaries with your with your ICs and with yourself to make sure that you are taking care of yourself. And if it's possible to get some protected time for yourself in your reports, I cannot tell you how valuable this is for me, and to be able to work on these things in time that's dedicated for it, as well as feeling like like that's something that helps me want to work at a place and want to be at a place that they value the efforts that I'm putting in outside of what I do in my daily work because the reality is that this stuff is back to what I'm doing every day. And then if you can incorporate open source and upstream contributions into promotion and career conversations. This is something that is super helpful because we talk a lot about some of the some of the glue work that goes unappreciated and some of the invisible work that goes unappreciated. There's a very relevant xkcd that I should have linked in here about the one open source project is holding up the whole internet. I see some nods you all know which one I'm talking about. But yeah, if we could make it less of a thankless job and incorporate these things into our promotion and career conversations that that would be awesome. And then for companies and foundations, if you were in that position, pay and hire open source contributors. Yeah, this one kind of goes without saying, tangibly reward the folks that are building tools for your project for your platform. A lot of companies now are built on open source projects and perhaps don't contribute as much as they could back upstream. And that's something that's not a difficult ask. And we should see more companies taking steps, more foundations taking steps to give back to those engineers but not just in a way that they think works the best. But in the ways that they're asking for not looking for, you know, a pizza party, but you know, whatever it is that that the maintainers are looking for at that time. Yeah. And then if you're a user, I didn't forget about you. The first thing, the most important thing, don't be a difficult person. When you're interacting with your when you're interacting with your projects when you're interacting with anyone else outside of yourself on the on the computer just please try to be nice. There's not really an SLA for most projects that I'm aware of. So bear that in mind and pitch in where you can. One of the best things that I've seen for the projects that I've worked on is seeing when those folks, the users communicate the successes back to the projects. So your kind words mean so much more than you know. And I would ask of each of you to commit to sharing a user success story or something that you like about a project that you rely on in the next, let's say, week and a half you got the conference you're busy when you get back next week think about your open source maintainers think about how you can tell great because these are these are things as well that maintainers appreciate for justifying being able to get more time to work on these projects. They can say oh so and so at this company is using it or like these people are really engaged with what's happening. I'm not just wasting time like, you know, it helps a lot so please communicate your success stories and not just every time you find a bug, because there are a lot of projects that I've worked on where it's like oh how do who do we know who's using the project well nobody's told us well, let's look at the issues that these people are falling a bunch of bugs that kind of sounds like they're using it so we can assume that this company is using our project. That's kind of backwards if we could go the other way where the companies are saying or the people are saying hey I've incorporated this thing. It's really great. Thank you so much. Alright, we're not going to solve it all right now. I would make a lot more if I could, but we're going to try and we're going to keep trying. A lot of us get in the open source because we love what we do. We're excited by putting our efforts into the world and want to see our projects succeed. We can burn out for all of the same reasons. It can sneak up on us and we undertake a lot of tasks with projects that don't count as work. We're not great at calculating the cost of remaining constantly available and we continually pour ourselves into our projects and communities and learn the hard way that we can't pour from an empty cup. It's not a bad thing to let the desire lock us into a loop or it is a bad thing to let the desire lock us into a loop of burning out and recovering only to burn out and recover again and again. In the end the best way to keep taking care of our projects in our communities is to take care of ourselves. So I wish you all the very best on this journey. I want to see working in open source be a healthy and viable career path for many, but more than that I want to see communities come together and support each other's health. So thank you. That was. That was the real thank you, but you don't have to leave. You can like ask questions and stuff we can hang out for a bit. I was talking like super fast and I burned through this presentation. So like, yeah, questions are amazing. Yes, please. Oh, there's a mic on the way. I'm nervous. Me too. And I really sorry to hit you that you went through burnout. I have a question about what you said for the foundations because you said hire the contributors. So how did you do it in a way that obviously you can't hide everyone right? Yeah. And then parting from that. How do you do it in a way that you're not actually originating some competition among contributors so that actually by kind of let's say saving a couple then you're putting so many others into that path. Yeah, that's a really good question. So if I understand correctly, say that I'm a foundation and I want to hire open source maintainers for a project. And I want to do it in a holistic way that doesn't alienate a bunch of the other contributors who feel like they're giving up their free time and not getting anything for it. One thing that I would say is that this isn't really a question that comes up in like any other circumstance of like, oh, if we like incentivize somebody to perform this task or pay people for the work that they're already doing, maybe other people will stop. I think that there are ways that, you know, let's say for example, it's a really, really big project and you're kicking it off. Maybe you have like a sort of artists in residency kind of thing where you have people take shifts like, you know, doing like stipends like months on months off so wouldn't be able to be their full time job, but sort of transitioning into this way that we are giving people money for the work that they're doing. And I think as well, like, there's no way that we're going to completely eliminate competition and there's no way that we're going to completely get rid of any like bad feelings or resentment that people feel about it. But I think that if we're intentional in the way that we do it, if it's like based on factors that are visible to everybody because these projects are in the open, I think that there's a lower risk of like destroying the project by hiring one or two maintainers. Does that answer your question? Yeah, I have to think about a little more. That's a really good question. Yes, the one in the back. Yes. Yeah, I'd actually start by commenting on this last point that another possible solution would be to focus on maybe like hiring open source contributors of like solo maintainers of projects. Yeah. They're using the ones that are the most that are suffering the most. Yeah, it's the XKCD comic. Yeah. And in that case, there's not much competition between the maintainers. And if you are concerned about that also, you can just use like GitHub, GitHub rewards or whatever the sponsors or tide lift and then just pay the project and the maintainers figure out how they want to That'd be another solution. But my question actually is thinking about like the solo maintainers. Right. It's quite common for solo maintainers of popular projects to go through burnout. Of course. So like do you have any tips actually for these solo maintainers themselves? Yeah, I personally don't. I will refer you to my friend John McBride's talk. He gave a great talk about the dangers of solo maintainership and provided a lot of advice and that that was at Kubecon. I'm sort of, you know, Kubecon Valencia, I think I will find it and I will put it in the notes. I'll upload I'll add this to the schedule like other links I had another slide and I'll put a link to to John's talk there. But if you look up John McBride, who's solo maintainer of the Cobra project for for a while. He has a lot of great advice a lot better than than I could give you I've never been a solo maintainer of a project. But yeah, I'll refer you to John. Yes. Okay, so I'm going to comment on the whole paying and hiring open source contributors thing just one last time because it is a big one. So, for those of you who don't know me a couple of years ago I actually worked for the CNCF and they hired me on as a technical writer to support CNCF projects. So one thing that I will say because I know that there's a lot of people who are being sponsored to come to this event by larger companies who are contributors to LF foundations. That is a very hiring maintainers through the foundation can be a very sustainable way of giving support to projects so for example, with smaller projects or with projects that have smaller maintainer groups like I was mainly on Kubernetes because because Kubernetes but for projects that have smaller maintainer groups. It can be very, very efficient to have the foundation hire some of those roles and then spread them across five or six projects. Like that's an efficient use of funds. However, and I will point this out specifically for those of you who are from larger companies who hold board seats. The impetus for making those hires comes from technical advisory committees and boards, like they will not do it on their own they need to have that proposed to them. So it has to kind of go through a board seat which if you're a true solo maintainer or if you are a maintainer on one of these smaller projects that's a lot harder to access but that's roughly that's how I was given that position a couple of years ago I don't work at the CNCF anymore. So my question for you Nigel sorry for that divergence. My question for you is, how do you manage the people aspect of burnout because I think a lot of maintainers are fantastic developers but I see a lot of. There's a lot of people management to being a really good open source maintainer and I think it really takes maintainers by surprise. Yeah, that's a good point. There, there is a lot of difficulty and like people are difficult, like they're like, in general, like people are very hard, like the hardest problem in programming might be naming but the next one is definitely people. It's harder for smaller projects. And I think that for the smaller projects it is important to for those maintainers to have very clearly the reasons that they got into this the reasons that they're doing it and to be taking care of themselves first and foremost, because like I said the one of the first times for me is irritability if like something happens that I get really annoyed like really quills. Oh, there's something out like something needs to shift. And I think that being clear in the communication of like hey, this is an open source project, you know, like we're we are doing our best. And then having very clear code of conduct, having very clear like contribution guidelines to be able to point people back to this document that says, this is how we do things here. And then for as the project grows like finding a people person like I have been like a community manager for open source projects. I've done a lot of that dealing with the difficult people next so that the maintainers can get a very redacted version of the requests that are coming in. But yeah, I think it is a very tough problem but first and foremost, I think if you're relying on a code of conduct, and then being clear about what it is that you're offering and what it is that you're not offering. And then that that has made it easier for the project that I've been involved in and then as the project grows to find community community managers but also to have like instances where people can meet the people behind the project. So we did like community meetings and office hours where people had synchronous time with the maintainers and I felt like that turned the temperature down on a lot of things a lot of quickly. Because a lot more quickly because most of the issues that we have are in miscommunication, like people don't like you write something in a GitHub issue and like somebody reads it the wrong way at the wrong time a day before the coffee and now we have a flame more in the comments and the issues lock. So I think that synchronous meetings are really helpful for that sort of stuff because you can explain what your problem is and then you have the benefit of context and facial expressions to not get ticked immediately. But yeah, to summarize, having a code of conduct, having instances where people can spend synchronous time or like meet the maintainers behind the project so they see a human and not just a GitHub repo. And then, yeah, taking care of yourself. That's my advice for for that. Yeah, any other question. Yeah. Oh, couple more hands. Yeah. Oh, good. I have the mic. Sorry. Yeah. Good morning. So just a small question. Yeah, that I was in the OSP office in my company, but due to some reorganization. I was moved in the internal ones. The reason the company gives is that the open source office does not bring any revenue. Okay. Okay. So now, of course, the revenue is the first. Yeah. So I like, I want to ask, do you think this is a right move or a wrong move? And if wrong, what advice can you give me which I can further tell them that please be considered. Yeah, I'm going to be very careful not to put my foot in my mouth here because I have an interest in staying employed. I haven't made it there yet. So to answer your question, to summarize your question. Yeah, sometimes projects get deprioritized because they don't make money. What do you do about that? I think that if you're able to emphasize the value that participation is creating that is not tied to money. I think that that's one of the things that in general, I feel like people should do things because of the right thing to do but often they need more justification. But that's capitalism for you. I think that if you're able to show benefits to the business that aren't directly driven by revenue, revenue but are clearly tied to participation in open source contribution and open source and how that makes the tools better that you're using how it makes the engineers better that are working on the projects. I think there are ways that you can spin what it is that you're doing into into value and there's like a whole hospital track and like, you know, the business of open source that people are going to have a lot more, a lot better advice than I am because they work in these deliver value and communicate value to the to the shareholders to the to the higher ups. I'm, I do it on a much smaller scale, like explaining to my boss why I should be doing the things that I'm doing, you know, contributing upstream. And yeah, because the right thing to do generally isn't a good enough reason. So, yeah, figuring out how you can tie what you're doing directly to benefits to the company that aren't monetary. I think that's a great first step. Hi, hi, I like your burnout curve, the story curve. Yeah, but all your advice is about how to get out of there. Do you have any advice when it's time to take up beekeeping and give up. I think that time just kind of finds you, you know, I think what I've learned is how much longer it takes every time I burn out. And when I'm sensitive to myself about like being intentional about getting back into what I know is going to be back in that space. It's like doing a cost benefit analysis, like when I feel back to like an even kill even keel of like, okay, is it worth it for me to get back into doing what I'm doing. And if the answer is no, then I'm not at the like beekeeping stage yet, but you know I've definitely moved jobs to find a place like to get that sort of new energy again to feel renewed. But yeah, I think that if you're sensitive to yourself, and like what it is that you need, and if you can continue to keep doing this and take that risk. Then, then you go back in, go back in again but like I have conversations with my sounding boards with my therapist with it with my managers with my friends my colleagues and, you know, make that decision from there is like, is it time to like sell the farm, you know, maybe. But yeah, I don't know that there's any sort of definitive sign other than like, you'll sit you'll sit down and think about it one day and you'll be like yeah, it's kind of time, you know, beyond that, all I can say is, sorry, you know, I wish it was more clear but yeah it's for me it comes down to when I find myself at that place like, do I have it in me to go again. And if the answer is no then I need to change gears like this is my third time at a career like I fully made the transition like twice, because I couldn't answer that question and then I slowly find my way back to the things that I love doing, you know. But yeah, it's hard to know for sure but I think you kind of know when you know that's not a great answer but it's all I got I'm sorry. How many bees do I have? Presently none. My, my thing is single board computers like by like Raspberry Pi's and stuff like that. But yeah, I think that my like, taking a beekeeping is going back into the music industry, you know, I do like recording and music production stuff, and I think that'll be my beekeeping there'll be a day where like I'm like alright, I've had it, that's enough, you know, and then move on. But I'm here now. I'm here right now. Very happy to be here. Thanks, thanks, thanks, thanks. Do we have any more questions or you ready to get out of here? Yeah, I've kept you long enough. Thank you so much for coming. Take care. Enjoy your conference.