It's a classic example, Grandchamp says, of IT neglecting to count open source code as a key asset and therefore failing to mitigate the risks that come with it.
"For some reason, it has escaped the traditional management channels. It escapes procurement almost completely because [it's free]. And it escapes a lot of technical evaluation because developers can just download it," he says.
Shaya Phillips, associate vice president for IT at Fordham University, says his IT department knows what can happen when open-source tools aren't managed properly, so it's trying to get ahead of that problem.
Best Practices for Managing Open-Source Software
CIOs looking to formulate and enforce open-source software management policies should first stop segregating open-source applications from commercial applications, says OpenLogic CEO Steven Grandchamp.
"Remove the 'open source,' because open-source software is just software," he says, adding that the best practices that IT uses when managing commercial software apply to open source code, too.
But Grandchamp and others say open-source management protocols benefit from other strategies too. He and others recommend the following:
• Start with a detailed policy. "You have to make some statements about what you're willing to do and not willing to do," Grandchamp says. "The big thing about the policy is understanding the risk tolerance of the company, because it really should be a risk-based policy."
• Understand the licensing terms of the various open-source tools that your organization is using or might consider using.
• Track open-source software once it's in the door. It's especially important to "make sure it's patched," says Gartner analyst Mark Driver.
• Conduct a sample scan or audit. As is the case with financial audits, it's impossible to conduct a comprehensive check of everything that's done using open source, but you can look at a sampling of uses and make sure they meet all the applicable guidelines, says Grandchamp.
• Use a compliance checklist. Sources such as Apache Software Foundation or the Linux Foundation have examples that you can follow.
• Check applications you distribute externally to see if they use open source code. As Penn State assistant professor Clark D. Asay points out, many open-source license requirements are triggered when code is distributed to users outside of your organization.
• Develop a system to identify open-source software that could be of value to your organization. This system should take into account your needs, the software's capabilities and license requirements and restrictions, Driver says. "Sometimes you have a good fit for code but not a good fit on the license," he says. "Not all open-source licenses are created equal."
• Devise a strategy for how your engineers will work with and engage the open-source community.
Sign up for MIS Asia eNewsletters.