Tag Archives: contributor sustainability

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