Project activity is the last element of operational open source risk. I recently heard a technical due diligence consultant call the problem “stranded code.” What did he mean by “stranded code”? Use of a component that no one is improving or even maintaining anymore. The beauty of an active, vibrant project is that lots of people are working on it, often finding and fixing issues before you even know you have them. And the open source culture is one where these folks will pitch in if you have an issue. About 2,000 developers work together on the Linux kernel in any given year! By contrast, some components began as pet projects and were abandoned at some point. Developers relying on those components are on their own to find and fix any issues, which can be difficult for developers who haven’t been involved with developing the code.
Consider your community
To get the biggest bang out of open source, you should maintain current and consistent versions and ensure that your developers look to use components supported by an active community. But cultivating this environment requires some sophistication. Most companies aren’t so sophisticated in their use of open source, which creates operational risk. If you’re buying a company, you need to work remediation of operational open source risk into your calculus.