How to develop open-source software within any kind of company

For businesses and other organizations today, open-source software (OSS) is transformative in terms of its ability to allow organizations to write software very quickly and to leverage innovation very aggressively.

OSS component-based development has reached a strategic tipping point, having moved from a cost-effective solution to a competitive advantage capable of delivering rapid and substantial return on investment for organizations that use it.

And use it they do. More than 80 percent of modern software includes open sourcecomponents.

Typical organizations, including Global 2000 enterprises, use thousands of OSS components, often in mission-critical software portfolios. Startups can quickly bring applications to market by focusing creative development on their core competency and relying on OSS for everything else. My company’s Central Repository, containing nearly 90 percent of open source Java projects, serves more than four billion requests per year to more than 61,000 organizations per year, including more than half of the Global 2000.

A vibrant ecosystem with a fundamental flaw

The same core advantage of OSS –its free availability, rapid innovation, and highly interdependent projects — introduces risks that can sabotage the IT or business value of key applications.

The issue really boils down to two interrelated concerns:

Complex dependencies: The open source ecosystem is comprised of hundreds of thousands of components, each of which may depend on tens or hundreds of other components. The whole ecosystem is interdependent. As a result, the properties (good or bad) of any one component are inherited across many others.

A simple, but potent example might help. Version 2.5.6 of the Spring-beans contained a severe, remotely exploitable security flaw. Spring-beans is a commonly used component, and 1,447 others depend on it. So the security vulnerability was inherited by all 1,447 other components, and untold thousands of applications that rely Spring-beans directly or indirectly.

Intellectual property issues add another dimension. Every component and dependency added to an application has specific and enforceable licensing and copyright requirements. This is true even if those dependencies are added unwittingly. This is troubling for software and embedded systems vendors who might inadvertently include a copyleft license such as the GPL in their shipping products.

This exact issue has resulted in numerous and expensive lawsuits including the well-publicized instance of Cisco’s unknowing inclusion of GPL code in their Linksys routers. In this case, the Free Software Foundation sued Cisco and forced the company, among other things, to make their source code publicly available.

Lack of update notification infrastructure: Components are updated frequently; the average component in Central is updated four times year. And yet, with all this change, there is no automated mechanism for update notification.

Take the Spring-beans example. Once the security vulnerability was fixed, there was no automated mechanism for the projects that depend on the old version to be updated to the new, fixed version. Taking it one step further, absent automated update notification, none of the direct or indirect users of the flawed Spring-beans components would have any idea that their applications were at risk.

In this wild West sort of lawlessness, many organizations are clearly taking chances and hoping for the best. A 2012 survey we conducted among 2,550 developers, architects, and managers found that only 20 percent of organizations have put effective open source management policies in place.

Order out of chaos: A strategy for optimization

Strategizing to yield the greatest ROI in using OSS demands a high-level awareness of how, why, and where OSS is used, along with consistent knowledge of OSS benefits, risks, and policies.

To this end, several vendors offer software composition analysis tools that apply data mining technology for use in inspecting OSS components for security and functionality issues, known fixes, IP ownership, and versioning. The best of these tools enable organizations to govern development processes, continuously monitor the health of their repositories, and retrieve real-time alerts when critical applications are affected by newly discovered threats.

To maximize the business value of OSS while minimizing risks:

• Assess your current usage of OSS components to grasp where you’re starting from, as an aid to setting realistic goals.
• Establish an open source governance program to filter, audit, track and manage open-source assets in the organization, and deploy mechanisms to monitor the effectiveness of your governance program.
• Build open source management into your entire software development process, evaluating OSS components before and while using them in development .
• Analyze and continuously monitor all deployed applications for newly discovered security vulnerabilities and stability issues.
• Establish well-defined channels of acquisition (such as the Central Repository) for each OSS component you leverage.
• Engage with the OSS community and establish routes to service and support for key components and frameworks.

Properly managing the use of OSS in development will let you focus not merely on the cost savings it can bring you, but also on the wealth of innovation ongoing in the open source domain. It will help make OSS a catalyst for change in your organization.

Wayne Jackson is CEO of Sonatype, a company that is transforming software development with tools, information, and services that enable organizations to build better software faster using open-source components. Contact him at wjackson@sonatype.com.

Image courtesy of olly, Shutterstock