Gartner estimates that by 2013, 90 percent of Global 2000 enterprises will include open source software (OSS) as business critical elements of their IT portfolios — and by 2016, that number will increase to 99 percent. It makes sense that open source use is on the rise. Java developers already know that open source offers unmatched flexibility, the power to control and easily modify code and optimize performance. The bottom line: Using open source components for software development improves an organization’s ability to deliver higher quality software faster at lower cost.

However, most Java developers have limited ability to govern the selection, management and distribution of open source components, which can expose their organizations to unforeseen technical and compliance risks, including potentially significant threats to software quality, stability, performance, security and intellectual property. To manage the use and risks of open source throughout the application development lifecycle, organizations must implement corporate standards for open source-based development.

Keeping the following 10 tips and considerations top-of-mind will help your organization maximize the business value of open-source components and minimize the risk of open source as you design, develop, build, test and move applications into production.

1. Establish an Open Source Governance Program

A governance program is necessary to filter, audit, track and manage open-source assets in the enterprise. Without one, you cannot account for the open-source assets that come into or leave the enterprise. Be sure to include guidance on quality, security and licensing — the three major risk areas to consider when using open source software components.

2. Establish Mechanisms to Monitor the Effectiveness of the Governance Program

To effectively monitor how well your governance program works:

• Monitor open source consumption from outside sources, such as the Central Repository.
• Find where potential problems exist by identifying groups that may not be adhering to the OSS policies.
• Audit your applications to ensure the included components meet your guidelines.
• Analyze all software delivered by subcontractors or software suppliers to ensure they are meeting your requirements.

3. Engage with the OSS Community

You can do this with various levels of involvement, from doing nothing to taking on responsibility for an open-source project. Here is a 0?5 scale for involvement level:

• 0: Do nothing
• 1: Submit feature requests and defect reports
• 2: Submit defect resolutions
• 3: Submit new features and other significant derived works
• 4: Actively take on an open source solution as its primary maintainer
• 5: Take on an open source project as its leader

4. Build Open Source Management into Your Software Development Process

You should not disrupt development or else projects will be delayed and costs will increase. Provide developers the tools they need to standardize on a set of thoughtfully chosen components free of license or security defects. To ensure projects do not include flawed components, use automated analysis during the build process.

5. Evaluate Open Source Components Before Using Them in Development

Determine if the project is mature enough for your use, and whether it meets your requirements for quality, security and licensing. An acceptable level of maturity is largely “in the eye of the beholder,” but some basic metrics are universal:

• How large is the community?
• Are there commercial channels of service and support?
• How often is the project updated?
• Is the project run by an established nonprofit group or stable vendor?

6. Standardize on a Common Set of Open Source Components

Lower maintenance costs by reducing the number of components that need to be supported. Limit the number of components that need to be evaluated as well.

7. Analyze and Continuously Monitor All Applications

To indentify security vulnerabilities and licensing issues, examine the complete bill of materials for your applications, not just first-level dependencies. Flawed components may be hidden deep within your applications. When vulnerabilities are discovered, quickly analyze and repair them.

Analyze existing applications too, not just new ones — it’s never too late to find and fix issues. For mission-critical applications, you might consider using heavyweight scanners that examine the complete source code.

8. Establish Well-Defined Channels of Acquisition for Each Open Source Component

You must have a trusted source for each component, such as the Central Repository.

9. Establish a Policy of Service and Support

Determine the level of support required and identify the resources required. For some projects, community-based support will be fine. Others will demand commercial service and support contracts with binding SLAs.

10. Benchmark Your Current Usage of Open Source Components

Benchmarking will help you understand where you are starting from and set realistic goals:

• Evaluate compliance to existing open source policies.
• Identify which groups are using open source components, including what they are downloading from outside sources.
• Identify problematic components being used in applications that are in development or in production.
• Classify existing projects based on business importance to identify potential risks and provide a mechanism to establish the role and value of OSS within your organization’s existing software portfolio.