Note: Here’s another from our friends at Black Duck! Peter Vescuso is the Executive Vice President of Marketing at Black Duck Software. He brings over 20 years of experience in marketing and executive management, developing new markets and building brands. Prior to joining Black Duck, Peter was VP/GM of the Enterprise Business and VP of Marketing at Cantata Technology. Peter was also Director of Marketing at Compaq Computer (before the acquisition by Hewlett-Packard), responsible for product marketing and market development in the Workstation Division. Before joining Compaq, he spent eight years in Hewlett-Packard’s Technical Systems Division.
Many software developers today get their projects completed faster by mashing together existing open source components – after all if there’s good code out there, why reinvent the wheel? An IDC survey from 2012 reported that 30% of the code in the Global 2000 was made up of open source. At Black Duck, we have a number of our best customers with pro-active open source policies that use 80% and more open source. One Black Duck customer captured the sentiment perfectly: “I only write what I can’t download.”
All well and good, makes sense, and in fact this trend has been going on for years. What about the rigor and discipline applied to keep track of components that are being used? Often the answer here is “not so much.” But as more and more open source components have been used, reinforced by the growing availability and abundance of open source—Black Duck tracks over 1 million open source projects—the need to manage and control has been growing exponentially. It’s one thing when you use a dozen or so components, quite another when you use hundreds. When you cross over into this territory, Dev managers start to worry. A good analogy….imagine building automobiles or smartphones, or a client facing app that serves hundreds of thousands of customers, and not knowing where the parts came from, or how you’d fix them if there were a problem? Typical Dev manager concerns include knowing a component’s provenance and quality, what unknown exposures exist from vulnerabilities or legal obligations, or the exposure that comes from relying on components that have unknowingly withered on the vine and are no longer active. Also if there’s never been controls or coordination on what components are used where, very often there are multiple versions – sometimes dozens – of the same components that make support and maintenance more complex, difficult, costly, etc.
Once the issues with unmanaged open source are in focus, the next questions are about bringing order to what can be chaos, i.e., how to easily manage, control and standardize on open source used throughout development without putting a drag on the development process. The good news is there are automation tools available to solve this problem. As an example, Black Duck offers automation software and consulting for open source management, governance and compliance while connecting development teams to critically important open source resources and communities. The software “bolts on” to existing dev tools—IDEs, SCMs, build systems—filling in the gaps needed to provide the visibility and controls Dev managers require for using open source at scale. It automates the search for and the selection of open source components at the front end of the process, supports an approval process (if desired) when components are used, can validate that what’s been chosen/approved is what’s actually being used, and monitors the deployed components to report on changes such as newly identified security vulnerabilities that need to be addressed. Dev managers can implement a catalog that contains approved components so developers can find and quickly reuse components, and it also helps support standardization of key components and versions. It’s one thing to use software to automate the open source management processes, but best practice would be for a company to develop an open source policy, then design processes to support it, and finally to automate with technology. An open source policy explains the guidelines around what and how open source is used, as well as forms the basis for employee education regarding the management of open source. And while many open source policies are based solely on the legal aspects of license compliance, the best policies are those that address the operational aspects including:
• Internal usage
• Release and redistribution
• License compliance
• Open source request, evaluation and approval
• Support and maintenance
• Community participation
Using open source software to build better software faster is increasingly the way development is done today whether it be a ‘waterfall’ process or Agile, for cloud or mobile. But using open source at scale, especially in organizations where developers are pulling down hundreds of components from the web, requires discipline and new processes. The good news is there’s technology to automate the process and best practices that can be adopted.