When Linus Torvalds created Linux, many industry observers saw an answer in search of a question. According to the Linux Foundation Web site, even tech pundits were largely unaware of Linux's potential, dismissing it as a computer hobbyist project, unsuitable for the general public's computing needs.

How wrong they were.

Fast forward nearly 20 years. Linux helped spawn a revolution in development, and the open source movement has created more than 220,000 open source projects. These projects now power a faster, more agile process - sometimes called multisource development - where increasing amounts of open source code are integrated with internal and other code.

The first big wave of open source software users turned out to be product developers who fell in love with open source for its significant financial and time-saving capabilities. With a focus on product ship dates, the velocity of development and time to market, ready-to-use code that reduced the development effort made a lot of sense. After all, why reinvent the wheel? Plus, if open source code already existed and was freely available to anyone on the Internet, it wouldn't be much of a differentiator in any one company's product. Given that, does it make sense to reinvent the same code segments - such as a parser or a compiler - over and over again?

The mobile industry has been one of the most aggressive in terms of adopting open source. The spate of new mobile handsets running on open source is striking - just look at all the advertisements for the Droid based on Google's Android open source platform. Even proprietary mobile devices like the Apple iPhone rely on dozens of open source components, most visibly the Safari browser.

Outside of product development organizations, enterprise IT organizations have been slower to adopt open source. Slower, that is, until the recession hit and a new pragmatism around leverage emerged. There's nothing like a crisis to motivate change. Access to open source code from a massive abundance of projects, combined with the compelling economics and flexibility enabled by the modular nature of open source, have caused IT organizations to take notice.

This is not surprising. It's also backed up by research from The 451 Group in which 87 percent of companies say open source meets or exceeds cost savings expectations. Perhaps more importantly, the survey uncovered that after adopting open source, 39 percent of users rank flexibility as the primary benefit and cost as the secondary benefit. That is the good news.

The not-as-good news is that enterprises in many cases have an ad hoc approach in the way they are using open source, with developers pulling in code from a plethora of external sources with little or no control. In one of these cases, we've seen an organization using more than a dozen very similar XML parsers.

Due to a lack of standardization and what seems to be an inevitable proliferation of versions or nearly redundant components, development and support costs are actually on the rise at some enterprises - precisely the opposite effect an organization would expect when embracing open source software. Consider a simple example: If an organization uses only two components in five different applications, and if each application has two versions, that translates into 20 components to track. It's more common that dozens (or hundreds) of components are used, and in large IT shops with a hundred applications or more, the complexity and scale of the problem quickly grows out of control, easily surpassing what can be managed with manual or ad hoc approaches.

Unfortunately, problems associated with a lack of standardization lead to more than version proliferation. There are deeper issues as well, the kind that might keep IT people from sleeping at night.

One issue is that managing operational risk is increased. If uncontrolled open source components are used and deployed in the IT infrastructure, and there's a problem or an outage, can that component be tracked down, patched and repaired? Also, with Sarbanes-Oxley there's a need to provide oversight and control of software acquired by an organization - and that includes open source. Failing to establish procedures to ensure compliance with open source software licenses may indicate a lack of procedure necessary to verify ownership and use of intellectual property.

When you consider the fact that distributed development is more the norm today than not, especially in large companies with multiple divisions spread to the four corners of the earth, standardization efforts are even more difficult.

And before you can implement processes, you need to have policies and objectives in place to guide the effort. The 451 Group survey discovered that 58 percent of companies do not have formal policies or guidelines for open source. While that number indicates that some companies are being proactive about open source, the fact that more than half the respondents have no policy illustrates how much room there is for improvement.

To bring standardization to enterprise development for open source, the best course of action is for development organizations to define a strategy and policy around how they will leverage and manage open source. Being proactive up front can bring some order to an out-of-control process and reduce maintenance and support costs down the road.

All code development has test and maintenance costs; when open source is introduced into the mix, it's even more important to know where your code comes from. Most development managers know that the cost of fixing defects is 100 to 1,000 times greater when issues are detected and fixed late in the lifecycle. By investing time and implementing the right processes up front, the end result can be more agile and efficient development, yielding higher quality applications with less code to maintain.

Enterprise developers and their companies are squeezed for time and resources and face tremendous competitive pressure. Any development process that can offer efficiencies - like adding open source to the development mix - can help a development team accelerate the creation of code from the beginning of a project through to shipping a product. Open source code, successfully managed and with some degree of standardization and automated management, can help cut costs while protecting the organization's investment and managing the very real risks and issues associated with the use of open source software.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access