The topic of open-source software has been steeped in debate since the development and licensing took root in the 1980s and picked up steam with the proliferation of the Internet in the decade that followed. As open-source tools and components began to grow more familiar among developers, enterprises approached open-source cautiously, with an eye toward questions of suitability, scalability and support.
However, the emergence and rapid scale-out of open-source-powered startups highlighted the unique potential of these community-developed components. As Jim Zemlin, executive director of the Linux Foundation, puts it, “could Google or Amazon be what they are if they were built on Windows and .NET? They wouldn’t have been able to buy and track licenses as fast as they could roll out servers.”
A parade of successful open-source initiatives, coupled with year after year of tighter budgets, and OSS (open-source software) is entrenched in the enterprise. In a keynote he delivered at Linuxcon 2010 in Boston, Jeffrey Hammond of Forrester Research asserted that when it comes to enterprise IT adoption, open source has “crossed the chasm,” pointing to the entrenched position and expanding embrace of open source among enterprise developers and decision makers alike, as indicated in a series of surveys carried out in 2008 and 2009. (See Hammond’s keynote slides here.)
Today, questions around open-source adoption in enterprise IT continue, but rather than asking if or when, organizations are increasingly focusing on how. Using OSS as components of enterprise applications is in some ways a game changer, but in some ways it’s not. Organizations still need to follow software development best practices, but success with open-source software comes with its own wrinkles, such as finding the right components, interacting positively with the community and understanding and navigating open-source licenses.
Finding the Right Projects
While the free availability of open-source components can work to catch the attention of developers and organizations, the value of any component, whether open source or not, boils down to much more than acquisition cost. Jim Zemlin of the Linux Foundation said the “-hey-this-is-great-because-it’s-free’ story is 10 years old. We’ve moved on to more sophisticated questions. Companies now want to know which projects are good, where can they get them, how are they best implemented, where can they find the best developer talent to work with OSS, and how can they contribute and improve it.”
The process of finding the right OSS project typically begins with a developer searching online for a code component that will meet a specific need. The process of searching for code, compiling a list of projects, evaluating the projects and their associated communities, and downloading and testing the code can be an arduous task because code (and different versions of it) can be scattered across the globe.
One resource that can make this process easier is the Website Ohloh.net, which houses a comprehensive database of 300,000 OSS projects. Each project has complete information regarding licensing, cryptography, security and the vitality of the community. Measuring the vitality is important because it won’t help your developers very much if they have to start maintaining someone else’s dead code. Insight into the sustainability of the project can be found in factors such as the number of committers, the names and histories of each committer, the number of contributors and their experience, plus the growth in the number of community members and the frequency of builds.
The site, which was recently acquired by Black Duck Software, is set to merge with Black Duck’s existing Koders.com site to provide all the information a developer needs to make an informed decision about open-source components. In the words of Black Duck President and CEO Tim Yeaton, the combined site will have the “richest metadata aggregated in one place that developers can use to understand each project.”
Understanding the community clustered around a particular project is key, because it’s from this group of users and contributors that open-source projects draw their strength. As a consultant, I’ve always asked my clients if they want to put all their eggs in one basket and be at the mercy of a single vendor for operating system, application and custom application licensing, support and updates. While a broad-based community can’t replace the professional support organizations maintained by enterprise-oriented software vendors, community resources can provide a powerful complement. What’s more, the most popular open-source projects-the components of the LAMP stack, for instance-tend to boast multiple commercial providers alongside considerable community resources.
Joining the Community
As use of particular open-source software components within an enterprise deepens, there’s a point where increasing project participation beyond bug reporting and forum interaction may become beneficial. For instance, the costs of supporting code extensions that don’t deliver a competitive advantage to one’s organization can be minimized if shared among other users of the project.
However, there are many issues around extending participation in this way- from collaborating effectively with a project’s developers to issues around copyright assignment and other intellectual property concerns, it’s hard enough to manage internal development projects, let alone manage a diverse crowd of individual developers who your organization really can’t hold accountable.
Last year, Microsoft helped found the Outercurve Foundation (formerly the Codeplex Foundation) to help organizations navigate the ins and outs of working with a community. The company-agnostic organization helps assign and track intellectual property of bits of code and connect members of the community through processes that facilitate the exchange of code. Outercurve.org currently hosts seven OSS projects by monitoring and managing contributions. According to Paula Hunter, Outercurve’s executive director, “this way enterprises know the code they download is free and properly licensed. They also know that they can contribute safely while shielding their own IP.”
Assigning a project to Outercurve distances the project from its creators while ensuring that it will remain free. Most projects are started to solve a problem, and most problems are likely to affect more than the project’s founder. For example, the CoApp project started as just an idea to bring package management to Windows platforms. The project launched, and within weeks dozens of developers were helping with planning. Now hundreds are actively contributing code or requirements.
Along similar lines but more directly focused on issues around license compliance, the Linux Foundation recently launched the Open Compliance Program help companies understand license governance and software inventory management of OSS. The initiative includes tools, training and guidelines for tracking OSS licenses such as a self-assessment checklist. Another component of the project is FOSSBazaar.org, a community for software and compliance professionals.
Most enterprises consume OSS through distributors’ professional support organizations such as Red Hat and Novell (which track license compliance for them) and don’t redistribute code as part of a product. “Life isn’t that complicated because the goal is that consumption of OSS should be hassle-free,” said Jim Zemlin of the Linux Foundation .
However, those companies intending to redistribute open-source components within embedded systems, mobile devices and network devices must manage their software supply chain tightly. As custom-built platforms become complex fabrics of OSS, knowing from where each component came from and if it can be used legally becomes more of a challenge.
We’ve reached the point where businesses supply the community and the community supplies businesses. It’s critical to understand where each component came from, what’s in it, whether it adheres to corporate development best practices, if it is secure, and whether it does what it says it does. According to Tim Yeaton of Black Duck, “a mobile handset manufacturer may add up to 100 new components to the base Linux kernel. With development scattered all over the world it is important to automate license governance as part of the code management process.”