What is Component Quality Risk?
Just as someone would scrutinize the qualities of a restaurant or their kids’ new friends, organizations should be very discerning when selecting open source components. Quality risk is the likelihood that an open source component may create tech debt for its dependent projects. A preliminary examination of the component’s maturity, popularity, developer activity and practices, and dependency management can uncover symptoms of a problematic component.
The Takeaway
Look for this: A component that was created and is maintained by a group of engaged and responsive developers; has a clear and substantive set of contribution guidelines; and has an active community whose members contribute regularly to improve the source code.
Be leery of this: A component that has not been updated in a few years and that has only one or two maintainers who don’t really engage with users and who don’t necessarily invite involvement from others. A component with a single commit might solve a short-term problem but could be cause for serious concern in the long term.
Assessing Components’ Risk
When assessing a specific open source component, ask yourself these questions:
- How mature is the project? Component maturity is an indicator of quality. A project that has been under active development for a few years and has been cultivated with mature development practices, is likely to be more stable with a more committed group of contributors. On the other hand, a newer project could indicate that the component will change and grow in ways that cause you some technical debt later on.
- Does the component have an active issue tracker? If so, when was the last time an issue was submitted and addressed by the maintainers? The presence of an issue tracker is a good sign. However, if the list of unresolved problems is long, that might indicate the maintainers are not able to give the project their full attention. In turn, this could present a problem for users of the project.
- Are there contribution guidelines specified in the component’s Readme file? Detailed, substantive, and communicative guidelines reflect the maintainer’s attitude toward user contributions and communicate appreciation for the sense of community fostered in open source. As a consumer of the component, you play a direct role in ensuring the guidelines make sense, encourage community efforts, and focus on dependencies. In other words, help other contributors by being a good contributor.
- How many maintainers are involved? The more the merrier! When more than one person is working to maintain the component, chances are good that the extra eyes and attention will show in the component’s quality.
- Do you get a sense that this project is someone’s hobby or is it a project with a community or organization backing it? If there is a solo maintainer, there is no system of checks and balances to ensure the project continues to run smoothly and with integrity. The health and future of the component is in the hands of one person, and that one person has immense control. On the other hand, a community- or organization-backed project is just that – an endeavor cultivated by people with a shared interest in improving the project.
Is risk ever okay?
Risk is sometimes unavoidable, and an organization may have no choice but to use a higher-risk component. For instance, if the organization must prioritize speed over quality to meet product delivery deadlines, it would not be feasible to pursue a higher-quality, lower-risk option. That is a risk the company has decided it is willing to take after weighing the pros and cons. On the other hand, an organization may not want to set itself up for unexpected work later down the road and, as such, might opt to make time to thoughtfully review component contenders. It all boils down to judgment calls and what is best for an individual organization.
What can go wrong?
If your organization opts to use a lower-quality component, your developer team should be prepared for the possibility of routine maintenance, also known as “technical debt”. This is the cleanup work required to maintain a component. A poorly maintained component impacts more than just itself. Things can get particularly ugly if other components in an organization’s app — transitive dependencies — rely on that unmaintained component. And we haven’t even talked about rogue developers who use their open source projects as a means to protest or make a statement.
Unsupported or end-of-life components
Good things don’t last forever, and that is certainly the case with open source components. Whether the maintainer is permanently stepping away to pursue other interests or the backers have a difference of opinion on the project’s direction, one thing is certain: Ultimately no one will be at the helm to oversee and direct the health and viability of the component, causing it to enter an unsupported state or end of life (EOL).
This can pose significant problems for consumers of those components. Without a maintainer, the component will eventually become unusable, which will wreak havoc for users depending on its functionality. Without maintainers’ updates to the code and bug fixes, the component will become unusable, which could wreak havoc for users whose applications depend upon its functionality. Sometimes these situations are anticipated, such as when the maintainer makes a formal announcement in advance. But generally speaking, there is no way to anticipate these circumstances. Ideally, a maintainer will have created disengagement plans to help users transition more easily. If such consideration is not provided, however, users are left scrambling to find an alternative component to meet their needs.
Standardizing as a team
So often, people and organizations are conditioned to stand out from the crowd or to position themselves in a way that is unique from their competition. However, when it comes to an organization’s tech stacks, diverging from the industry’s commonly used tools and resources can come at a price. The more tools you use, the more risk you introduce to your team’s work, and the more vulnerable you are to exploited components.
Generally, minimizing risk is about weighing your organization’s priorities and needs against what you are willing to pay (and how much you can afford to pay) when a problem arises. And by “pay”, we’re talking about technical debt, employee time and availability to work on other projects, remediation efforts, etc. Choosing to standardize your tech stack to reflect the industry’s commonly used tools might be worth any lost innovation or creativity if it means easier and less costly remediation when a vulnerability is discovered. You can also standardize solutions by applying the same fix to numerous other problems instead of having to create a unique solution for a single problem. Standardization allows you to limit your tech footprint and make your organization a little safer as a result.
Project Hygiene
Sonatype researchers have learned that open source projects are not equal in terms of quality and project hygiene. This is often a combination of factors of good management, automated testing, and a responsiveness to reported issues. Starting with quality dependencies goes a long way to mitigate open source risk. This is why organizations are shifting the risk assessment of their open source hygiene to earlier in the development lifecycle. This involves starting with an open source governance policy that maintains the health of the application’s dependencies as the project matures. An automated review of an application’s dependencies start within the developer’s IDE so they understand the risks from the start.
The ultimate best practice
Open source was born and continues to exist because of its community of backers and contributors. Without this integral group, open source would not be what it has become. Supporting this community and contributing to its projects are absolutely essential to ensure its future. This is the absolute best “best practice” we can impart. Getting involved with and contributing to the open source you consume is, in essence, reinvesting back into those components while taking an active part in maintaining your organization’s critical infrastructure by ensuring that the components only contain good, clean code. Plus, chances are good that, if you could benefit from enhancing a component or helping to fix a bug, someone else probably could as well. In the end, not only do you get the precise functionality you need from that component, but you also are contributing to a project that you consume, which is simply good open source karma.