Tag Archives: contributor sustainability

General

Governance Part 3: New Contributors and Pathways to Leadership

Black ladder going through a slot in a canyon with reddish orange rock.

This is the third blog post in a series about open source project governance, so you might want to pause and read the first post about why governance is important and the second one about defining governance before continuing.

It can be difficult to get people to contribute to your open source project, and unfortunately, there is no magic or one size fits all solution. Many projects struggle to find people who will actively participate and continue to participate over the long term. If it was easy, you would already have all of the people you needed to maintain your project, and you wouldn’t be reading this blog post. But not all is lost, there are things you can do to increase the chances of growing your contributor base for your open source project.

Good contributor documentation, especially for new contributors, is the first step toward bringing new people into your project in a scalable way that requires less time from busy maintainers. If this is well documented, new contributors can get started with a minimal amount of help from existing maintainers, which can save you a lot of time in the long run and reduce frustration for maintainers who are answering the same questions over and over. At a minimum, you should have instructions for everything that is required to get your project up and running in a development environment along with the process and guidelines for submitting a new contribution.

Defining the roles and responsibilities for contributors, reviewers, and maintainers can help with recruiting new people into these roles. You can think of this as a ladder because contributors climb up to become reviewers and those reviewers can become maintainers. What’s important is to have some documentation so that people understand how they can climb the ladder and gain more responsibilities within the project.

A contributor ladder usually outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the ladder and advance up it as their involvement in the project grows. This helps set expectations for the roles and encourages people to think about how they might take on increasing responsibility within the project. As you get more of the people moving into maintainer roles, you can reduce the workload for the existing maintainers.

As a maintainer, when you are reviewing contributions and engaging in the community, think about and notice when someone is making solid contributions, which can help you decide who you can encourage to contribute more or maybe find someone who could move into a maintainer or other leadership role. Reaching out to someone and acknowledging their work while encouraging them to do more can help quite a bit with growing your contributor base. Sometimes people just need a bit of encouragement, and you can ask them for specific things that you know they are good at. 

You should also be thinking about how you can move people into leadership positions to be responsible for activities beyond writing code, like documentation, community management, marketing, and other important roles. These activities take up valuable time from maintainers and someone with expertise in these roles can often do these activities more efficiently and with higher quality than a maintainer without that specific expertise. You can add these to your contributor ladder and promote people into maintainer roles to be responsible for things like community management, documentation, program or product management, marketing, and more as your project grows to need these roles. 

Maintaining an open source project is so much work, and many maintainers are overworked, exhausted, and burning out. The best way to address this challenge is by finding people who can reduce your workload, but it’s hard work, and it takes time away from the day to day activities now, which can be hard to justify when you feel like you’re barely keeping up as it is. In the longer term, spending at least a little time on things that can help you recruit and keep new contributors that can eventually become maintainers will be worth it. You don’t need to do everything at once, and many of the suggestions above can be taken in small steps, one at a time. Spending just a little time on something to grow your contributor base and recruit new reviewers and maintainers is a great way to start.

Additional Resources:

This is the third post in a series about governance, so stay tuned for more blog posts about creating intentional culture and project ownership.

Photo by Paulius Dragunas on Unsplash

General

From First PR To Lifelong Impact: Helping People Thrive in Open Source

Slide in the background titled From First PR To Lifelong Impact: Helping People Thrive in Open Source with avatars of the 4 speakers who are sitting on tall chairs in front of the slide from left to right Matt Denny, Shuah Khan, Ruth Ikegah, and Dawn Foster. In the foreground are slightly out of focus audience members from the back of the room.

I spend a lot of time thinking about the sustainability of open source projects and the role that contributor sustainability plays in overall project sustainability. This involves more than just attracting contributors, but in ensuring they stay, grow, and thrive within our open source projects, and that can be a lot easier if we think outside of our traditional boxes and get creative about recruiting and retaining contributors.

Within the CHAOSS project, some of our most successful initiatives are driven mostly or partly by folks from our CHAOSS Africa chapter. We also have a CHAOSS Asia chapter that has recently re-started and is also driving some interesting work within the project. As a result, I’ve seen first hand some of the challenges, but also the rewards, that come from making it easier for people to contribute from countries that haven’t always been well-represented in many open source projects.

On a similar note, until recently, I was co-chair of the CNCF Contributor Strategy Technical Advisory Group where we were working to help CNCF projects grow their contributor bases. The CNCF mentoring programs were managed out of this group, and I was struck by how many mentees stick around after their time in the program with some mentees even becoming mentors! Another initiative within this group was the Deaf and Hard-of-hearing Working Group where I was inspired by all of the amazing work to help folks more actively participate in CNCF events and projects! This work was so successful that a second group was created by people from the blind and visually impaired community with similar goals of making it easier for people to participate.

All of this work got me thinking about how traditional pathways into open source don’t work for everyone and that we need to expand our contributor pipelines beyond the usual audiences if we want to have more sustainable open source projects where everyone can feel comfortable participating. This was the idea behind bringing together a panel of experts at the recent Open Source Summit in Denver where I led a panel discussion about this topic with Shuah Khan, Ruth Ikegah, and Matt Denny. I hope you enjoy this video of our discussion!

Note: A huge thank you to Sandeep Kanabar who helped put this proposal together, but was unable to attend at the last minute, and thanks again to Matt for stepping in on short notice! 

Resources and Links:

Related Fast Wonder blog posts:

Photo by The Linux Foundation used under the CC BY-NC 4.0 license.

General

Companies Can Mitigate Sustainability Risks

A bunch of people having a great time in a fun picture from CHAOSScon EU

I wrote a blog post earlier this week, Contributor Sustainability Impacts Risk and Adoption of OSS Projects, focused on helping maintainers and open source project leaders understand how companies view risk and how this impacts adoption of their projects. Marko Bevc commented on Bluesky that “there is another side of this coin while companies evaluate the risk (as they should), they should also look into how they are going to support those projects they use (either with contributions or/and other resources – e.g. funding).” This is a really important point, and it’s something that I always bring up when talking to companies about evaluating risk (20 min into this video, for example), so I decided to write a part 2 for the original post, but this time focused on what companies can do to mitigate contributor sustainability risks when adopting open source software.

As part of spending a lot of time over the years thinking about the sustainability of open source projects, I’ve given a bunch of talks (see Additional Resources section below) about how companies can assess the risk and viability of open source projects, but assessing viability is the beginning of the process, not the end. Understanding open source project viability is an ongoing process that needs to be monitored and decisions revisited as projects evolve. As a company, the best way to monitor the ongoing viability of a project is to have your employees contributing and participating within the project. This serves another important purpose beyond just monitoring. By having your employees participating in a project, you can help to continuously improve the viability of that project to increase the chances that it will continue to be viable over the longer-term. 

However, most companies use so many open source projects that you can’t possibly employ contributors to participate in all of them. Generally, I recommend that companies focus their contributions on strategic open source projects that are critical to your ability to deliver customer-facing products or services. For the other projects that you don’t contribute to directly, you might still be able to help them increase their viability in other ways, like through funding, for example. Some companies have funding programs where they fund key dependencies and other projects (e.g., FOSS Funders, Microsoft’s FOSS Fund, Bloomberg’s FOSS Fund). However, it’s also important to think about the impact of providing funding because throwing money at some projects can create friction within the project that can sometimes have a negative impact, while in other projects, funding can make a big difference in increasing viability. We discuss these and other funding issues regularly as part of the CHAOSS Funding Impact Measurement Working Group, and we also maintain a list of resources and research about funding.

To wrap this up, open source sustainability and viability are not something that you can think of as all or nothing. No project is perfect, and each project will have areas within them that are more or less sustainable. Companies can help make projects more sustainable and more viable over time by providing resources, like direct employee contribution and funding for those projects. 

Additional Resources:

General

Contributor Sustainability Impacts Risk and Adoption of OSS Projects

I’ve spent a lot of time over the years thinking about the sustainability of open source projects and the role that contributor sustainability plays in overall project sustainability. When I was co-chair of the CNCF Contributor Strategy Technical Advisory Group, contributor sustainability came up often as a concern for CNCF projects, and the most common question was about how to get more people contributing to our projects. This is a hard problem, but there are some resources at the bottom of this post to help grow your contributor base and increase the sustainability of your open source projects.

What I think many people underestimate is how contributor sustainability is viewed through the lens of risk by companies who are deciding whether to adopt your project. It’s easy to think that your project is different. No one will leave, and the project will be wildly successful forever, but that’s not how many companies think about open source adoption. Some companies think hard about which projects to adopt, especially if those technologies are crucial for delivering solutions to their customers, and would be difficult to replace if the project suddenly wasn’t available. Projects with a single dominant contributor or contributions coming almost entirely from a single company are going to be perceived as riskier and companies will be less likely to adopt or use those projects. This is especially true given the recent wave of companies relicensing open source projects and putting them under proprietary licenses. Put in simple terms, contributor sustainability risk makes it harder to get people to adopt your open source projects.

When I was Director of Open Source Community Strategy at VMware, I would often evaluate the risks of adopting specific open source projects, especially if we were considering building commercial products that incorporated those open source technologies in ways that were critical to delivering products to our customers. Contributor sustainability played a big role in deciding whether we would adopt a project. This was especially true for projects that were more strategically important for us, and which would be hard to replace if the project became unsustainable in the future. Given the choice, we’d select projects with better contributor sustainability, which would be a lower risk for us as a company.

Just last week, I was looking at an open source project where almost all of the contributions came from employees of the company driving the project, and there was a single lead developer who made the vast majority of the contributions and code reviews / approvals. That lead developer and their employer are single points of failure for the project. These single points of failure introduce risk for potential adopters and are likely to cause people to think twice before using a project. If I was a company looking for a solution, I would be unlikely to select a project that could suddenly cease to be updated (including security updates) if something happened to the dominant contributor or the company.

In summary, contributor risk stemming from a single person or a single employer makes your project riskier and less likely to be adopted.

While growing your contributor base is hard work, there are quite a few resources to help you improve contributor sustainability along with gaining a better understanding about how companies think about risk when adopting open source projects. Here are a few of those resources, most of which also have links to additional resources:

Update: You might also be interested in reading this follow up post: Companies Can Mitigate Sustainability Risks

Photo by Jan Kopřiva on Unsplash