With our launch of Insight, we've been talking to a lot of customers and prospective customers about effective management of open source-based development. At this point, we've heard it all. But some trends have emerged. One thing is clear -- virtually everyone wants to use more open source in their development processs, but realizes the need to effectively manage its use. With thousands of components in use across their organizations, many people struggle with where to start. With this in mind, we've put together a 'top 10 list'' to get things started. You’ll find a summary of the entire list here.
We’ll be exploring each item in more depth through a series of five blog posts. But for now, let's start at the beginning with understanding your current usage of open source components.
1. Understand where you are.
It’s impossible to improve without first understanding your existing situation. These are a few of the key things we recommend to ensure you know where you stand:
- Analyze your consumption to understand what and where components are being downloaded. By doing this you’ll know how open source components are used throughout your organization for development and which development groups are the heaviest users. Many IT organizations are surprised at the level of open-source penetration that has occurred "under the radar".
- Identify problematic components currently being used in development projects. If your organization doesn’t yet have an open source policy, or at least one that’s followed, then it’s likely at least one group is inadvertently using components with license or security issues. Completing this review will give you a good idea of how well (or poorly) your organization is doing.
- Classify existing projects based on business importance to establish the role of OSS within the enterprise’s existing software portfolio. You’ll typically want to introduce new processes to a few projects at a time before rolling them out to the whole enterprise. As any change can be disruptive, you may want to first try out your new procedures on less critical projects to avoid disruption. Once proven, you’ll want to quickly implement them on your most important projects to realize the benefits.
2. Analyze your key production applications for security vulnerabilities and licensing issues
You need to first understand where you stand before you can make informed decisions as to what changes, if any, need to be made. We recommend the following steps:
- Examine the complete bill of materials for your applications, not just first level dependencies. Java’s building block approach makes it fast and easy to build new applications using open source. But at the same time, this makes it difficult to identify all the dependencies as these may be nested several levels deep. Unfortunately, what you don’t know could indeed hurt you as illustrated in the figure.
- Analyze new and existing applications – it’s never too late to find and fix issues. Your existing applications, finished before you had a complete open source governance program in place, are likely to contain hidden risks. New vulnerabilities are being discovered all the time, so even if your development team carefully vetted every component before choosing them, it’s likely that new issues have been discovered since you put the application in production.
While its possible to manually implement these tips, you’ll really want automated tools, especially if you are part of a large organization. While you could cobble together your own tools, we recommend you check out Sonatype Insight, a set of tools and services we developed to help our customers address these very issues.
Once you implement these two tips you’ll have a really good idea of where you stand in terms of open source governance. In the next post we’ll provide tips on how to start up your governance program.
