13

Transitioning Leadership

“The greatest leader is not necessarily the one who does the greatest things. He is the one that gets the people to do the greatest things.”

—Ronald Reagan

I once heard someone say that their goal as a parent was to raise kids that would be better parents than they were. And this was a really good parent saying this, one giving training and support to parents. What it speaks to is the intent to always know that your work can be improved upon and made better and that your humility will help it get there. Legacies aren’t built from the work of your own hands, but by the impact and effect you have on others.

When I speak to projects about open source leadership, I emphasize the importance of servant leadership in open source communities. Contributors and users, unlike employees, don’t have a financial binding to a project community; they participate because they want to be there. And the bigger part of the success and the work done in a project is because of those contributors and users; if they aren’t there, there quickly becomes a lack of resources for development and, further, no audience for the projects. Being a great leader means ensuring those contributors and users can do great work in the project or with the code that comes from the project. Or better put, being a great leader means you are putting the needs of the project before your desires.

Leadership in open source projects is also a thankless job. In Chapter 7, Growing Contributors to Maintainers, we talked about the stress on open source project maintainers, as projects are used ubiquitously around the world, and typically a small percentage of users end up making any contributor back to a project outside of a support or bug fix request. It’s a job that is certainly done out of passion and is usually hard to recruit. Often, when I work with projects in early formation, and the question comes up, “who should be the project chairperson?”, everyone goes immediately silent. It’s not all because of the workload either; most developers don’t feel they have what it takes to lead a project, and often, they do but just don’t realize it.

Open source projects, by the nature of having code put out under an open source license, are indefinite, but those contributors and maintainers aren’t around forever. Projects must consider transitioning to the next set of leaders to be successful and sustainable. In this chapter, we will explore how to do that effectively:

  • Why even think about transitioning leadership?
  • Building a plan
  • Stepping back comfortably

Let’s start this chapter by answering an important question: why transition leadership at all?

Why even think about transitioning leadership?

Not all projects are forever, but once code is put out under an open source license, it is out there forever. While it’s perfectly okay if a project sunsets (something we will discuss in Chapter 14, Sunsetting an Open Source Project), if the project is actively being used or has a vibrant community, bringing new leadership into a project is important for its sustainability.

There are many reasons why projects need to think about transitioning leadership, but there are three main patterns we tend to see that projects encounter: career change, project leaders nearing retirement, and a project stalling. Let’s start with one of the most common: the leader has a career change.

Career change

In my post-university career up to this point, I’ve worked for four different organizations (which in tech is a really low number over 20 years). And my career focus changed over that time as well, as I spoke about when chronicling my career in Chapter 11, Open Source and the Talent Ecosystem. In generations before ours, it tended to be more common for someone to stay in the same profession for life; in our current world, that isn’t a reality.

Going back to Chapter 11, Open Source and the Talent Ecosystem, open source projects are often used as a jumping-off point for a larger career. Someone might start a project to get on the radar of a larger company, and when they land that dream job, the open source project hits the back burner. This doesn’t happen all the time; many developers like the open source project they are leading and work with their prospective employers to ensure they have the time to continue to maintain their project(s). Often, those employers are highly incentivized to allow this because typically, they are hired because the project is quite important to the employer.

Many who are skilled in software development do end up staying in that profession but might change focuses or domains. For example, someone who started as a full-stack developer (meaning they have no one area of an application stack they focus on but can be a software developer in multiple layers of an application stack) might look to specialize in frontend development (such as JavaScript coding or user interface design). If they have projects that are more focused on backend development (such as application logic or other backend libraries), they might not have the time to focus on those projects as it doesn’t relate as much to their daily work. Additionally, as trends change over time and new technologies emerge, the developer likely would not be as current. Sometimes, that’s a good thing; there’s plenty of legacy code out there and a project supporting that isn’t a bad thing. But largely, you will see the developer lose interest in the project and it gradually slows to a halt.

Career change is one aspect needed to transition leadership, but also is the biggest career change for all of us – retirement. Let’s look at that now.

Project leaders near retirement

One thing that has come more to the forefront for me as my career progresses is the mortality of it all. You don’t think about retirement as much as when you’re in your 20s, but come your 40s and 50s, it’s closer for you than the beginning of your career. All of us do retirement planning as part of our jobs in one form or another; in the United States, we have 401k and/or IRA plans that we contribute to, to ensure we have money at retirement. Our open source projects need that same planning since the code will live on without us.

Just as in the career change model, the pattern you typically see is the benevolent dictator model being the current leadership, and then either a transition to a new leader or a Technical Council, Elected, or Vendor-neutral foundation model of governance (see Chapter 5, Governance and Hosting Models, for more details on each of those models). It’s often hard to find that same type of person that can step in with the same passion and broad skillsets as the current benevolent dictator, or the project has such mass adoption that a single leader cannot handle it all.

Projects such as Ruby, Python, and PHP transitioned from the benevolent dictator model to the Vendor-neutral foundation. PHP took the longest to get there as they went through the cycles of Technical Council and then Elected over two decades before launching the PHP Foundation in 2021. Ruby and Python moved to a Vendor-neutral foundation much faster; Ruby with Ruby Central in 2001 (5 years after Ruby 1.0) and Python with the Python Software Foundation also in 2001 (10 years after Python 0.9.0). Interestingly, the Python Software Foundation preceded the transition from Guido van Rossum as the benevolent dictator for life to a Technical Council in 2019; that isn’t an uncommon problem as changing the governance for a project can be very disruptive, so focusing on succession and long-term asset management is the first and foremost concern. The Linux kernel is a good example here, with Linus Torvalds serving as the benevolent dictator here in 2023, and the CBT Tape project we spoke about in Chapter 1, The Whats and Whys of Open Source, being hosted by the Open Mainframe Project and Linux Foundation while having Sam Golob as the current sole leader.

With that, we have looked at two aspects of transitioning leadership where the leader is active but needs to move on. But what if the leader isn’t all that active? Let’s look at the case where the project might be stalling out.

The project is stalling

There is always lots of excitement when you start an open source project. Code begins to flow in, the repository is getting structured, and you see people downloading the code and trying it out. But over time, maintainers get busy in other areas of life, lose interest in the project, no longer have the same needs that the code addressed, or might just consider the work “done” and stop development. I did a quick search of GitHub and found that there were over 26 million GitHub repositories that haven’t been updated since before 2021, with just over 12 million updated since, so projects stalling out is certainly prevalent.

For a leadership transition, I’d break down project stalling into two categories: projects that are “done/no longer relevant” and projects that have been “abandoned,” meaning the maintainer for whatever reason is no longer maintaining the project. It’s hard to make the determination on which category a project is in, but there are some clues and tells that can help:

  • Does the project address a technology that is current or not? For example, the project at https://github.com/nudded/GoogleReaderAPI is a Ruby wrapper for the Google Reader API. Google Reader was shut down on July 1, 2013, so this project is likely in the “done/no longer relevant” category.
  • Does the project have lots of pull requests/issues that were opened after the last commit to the main repository? This likely means there is some user base around the code and probably falls into the “abandoned” category.
  • If the project has an automated CI/CD build system, did the last build succeed or fail? When was the last time there was a successful build? If it’s been over a year since the last successful build, that probably means the project falls into the “abandoned” category.

One thing that is not a great indicator is when the last commit was; again, a project might be considered feature complete or done, so there won’t be many (if any) changes. Or, some projects have a slow code velocity. OpenEXR (https://github.com/AcademySoftwareFoundation/openexr/commits/main) had only one commit to main in December 2022 and one commit to main in January 2023; knowing those maintainers, they certainly haven’t abandoned the project, but considering that many projects will slow down in December and the maintainers tend to have other focuses after the holidays, this shows that velocity slowed down.

The big thing I want to emphasize is that before you declare a project as “abandoned,” reach out to the maintainers and see if you can help. Some maintainers might take that as an invitation for you to take over the project; others might give you some sort of limited access to get things back moving as they still have interest but just lack the time currently. And sometimes, you hear nothing back; in those cases, it usually makes sense to create a fork so that you can continue with its development; if the maintainer emerges, they likely will appreciate all the work done and might bring you in as a maintainer. It’s crucial to be respectful to the maintainer; they put their intellectual property out there under an open source license and it’s helped you solve a problem, so working with them to make the code better versus forking without upstreaming the code back to them is generally the best approach.

Now that we understand the reasons why projects need to think about leadership transition, let’s look at how a project can be proactive in building a succession plan.

Building a plan

Succession planning is something you see many organizations spend considerable time developing, especially large and long-running ones. These organizations build succession plans because they have people that depend on the organization in one way or another; they might be employees, customers, and/or investors who have a vested interest in an organization continuing to operate successfully over time.

Open source projects similarly dependent on a large user community must also consider succession planning. Succession planning is not a single process, but it involves a few different pieces and can take some time to complete fully. But before you can start bringing in a new leader, you need to ensure the project’s operations are well documented. Let’s look at how to do that now.

Documenting your project’s operation

In Chapter 5, Governance and Hosting Models, we talked about the importance of writing down your governance, not only for everyone to be clear on how things work but, more importantly, as it’s easy to forget all the policies and processes a project has, especially when they are infrequent. As we consider succession planning, the documentation needs to go down another level to document how a project’s operational aspects work.

Here are some key things to have documented:

  • Credentials for any services the project uses (social media, build resources, code repositories, scanning tools, and any other collaboration tools). These credentials should be saved in a secure vault owned by the project; there are several services a project can use, such as Bitwarden or 1Password, that provide free accounts for open source projects.
  • How the build and test infrastructure works, including the services and tools that are used and how they interact and work together.
  • How to install or deploy the project’s code.
  • Release plans and roadmap.
  • Code architecture and design.

Much of this seems trivial, but imagine if a maintainer is not around and it’s all stuck in his or her’s head; the project can certainly recover, but days and weeks must be spent trying to recreate this. And some of these items – such as credentials to various tools and services – are sometimes nearly impossible to access, and new resources must be built. I’ve seen it too many times where a maintainer of an open source project seemingly disappeared, and you see users scrambling to find out how to get access.

The curl project (https://github.com/curl/curl) has great project operations documentation. Some good reads they have are as follows:

The curl project goes into further details, which gets more into governance itself, down to etiquette and conduct standards, how security issues are managed, and even a history of the project. The history of the project is especially useful as it helps give a sense of the lineage of the project and gives future maintainers insight into its past.

Documentation is an ongoing process and something that a project should start early on and continue to maintain. While researching for this book, I came across a great article on open source project documentation (https://opensource.com/article/20/3/documentation) that recommended a project maintainer spend 10-20% of their time writing things down; I think that’s a great measure for a project to align to. Speaking from experience of inheriting old code bases and transitioning projects to others, you never regret the time spent writing documentation.

With documentation in flight, the next phase is to start implementing a process for a leadership transition. Let’s look at that now.

Timelines and enablement for new leaders

If an open source project were a public company, the Board of Directors would think about succession plans for key leaders such as the CEO from day 1. It seems odd at first glance; why would you plan for the new leader’s successor when you just appointed them? For one, you never know when a CEO will look to leave the organization, die, or be underperforming, so having potential successors in the wings helps expedite any leadership transitions. But more importantly, it gives the organization a chance to mentor and groom future leaders using the wisdom and experience of the current leaders. As we discussed in Chapter 7, Growing Contributors to Maintainers, developing new maintainers is best done with mentorship from the current maintainers, using a gradual and intentional process along the way.

Now, open source projects typically don’t have the same ability to have leaders-to-be in the wings waiting to be named a new project leader. Frankly, it’s hard to find people willing to lead projects, let alone qualified. Open source projects don’t have thousands of employees globally; most are single-maintainer projects, and only a small number of projects have more than a few dozen maintainers. And executive leaders in public companies typically have a generous compensation package, which is quite appropriate considering the responsibility and duties of the role. Open source project maintainers are rarely compensated, and when they are, it’s very much below market rates.

But what open source projects can learn from public companies’ succession plans is that planning ahead is better than scrambling when it’s too late. The best way to set timelines is by working in reverse; when must the transition be done? This enables a project to set milestones along the way and realistically determine what degree of transition can occur.

Borrowing from the plans we would see in public companies, here’s a good way for open source projects to make succession plans:

  1. Assess how long the current maintainer/leader expects to be in their role. Are they only wanting to lead it for a year or two? Do they want to lead indefinitely?
  2. Is it realistic to think one person could replace the current maintainer/leader, or should multiple people take on parts of the role? Ruby and Python were great examples where the benevolent dictators were truly unique individuals that a single person couldn’t replace – and additionally, the needs of a growing project meant there would be additional needs over time that even the perfect replacement benevolent dictator couldn’t fulfill. This might lead to moving governance structures as part of the leadership transition.
  3. Identify potential leader(s) and have them take on some of the duties and shadow the current leaders. As we talked about in Chapter 7, Growing Contributors to Maintainers, this will also help determine if there is a mutual fit between the person, the role, and the project.
  4. Get input on any leadership structure changes from key community members. See how they would react to a change and what things they see that should be considered as the project goes through the transition period. The key part is that you want to set up the new leaders and leadership structure for success.
  5. Publically announce the new leaders and leadership structure. Ensure you give the community a chance to ask questions and engage the new and previous leaders. Transparency is key as you go public; you must provide the community with as much context and insight as possible so they can understand why the transition happened.

Not all projects will have the luxury of having other maintainers able to plan leader succession to this degree; smaller projects might have only two to three maintainers. But the same general process and structure apply; each maintainer should realistically think of how long they want to serve in their maintainer role, determine the best way for them to be replaced, and then find and mentor those replacements. What is key here is thinking intentionally and with a plan for the future; if people depend on your project, it’s important to ensure there is a plan for how a project can be sustained over time.

Once a project has a transition plan, it’s time to implement it. In my experience, the hardest part of that plan is for the previous leaders to step back. Let’s look at how to do that comfortably for both the new and current leaders and the community as a whole.

Stepping back comfortably

Even with the best transition plan done, it’s hard to “cold turkey” step back from a project. Stepping back is a gradual process, where the new maintainers and leaders can take over the activities while reducing their dependencies on the maintainers they plan to replace. Many maintainers tend to err on the side of caution when stepping back; after all, they put lots of energy and passion into the project and want to be certain that it will be in good hands (not always, of course; some maintainers might be so burnt out by the project that they are just thrilled to find someone to take it off their hands… hehe).

Presuming a maintainer wants to ensure a smooth transition, there are a few things they should do. We’ll look at them in the upcoming subsections.

Being appropriately available

The most important thing is to ensure their previous maintainers don’t completely disappear. But this has to be done with caution; you don’t want to appear to be meddling or micromanaging the new leaders, but simultaneously you want to be a resource for those leaders as they run into challenges or need advice. Being an open source project leader is a lonely job, and having someone who has been in that role can provide great support and encouragement to those new leaders.

I’ve worked with a few communities that have undergone leadership changes and having previous leaders available as a resource was of immense value. In one project, the transition happened in the first year as the leader had to step away due to a job change and family illnesses. The previous leader would try to attend meetings and respond to emails occasionally after stepping down, but that leadership group would reach out to the person for questions they had or to understand past decisions made. It went quite well, and the new leaders have done a solid job of growing and maturing the project.

In another project, the project leader stepped down as they became absent from the project frequently, and other maintainers would need to step in and review pull requests and address issues in their absence. The project leader stepping down was not something they truly wanted to do; they saw much of their identity in the project, and they struggled to step back truly. This caused a lot of friction with other developers; the previous leader would start conversations in the community on directions for the project that wasn’t representative of the other maintainers (in fact, much of the time, the other maintainers never even heard of the ideas proposed). This hit a breaking point after some time, requiring the past project leader and the current maintainers to meet to discuss the issues. In this case, the past project leader saw the project as an outlet for them; when the project leader had to step back, they had several family and personal issues ongoing. Participating in the project brought them a sense of belonging, but they struggled to find the best way to get involved again. In the end, the maintainers brought back the previous project leader in a limited role to focus on getting feedback from users and helping triage issues; something they truly enjoyed doing.

Being available is one thing, but previous maintainers don’t always have all the answers. Let’s look at helping those new maintainers with a broader support network.

Endorsing the new leaders

I sometimes get organizations that bring an open source project into a vendor-neutral foundation and become worried; what if the community takes over the whole project and pushes them out? I can understand the fear; it’s a loss of control from a legislative perspective, and the decision-makers will no longer be dominated by one company. In reality, once it’s in a vendor-neutral foundation, newcomers to the project tend to defer to the contributing organization around most key decisions. From those newcomers’ perspectives, the vision and work the contributing organization put into the project, not to mention the gratitude the newcomers have for the contributing organization for contributing its intellectual property under an open source license, positions the contributing organization as “elders” in the project community.

This means that when new leaders emerge, those leaders, while they might have the “legislative” powers, might not have the “effective” powers. Open source is a scratch-your-own-itch model, and any project can be forked at any time, so if community members don’t like the new leaders, they could either move on from the project or take it somewhere else to change its direction. Forks are very distracting for an open source project and generally result in either the fork or the main project winning out. When friction like this happens in the community when new leaders come in, this is where the previous maintainers can step in and help with endorsing the new leaders.

This is something previous maintainers have to be careful with; the new leaders might have made decisions or actions that aren’t something the previous maintainers would be supportive of. Generally, previous maintainers have built up a fair amount of social equity with the community for their contributions, but that social equity can vanish quickly. At the same time, previous maintainers don’t want to undercut the new leaders. It’s a tricky balance. Good previous maintainers try to point the direction of the project to look toward the future and then continue to support the current maintainers to help them through rough patches.

Setting the right support network for new maintainers

I remember when I first became a community manager at SugarCRM and quickly realized “there aren’t a lot of us community managers around.” I ran into the same challenge when I started leading OpenSocial and, later, ODPi; it’s a small circle of people with experience in open source, so it’s best to leverage that collective wisdom.

Just as new leaders need to embrace their elders, it is just as important for them to embrace and learn from their contemporaries. There are lots of patterns you see that are successful in open source projects, and being able to share them is important for not only the project to succeed, but the entire discipline of open source project leadership to thrive (which is exactly the motivation for writing this book).

Here are some tips to get started:

  • Attend open source conferences, as that’s where open source leaders will be. Introduce yourself, buy them a coffee or other beverage, and learn more about them. The hallway track at these conferences is full of amazing expertise, and these people are generally passionate about helping other open source projects thrive.
  • Keep the dialog going when you find a few project leaders you admire and find easy to chat with. Set up regular check-in meetings, offering to be a listening ear to them as much as you would like them to be for you.
  • Consider starting a blog to talk about your experiences as a maintainer. Mike McQuaid is one of the project leaders for Homebrew (brew.sh) and has a great blog where he shares his insights on being a maintainer (https://mikemcquaid.com/); I’m sure writing all this down has helped broker great conversations with other project maintainers, and at the same time has likely been quite therapeutic… hehe.

With the right support, new leaders are set up for success. But sometimes, the community also needs that nudge to see the new leaders as the true project leaders. Let’s look at the role of previous maintainers in endorsing the new leaders in the next chapter.

Summary

In this chapter, we addressed transitioning open source project leadership, looking first at why projects should consider succession planning as maintainers might be looking to change careers, getting ready to retire, or perhaps disappearing from the project itself. We then looked at building a plan for transitioning a project, including ensuring the project’s documentation is in order and building a full transition plan. Finally, we looked at how previous maintainers could step back comfortably and be supportive of the new maintainers.

Succession planning is hard for projects, not just because of the work required but because of the reality of our mortality. We never want to think of the day we step back from our work and hand it to the next person to take it forward. We might think the next person won’t do as good a job as we will. The reality is, that feeling is because we won’t know what to do once the work is on to the next person. But there’s always a new adventure ahead of us.

While transitioning to new leadership is one exit for a maintainer and their open source project, sometimes, the project has run its course, and it’s time to shut it down. This is known as sunsetting and is what we’ll look at in the next chapter.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset