Every time your organization uses any technology, open source or otherwise, you take some risks. Thinking about the risks that open source presents reminds me of an xkcd comic showing how all modern infrastructure is precariously built on a project maintained by a random person in Nebraska. This scenario is actually more common than you might think.
There are ways to look at and address these risks across several categories. By evaluating those risks, you can help make the right business decisions about using and contributing to cloud-native, open-source projects.
Here are the questions you need to ask, and how to address the risks the answers may present.
1. What do you know about the contributors?
For any open-source projects that you rely on, are there enough contributors from enough organizations? The reason behind this question is to ensure the project could continue uninterrupted if something dramatically changes with one contributor or organization.
This is a bigger risk for projects that are highly complex or that contain technologies that require specialized expertise. You should also look at where those contributors are employed. If most of them work at the same company, you'll want to think about what might happen if that company changes its strategy or is acquired. It might even run out of money or go out of business.
Ultimately, you should ask yourself whether the project is likely to be successful if all of that company's employees left the project.
2. Who's in control?
Another important indicator of risk relates to who owns or controls an open-source project. From a risk perspective, projects with neutral governance, where decisions are made by people from a variety of different companies, present a lower risk. The lowest-risk projects are ones that fall under vendor-neutral foundations.
Kubernetes has been successful in part because it is shepherded by the Cloud Native Computing Foundation (CNCF). Putting Kubernetes into a neutral foundation provided a level playing field where people from different companies could work together as equals, to create something that benefits the entire ecosystem.
The CNCF focuses on helping cloud-native projects set themselves up to be successful with resource documents, maintainer sessions, and help with various administrative tasks.
In contrast, open-source projects controlled by a single company have higher risk because they operate at the whims of that company. Outside contributors have little recourse if that company decides to go in a direction that doesn't align with the expectations of the community's other participants. This can manifest as licensing changes, forks, or other governance issues within a project.
3. Is the governance documentation clear?
Reading the governance documentation for a project can also help you learn about potential risks. Projects with sparse or no governance documentation are a higher risk due to the potential for misunderstanding and unclear expectations.
Governance is designed to outline expectations around roles and responsibilities along with the decision-making processes, but it varies with the size of the project.
The CNCF encourages governance documentation for all projects. By the time a project reaches the incubation phase, the contributors managing the project need to have a governance.md file that shows who is leading the project and the process for selecting future leaders, with a requirement that the process be employer-neutral.
The key is that having a fair and transparent process for selecting leaders, such as elections, for example, reduces your risk, since your contributors can participate in the elections and have a say in the governance of the project.
4. Does the project have a charter? What's in it?
The project should also have some kind of project charter, which can take many different forms. Often it's not called a charter at all, but takes the form of a mission statement, scope, values, principles, and similar concepts often found within the governance documents and/or various project README files.
The overall cloud-native ecosystem is complex, and many projects contain overlapping functionality. A charter can help end users understand how your project fits into the overall ecosystem and what functionality it does or does not offer compared to the many alternatives. Having this documented can help avoid issues and misunderstandings later, which helps to reduce risk.
5. What is the community's culture?
The community can also have a big impact on overall project risk. Look at how people treat each other within the community, including on the mailing lists, in GitHub reviews, on Slack/IRC, and other communication channels. Projects with a culture built on respect and kindness have lower risk because your employees will enjoy participating in the community.
On the flip side, toxic cultures in open-source projects put your employees and other contributors at risk. There could be both mental and physical health risks for your employees, and these toxic environments can negatively affect retention, since employees might be so eager to leave a project's toxic community that they look for another employer.
If the culture is too toxic, it will be difficult, if not impossible, to mitigate this risk. There is always a risk that things could go terribly wrong with the project as a whole if things get even worse within the community and contributors start disappearing.
Start by understanding your acceptable risk
Most business decisions boil down to an assessment of risk and making tradeoffs. To that end, you should be thinking about project risks in terms of how you're using these projects within your business. If you build products on top of open source, you want to eliminate as much risk as possible.
On the other hand, if you are using an open-source project as a small component within a minor piece of your infrastructure, you can accept more risk.
No project is all good or all bad, all risk or no risk, and no one solution will be right for every situation. Project risk, like most things, exists on a continuum. Deciding which risks you're going to accept is the beginning, not the end, of the process, since you should also be thinking about how you can monitor and mitigate those risks over time.
Think about the risks you might be taking and make informed business decisions about which are acceptable.
Want to learn more about open-source risks and how to manage them? Come to my talk at KubeCon + CloudNativeCon Europe 2021 Virtual, where I'll go into depth about project ownership, governance, community culture, and contributors. You'll learn how to assess and mitigate risk across these categories to make better business decisions about which open-source projects you support. The conference runs May 4-7, 2021.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
