 Wonderful humans. Thank you very much for coming to the Community Debron today. It is my pleasure to introduce V.M. Vicky Brasseur, who is going to be talking to us about succession planning for FOSS projects. I'm really excited about this talk, because I don't think we have a lot of conversations about what to do when you need to gracefully leave your project. And Vicky's going to tell us how to accomplish that successfully. Thank you, Vicky. Thank you. Thank you. I will at least give you an introduction to how to do so gracefully. So yeah, I don't have to read that slide to you because Leslie just handled that. Thank you, Leslie. She's amazing. Who am I? Why am I up here? I am V.M. Brasseur, but because we're all friends here, you can call me Vicky. I am an open source strategy and freelancer. So contact me there. I am an author and moderator for opensource.com. So if you want to write an article and get it in front of 1.2 million free and open source software fans every single month, please contact me. And as of this past week, I am the author of probably, as far as we can tell, the very first book on how to contribute to free and open source software. So I encourage you to check it out. It is on Pragmatic Programmer. So it is available now in ebook form. It is in beta. So there is still some more content coming. But do check it out there. So these slides are already available on Internet Archive. I am also doing a screencast right now. And I will put that video on Internet Archive as soon as I have anything resembling Wi-Fi. But the slides are there both with and without speaker notes. Now, succession planning can be a fairly complicated thing at times. I will be presenting general tips for how to approach this process, but not all of the recommendations are going to work for every single person or project. Some will work better for large projects. Some will work better for small projects. You do you, honey. So take from this presentation what you need. Don't feel obligated to do every single thing I'm going to suggest. And I say this, but frankly, we're not going to have any time for questions, so fuck it. As we all know here, we have been sharing software for as long as there has been software. But then back in the 1970s, the organizations that create the hardware figured out that, hey, there's a business model behind the software. So the people who were previously sharing and modifying the software no longer could. Stallman fixed that. Thank you. In 1983, GNU Project 1984, open source initiative. As we have heard, some of you were here earlier, we sang happy birthday to them. Because open source, 20 years ago to this very day, became a thing. So happy birthday, open source. Now, there's really no denying that free and open source software movements, they've changed the face of technology. And they are here to stay, thank God. But we're starting to reach the scale and age where oral history just doesn't really cut it anymore. It's been 40 years since the 1970s, people. We still have the founders of our movement in our mists. And we are so lucky to have that. According to the 2017 GitHub Octaverse study, there are over 25 million publicly accessible repositories on GitHub alone. That's not counting GitLab, that's not counting BitBucket, that's not counting all of the privately hosted repositories. Millions of these. And most of us can't do our jobs without them anymore. I literally would not have a job without free and open source software. Now, we couldn't run our companies, we couldn't serve our customers. But now 40 years on, we're really very overdue to be thinking about how we in free and open source software, how will we get by when the people we rely on, our leaders, our founders, when they move on. These aren't necessarily just the RMSs or the BDFLs of the world. Because every project has people in important and critical roles, and every single project out there needs to consider a backup plan for when those people need to move on for some reason. And that brings us to the topic of today's talk, which is succession planning. Now I have done a ton of research into this, specifically in free and open source software contexts. I've done lots of interviews of leaders and community members all across the board. First thing I find I always need to do is define succession planning. Here's what Wikipedia says succession planning is. I'm not going to read it for you. I'm assuming you're all literate. But this is pretty standard for what you read on the literature on the subject of succession planning, which is almost entirely written by HR professionals. There's not a lot for small organizations, nonprofits, things like that. So I'm not really a fan of this definition, because it doesn't fit us very well. It says here, leaders. It implies that only leaders are the ones who need backup. But in free and open source software, what is a leader? What do we define as a leader for us? Well, it gets pretty complicated. So I prefer this. From a free and open source software perspective, I think it's better to think of succession planning as a skills pipeline rather than a leadership pipeline. Skills are something that you can teach people. Leadership is considerably more difficult to do that with. Now, the literature does focus on high level leadership things like CEO, founder, stuff like that. But in FOSS, there are a lot more important roles than just that. Any role, which is measured by a bus factor, is a role that can benefit from succession planning. So who here has heard the term bus factor before? Right. Awesome. First time I did this, like half the audience would like bus factor. What the hell? So a bus factor is the number for, it's the number equal to the number of project members who can be hit by a bus before your project is in jeopardy. So if one person on your project gets hit by a bus and then the entire project screeches to a halt, you have a bus factor of one. And that is the worst possible bus factor. So anything that can be measured by bus factor should have a succession plan of some variety. Now, when I was talking to people about this, a lot of them would say, 40 years, Han, we've never done this before. Why should we start thinking about it now? We've never done it that way. Well, for starters, the phrase we've always done it this way is probably the most dangerous statement in the English language at least. I can't speak for the others, unfortunately. But aside from that, there are a lot of reasons why you should consider having a succession plan. And they're not necessarily the ones that are the most obvious, but I'll start there. The most obvious one, which is continuity. When somebody leaves your project, what happens to all those tasks they were doing? Do they just fall on the ground? Succession planning helps ensure that tasks continue to be performed and no one is left hanging and your project can continue very smoothly. If a person leaves a role without having a replacement, it can lead to a whole lot of confusion and delays and possible political strife for your project. Now, these political woes, those problems, they can be some of the most damaging things for your project and your group. Delays, you can fix a delay, you can catch them up. Hurt feelings, not so easy to fix. So be careful with these political things. Creating a succession plan, it helps alleviate the very insecure and unstable time when someone in a vital role, in a critical role, has moved on to something else. Everyone knows who's next in line and most particularly, they know why. The thinking required for a succession plan is the same thinking that contributes to project longevity. Duh, I mean, you're taking the long view here. So a succession plan, it ensures continuity and leadership and culture and productivity and it ensures that the project will continue. You're taking the long view of your project, not day by day, but year by year. This is the one nobody really thinks about and I think is one of the most important parts of a succession plan. We talk a lot about helping to have sustainable free and open source software. What are we gonna do to help the maintainers? They're getting burned out. Well, the maintainers can do something to help themselves. You have agency as a maintainer. You can help by coming up with a backup for yourself. If you have that, then you are now free to take vacations. When your child gets sick, you don't have to feel like you have to keep watching that repository all the time to keep the project going because you have somebody who can do that. You've got someone who has your back. Reduces burnout of project leaders and those are important roles. Now, we talk a lot in free and open source software lately in the past few years, thank God, about mentoring. Yay, mentoring, we love it. But we typically talk about helping people code. We have outreach and other amazing organizations that help people start contributing to open source software and that typically means code but there are other ways to contribute. So this talent development, you can have succession plan to help teach people those other critical roles in your project. This helps everyone. The role holders get successors, project organization, they get continuity but the people who are learning these things, they get a lot of new skills that they can apply elsewhere in their lives and those new people get a lot of motivation from seeing a succession plan in action. They see a path, they see where they could go. I could do that someday. Maybe I'll stick around and not just drop the one drive-through contribution on you but I'll stick around because I want to do that over there but they can see it. If you don't have a succession plan, they can't see that, they don't know what the options are. It also, for new people showing up to your project, having a succession plan is motivating because they can look at your project and go, oh wait, they care, they've thought this through, this project actually has it shipped together. If I give them my contribution, I know it's going to have value over the long haul. Succession plans are an amazing opportunity to bring in new people with new ideas into critical roles in the project. Studies show over and over and over again that a diverse leadership on a team it leads to a much more effective project and a much more innovative team because you have more ideas in there, it's great. So use your succession planning as an opportunity to open the door to those new ideas. I have huge problems with this word. So unfortunately, what typically passes for meritocracy is it translates towards hostility for new contributors and it leads to echo chambers. In my not-so-humble opinion, you cannot claim to value merit if you do not take the time to define what merit is. And then you have to train people in that merit. A so-called meritocracy without a mentoring program, without a healthy governance structure is just an excuse to practice subjective discrimination, frankly. It's a way for bullies to hide behind unexpressed biases because merit becomes, I'll know it when I see it rather than defined. Now a succession plan helps with this because you define what merit is. It's very clear, it's very open, it's very obvious. And suddenly people are moving up in the ranks who wouldn't otherwise because it's evident to everyone in the community that, oh, they did earn that because here's what you have to do to earn that. So you can actually start moving closer towards that meritocracy holy grail. Now, quick summary, that's just some of the benefits you can get, these are the highlights of the benefits. There's obviously going to be a lot of different ones for different projects, but there's a lot of great things here and yet we don't do this. Now when I was doing my research, knowing about succession planning is one thing, but if you've got a problem, you have to get to the root of the problem. The root of the problem here is why aren't we doing this? Well, I have answers now. This is the same reason anything doesn't happen in free and open source software, right? A lot of the people I spoke with, they recognize succession planning is a problem and their project needs to work on it but they just hadn't gotten around to it because there's always something more important to do. Now, this, believe me, I can relate, okay? But this isn't a problem with time availability, it's with prioritization. This is a person who has never been bitten in the ass by somebody leaving them and then seeing just how much it can hurt their project. Oh crap, they were a bust factor. I didn't know they were a bust factor. Look, now we're totally hanging. A lot of people are so busy and so preoccupied that they just don't even think about it at all. I mean, why would they need to? I mean, David is always there for me. My project, when I need something done, I turn to David and I was like, Dave, can you make it happen? And he's like, yeah, totally, I'm there. But what if one day he's not? I just haven't had the chance to think about it because he's got my back, right? What if he suddenly moves to Amsterdam? That would never happen. Succession planning is often like estate planning associated with feelings of loss and it can make people address their own mortality and a lot of people aren't comfortable with this. So they will just avoid succession planning altogether. Once in a great while, it doesn't happen often but it does so it's worth mentioning, you'll get a leader who just doesn't want to do this. They don't want to recognize that they're replaceable. They don't want to admit the fact that they might have to give up their power and influence someday. This is a big deal for some people. The failure to recognize this or admit this, it sets the project up for failure in the long run and probably the short run, frankly, I wouldn't want to be a member of that project anyway. But what happened over and over again as I was talking to people is they are willing to set aside the time, they're willing to put in the effort but they just don't know where to start and that's because, again, we don't have the resources for this. They're all for boards of directors and shit like that. We don't do boards of directors very much. Okay, the foundations do but most of us aren't in foundations, we're in smaller projects. So yay, we finally get to how to do this. How do you get started? Well, number one, I'm going to throw a lot of stuff at you. Do not feel you have to do it all, do not feel you have to do it immediately. The thing about succession planning, again, you're taking that long view. It's okay if this takes time, it should take time. You might feel you're not making progress but believe me, if you're working on it at all, that is progress, that's huge progress. So this next section is actually split into two. Number one is the first for people who are currently leaders and leaders I'm using as shorthand for people in critical roles. And then the second bit, if you're not yet in a critical role in a project but you would like to be, you have a place here too, you can actually help with succession planning for your project. So let's start with those current leaders, critical roles. What can you do on your project to help kind of cultivate people to take on your specific position when you move on? Well, before you start, remember you are in an open community here, or you should be, I'd like to think we all are. So you're in an open community, do all your work in the open necessarily, you don't have to take everything to committee and it takes six months to get a single decision. But do keep people posted, tell them what you're doing, tell them why, hey, here's our decision this time, here's our decision that. So do work in the public eye. Now, step one, identify those roles in your project which are critical. You have to know this first before you can move on. Now, I've given this talk before and people are like, Vicky, what's the critical role for my project? And I'm like, I don't know. I can't tell you that. Only you and your project can determine what's really most important, what's most critical for your project. Only you can define that. I sometimes suggest maybe you look at the people in your community and start there, right? But a person is not a role. I can almost guarantee you, nearly everyone in your project is doing multiple roles. So you can start with the people, but then you do have to break it down into the roles. So try and think in roles, not people. Now, once you've identified each of those roles, look at the duties of each specific role. Look at the list of things you think it does, then talk to the person who does it and find out what it actually does. And I guarantee you the second list is going to be a lot longer. So be really open and honest about the legitimate duties of that role. What does it actually do? Because it's possible that role should be refactored and split into at least two, if not more roles. That right there, you split one role into two, you've just improved your bus factor. Right there, just by identifying roles, identifying duties and splitting up the role. So refactoring has another great bonus, which is now that role, each of those roles that you have split out and refactored, they're smaller, they're less intimidating, they're easier for someone new to step into and thrive at. So breaking your roles into smaller roles, really awesome, does great things for your project right there. Now, as you're doing this, do consider limiting the tenure for the role. There are multiple reasons why you might consider this. And again, I'm not gonna tell you how long is best for you. It might make sense for your release manager to be around for a year, for 18 months, six months. I don't know, I can't answer that. Only you can make sense of what works for that role. But doing this, it ensures that that role will be moved on. Oh, I'm getting two different numbers here for time. She had 10. I'll take care of it. I have a timer, I says... Anyway, I'm moving on because I don't have a lot of time. No. So this ensures that it will be handed on. It ensures that you can get that new diversity of thought, those new ideas into that role, which can do amazing things for that role. But even better, it gives a person who's currently holding that role a light at the end of the tunnel. They can see, I only have to do this for six months and I'm gonna log my time and I'm gonna be a great community member and I'm gonna move on to something else. So they don't have to feel trapped in a role. They know they can always move on. But, best yet, and the thing that I have yet to find anyone think about is that what you've just done by limiting the tenure of that role to like six months, if I'm in this role and three people have had it before me, let's say something dramatic happens to my parents and I have to fly home to take care of one of them. Who's gonna take over my role that I'm doing? Those three people who had it before me, it's an instant safety net. You've got people who can help you out. So there are really good reasons to limit a tenure for a role. Once you've identified the roles and the duties, everything else really becomes knowledge transfer. Now, this is going to be an ongoing process but you're probably gonna have to do a big brain dump at first and this is a pain in the ass but do it. What do you do? Well, first, those duties don't just happen. There's a way to do it and there's a why to do it. So write those down, collect the policies, collect the procedures, right? This is really important. Now, remember, you're gonna have a different perspective than the new person coming in. So as you are looking at these policies and procedures, what is evident and obvious to you is not going to be to them. So write down everything even if you think it's too obvious. Collect this. Resources, lists of account. So Twitter, GitLab, GitHub, whatever. What are these accounts associated with your project? Collect those. Those are the obvious ones. The less obvious ones, you ever go to do a meetup and find that the person who had all the contacts for the folks who buy you pizza, they went and scuppered off somewhere and you can no longer get a sponsor for your meetup. The contacts for your project are really important. Those usually are personal contacts but they should be shared. So should that person move along, you don't lose the contact and your project can still continue functioning. No one person, full stop, should ever have credentials for any service for your project. Ever. While you're at it, don't have these services going to somebody's personal email account. Never because then when they scupper off and disappear, if you need to get access to that account and they're not replying to their email, you also can't get an email reminder because it's going to their email address. So have that role account go to multiple people. This also creates accountability because I have seen this used for evil before, unfortunately, where people are embezzling or they're locking others out of the project because they've got their knickers and a twist over something, but if you have multiple people who have access to this stuff, that's less likely to happen or it's going to be more difficult to do. So that's a big CYA there. So make sure when somebody does walk away from your kingdom, they're not walking away with the keys to the kingdom. This is often overlooked when doing knowledge transfer. Please provide some sort of project history for the people coming later on. Again, you're taking the long view here and that part of that long view is documenting how you got to where you are today. And this provides the context for the next people to come along who have to make decisions. Give them that history so they can decide, oh, right, we didn't do it that way for this reason. Give them that information. And for crying out loud, write this shit down, man. You will have spent so much time collecting it and if you don't document it somewhere, why? You will have wasted everybody's time. So write it down, document everything, but I'm here to tell you no one's going to read it. They're not. They're going to look at this great, big, huge 20-page document and they're going to be like, peace out, man, I'm not doing this. So they're not going to read it, but if you give an abstract or a summary at the top of every single document, they can skim that, get the vital information they need and if they want more information, they can deep dive. That made your documents actually useful. People will start using them. I guarantee if you add TLDRs and abstracts at the top. Now, if you're a brand new leader, there are things you can do if you want to step into a critical role. First of all, look for ways to help. Don't expect us to ask you, you ask us. How can I help? Ask to chip in, volunteer for the really small, possibly annoying, but definitely, definitely vital tasks that the people in critical roles aren't able to take on because they're doing bigger things. You will be like the hero of the project if you do this. It's also a great way to apprentice your way into a leadership position. Another way to do that is to shadow people in those critical roles. You want to see how release engineering is done? Great, shadow the release engineer. Then you can see how it's done. More importantly, you can see whether you want to do it later because it could be, it's a real mess. Totally chaotic, you're like, oh man, I just don't want to have anything to do with that. If you shadow them, you can learn that. It's much better than stepping into it and noticing the mess you suddenly have to clean up. Those of us who mentor, we want to help you. But we usually don't ask, right? Ask us, come to us, say, hey, could you help me with? Are there any tasks that I could? Give me advice on. If you perform tasks, ask for feedback. And we are very happy to help you, but we forget. So sometimes we need your reminder. So ask us how to do these things. And then come to things like this and learn the history of your project and then write it down in those docs because I can guarantee while it's so important the people who are working on this accession plan are gonna forget it and not do it. So pick up that baton and do it. Now, I was going to give examples of projects that do this badly, but in my research, I discovered I don't have to. Yay, we all know projects that don't do this because we're in projects that don't do this. So instead, I have two examples of projects that actually are doing something along these succession planning lines and they're amazing. Very briefly, obviously, only two, this is not a complete list. Number one, exorcism.io. Fantastic service and open source project. They will do anything possible to help you land your first patch. They have dozens of language tracks and they did a review to make sure everyone could actually, you know, had support. They now have two to three maintainers for every language track. It's great, they're doing an amazing project on this. And Vox Popoli, the entire project is a succession plan for puppet modules. That would otherwise be orphaned somewhere without maintainers. You can instead give it to Vox Popoli and the entire project will maintain them and share that burden. They're great. Image credits you don't need to see. Here's this. Slides will be available. Our slides are available now. Video will be available soon. Thank you. I will shimmy down. We can have time for a couple of questions. Oh, there's actually time for questions. Yeah. Awesome. We're gonna make time for three questions because we appreciate you. Anybody have questions? Yes, sir. What's your name? Michael. Hi, Michael. Do you have any recommendations for all the credential stuff? The thing is, I'm holding any project and we have several internet domains and since we are not an organization, all the different domains are registered for different persons and sharing these credentials to the whole management and so it's a problem since domains mostly are connected to persons. So how could one do this? It's complicated and that's not a quick answer. I mean, that is the quick answer, but there is no quick answer. I mean, it's like key pass and form a foundation and blah, blah, blah and join a foundation. There's lots of ways to approach it. There's no one silver bullet. I don't know what your problems you need to get fixed specifically, but I can't give you a quick answer on that. I'm sorry. Yes, Remi dear? No. Okay, cool. No, there are none, specifically not for our, there's none for free and open source software and as far as I can tell, there are no really good ones for the foundation level either, like not for board of directors, that sort of thing. It's something that each, you get an HR professional and they help you with it, is what you normally do and we can't do that. But good question. No one's ever asked that one. He's still setting up. Can I go? We're gonna go to the last question, sorry. Okay. We only have one. Okay.