It’s no secret that open source software is now used by the majority of enterprises around the world, but it wasn’t always that way. In fact, it wasn’t until early corporate users began to realize the substantial cost savings and numerous other benefits of open source that its popularity grew to the point where it now constitutes some 30 percent of the code in Global 2000 organizations, according to IDC.
Financial services firms were among the earliest users of open source, so it seems fair to say they’re further along on the learning curve than most when it comes to enterprise use and management of the software. With that in mind, Linux.com recently spoke with Black Duck Software CEO Tim Yeaton – who recently wrote an article on the subject – and Jamie Hill, director of the OpenMAMA initiative at NYSE Technologies, in the hopes of singling out some best practices.
‘A Different Mind-set’
“The financial services industry has long been leading the charge regarding open source use,” Yeaton told Linux.com. “Ten years ago, the industry was focused on Linux; today, financial services organizations remain voracious open source users at the fore of understanding how to leverage it in development and operations, and recently relying on it for mobile apps, cloud computing and Big Data.”
Indeed, there’s been a change in mind-set among financial services firms over the years, Hill suggested. Traditionally it wasn’t uncommon for such companies to be wary of open source, especially projects that had no commercial support model.
“Big firms rely on having someone to call and scream and shout at when something goes wrong,” Hill explained. “It is what they’re used to.”
The challenge has been for such companies to “get in a different mind-set, where rather than scream at the vendor, the solution is to contribute to the project and become a stakeholder,” he added.
‘Years of Lax Controls’
Most senior development managers now understand the benefits of open source, Yeaton said. The issue today is that “they must now confront the challenges created by years of lax controls over what developers have been downloading and integrating into their software,” he said.
The choices developers have made regarding “what’s in their code base, what’s being used and where, and how to support it,” for example, all have implications for quality and operations, as well as the ability to speed development and lower costs, he pointed out.
Now that those effects have become clear, best practices have emerged in the industry in four overall categories, Yeaton suggested: tracking and control, maintenance and support, audits and community strategies.
Best Practices for the Enterprise
1. Tracking and Control
“While it may seem of obvious importance, tracking and controlling where and how open source is used in enterprises should be a priority, although it is often not done well,” Yeaton said.
That means more than simply being aware that a particular open source project is being used; rather, “it’s critical to know the specific components and versions, like when a security vulnerability is discovered it is reported with respect to a particular version of a project (e.g. the recent flaws discovered in Java7 update 11, specifically JRE version 1.7.0_11-b21),” he explained.
Control is also critical so that the organization is aware not just which version is affected, but also where it’s used so it can be found and remediated.
With tracking and controls in place, “it’s a relatively small additional effort to leverage that work and provide catalogs of ‘approved’ components that are ready for reuse,” Yeaton said. “A bank may spend a lot of effort to do security research, for example, to protect bank systems and networks. This can be a substantial investment, so encouraging developers to reuse common, approved components can deliver significant savings in time and effort.”
2. Maintenance and Support
Enterprises must also ensure that they can maintain and support their code effectively to ensure reliability and security, Yeaton pointed out.
“Unfortunately, there is no one-size-fits-all approach to maintenance with open source projects,” he added. “Some organizations have a preference for buying support from a single commercial vendor like Red Hat, others utilize open source support aggregators such as credativ for multiple projects, and some rely on self-support models. Each has their own benefits and drawbacks, and the best choice often varies from project to project.
“The key is to ensure that whatever approach you’re using – and it may be a combination – is appropriate for the types of components, level of OSS use and how it fits with your internal resources and capabilities,” Yeaton noted. “It comes down to ensuring you are actively managing these processes, and not leaving them up to chance.”
3. Audits
Reliable license audits are imperative, Yeaton said, “particularly when working with customer-facing implementations and anything that might be considered distributed.”
Without a formalized development process including controls on the acquisition and integration of open source components, “chances are an organization won’t be aware of what’s being used and the license obligations associated with the code,” he explained. “Even when software is not distributed, tracking and auditing are still essential to proactively managing vulnerabilities and bugs, which can have far-reaching consequences at all levels of an organization.”
4. Community Strategies
Finally, the piece that’s commonly still absent in many financial services firms is an explicit strategy for dealing with the community, Yeaton said. “We see this often – they have the three more technical best practices in place to foster OSS use, but haven’t yet developed the processes, culture and mechanisms needed to work directly with the community to obtain support, make contributions and influence project directions.”
For example, even though community support is typically free, “organizations need an internal champion to pursue it, and take responsibility for it just like any other type of support,” he pointed out. “A best practice we recommend is to empower a technology owner – to consolidate this work to one person or team, instead of duplicating it within each group. Use community-style techniques to empower that person to provide support and manage contributions for departments throughout the organization.”
It’s also important to have a clear policy and process for encouraging and governing open source community participation, Yeaton added. “Active participation will help developer groups move faster than by working alone, and often faster even than working with enterprise software vendors. But in order to take advantage of this, enterprises must specify and manage how their developers can and should participate.”
Traditionally, a lot of the banks and financial services firms have clauses in their employment contracts that prevent giving away any kind of IP during work hours, Hill pointed out. These legacy clauses can prohibit a firm from participating in an open-source project, he said.
Today, however, “that’s getting broken down,” he added.
“We’re not really a group that shares ideas, typically,” Hill concluded. “But places where we can come together and collaborate on something we all use lets us pool our resources without competing. With so many different people involved, it makes for a better result.”
