Tag Archives: risk

General

Assessing the Viability of Open Source Projects

Various types of purple dice with white letters, including a traditional D6 die, a D20, and others. Sitting on a white piece of paper with blurred writing.

I’m thrilled to announce that we just launched the Practitioner Guide: Assessing Viability, which is the latest in the CHAOSS Practitioner Guide series! A huge thank you to Gary White Jr. who wrote quite a bit of this guide along with the viability metrics models that it’s based on.

The topic of viability and risk is one that’s near and dear to my heart, and is something that I’ve been talking and speaking about for the past 5 years going back to when I was at VMware where it was an important consideration for our Open Source Program Office.

Open source software is found in almost every codebase, but some open source projects are more viable than others over the long term. Many companies don’t have a rigorous process for selecting the most viable dependencies. Often product teams, or even individual software developers, select open source projects because they fill a particular technical need without any assessment of the viability of the project or the risks they might be taking by using it. Assessing the viability of open source projects, especially ones that have the potential to impact your business, is a good first step toward managing risk and reducing the chances of potential business disruptions.

Here’s a short quote from the guide:

“Most business decisions boil down to an assessment of risk and making tradeoffs. Organizations should be thinking strategically about project risks in light of how they are using the projects. If it’s a critical part of a technology stack, it should be as low of a risk as possible. On the other hand, if an open source project is used as a small part of some non-critical infrastructure, an organization can accept more risk. Assessing viability and thinking about it from the perspective of risk and which risks to accept is an important first step, but it’s also important to think about which risks can be mitigated to improve viability. The best way to mitigate many of these risks is by paying employees to contribute to the projects that are most important to your organization. This provides an opportunity to improve viability and sustainability, but it also provides insight into where the project is heading and how things are going, so that if something changes in the project to further increase risk, it might be easier to anticipate those changes.”

– The CHAOSS Practitioner Guide: Assessing Viability

This guide provides advice for assessing viability across four categories: compliance and security, governance, community, and strategy. Depending on your use case, you may find different opportunities to use this viability assessment framework and how you use it will vary based on your organization’s assumption of risk. I hope you enjoy this guide and the others in the CHAOSS Practitioner Guide series!

Additional Reading:

Photo by Ian Gonzalez on Unsplash

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