Accidental Open-Source Developers

This touches on a side issue. Your company may not be in the software business, but that doesn't mean that your in-house developers aren't modifying open-source programs for your own internal use. That's not a problem by the rules of even the strictest open-source license. But if you ship a product that contains modified open-source code, you'll need to obey the license's rules or face possible legal consequences. Verizon, for example, ran afoul of this when it shipped wireless routers for its Fios (fiber-optic service) Internet that contained a GPL (General Public License) program.

Some corporate executives, such as David Allen, CTO at Sparta Consulting, an SAP consultantry, are already painfully aware of the potential trouble with using and developing open-source software. "I am a big fan of open source, use it every day, but I'm concerned that too many CIOs do not have an adequate grasp on their responsibilities with the various licenses that we generically describe as open source. As a new CTO, I have taken the responsibility of creating our IP development standards/policies. Beware of trying to walk the line between 'use' and 'development.' The line between configuration and extension or development is fuzzy at best."

To avoid this kind of misstep, and to make sure that authorized in-house programs are green-lighted before going into production, Hirsch says his company plans to have its policy "state that open source can be used for experimentation, prototyping and investigative application development without permission. However, any production designed applications or utilities will require an approval by the CTO/CIO and the business owner before open source can be used in a production environment."

So long as you use any customized open-source software in-house, Gordon Haff, principal IT advisor for the Illuminata Group, doesn't see too much for companies to worry about. "Anecdotally, when I'm in an end user audience, I don't see much interest in or knowledge of open source software licensing nuances and issues. And, truth be told, for a lot of end users, it doesn't matter much. If you're strictly an end user developing software for your own internal use, you can use pretty much any open source software you like without knowing or caring about the differences between GPLv2 and BSD."

Managing Software

Making proper use of open-source software is the central concern for most companies and organizations. Alan Young, CIO of the Southern Ute Indian Tribe, is focused on coming up with a viable open-source deployment policy. "Given the budget pressures that IT faces and the business objectives, sometimes it makes good sense to think about open-source applications, but the road is fraught with scary consequences."

Among the concerns that Young plans to address are:

1. What is the formal organization behind the open-source entity? Are they organized? Are they a one-man show? "I prefer the more organized [approach] where 'donations' can be made for support of source," says Young.

2. What is the release schedule for source code?

1. Does the open-source project have a life that makes sense? Like more than one month or one year? "I would prefer three to five years at least," says Young, "since some of the development is a balance-sheet item."

2. Is there a maintenance/support plan for the open-source project? Points out Young, "Once you deploy open source into your enterprise you have to keep up with operating system, hardware configuration changes, database changes and the like."

After all, as Young observes, for all open-source benefits, "If the project dies, guess who's left holding the bag? Me!" That's a position no CIO ever wants to be in.

On a larger scale, Roger Valade, vice president of technology for Entertainment, the company behind the Entertainment Book marketing program, says the company has effectively adopted a number of open-source components, "providing both significant cost savings and environmental standardization." Entertainment's open-source philosophy is purely practical: "Our policy right now is 'use it whenever you can—it is a productivity improvement. Don't code what you can download.' Sometimes we have battles (Hibernate vs. iBatis) [Both are services to make it easier for programmers to connect objects with database queries] and that is when it gets interesting."

In the future, Entertainment plans on refining its open-source strategy by developing a policy that considers such things as existing skill set, availability of training, availability and cost of outside resources, strength of the user community and appropriate cost model. Says Valade, "To a large degree this is a subset of the portfolio management initiative with a specific focus on open source given both its popularity, subtlety and long-term impact."

John Rafuse, executive VP at HeavyLifters Network, a Canadian-based business and IT consulting firm, would agree with Valade. Rafuse sees open-source software management as being "exactly the same as controlling any software asset." To track HeavyLifter's software use, Rafuse uses the open-source program The Verified Software Repository. Closed or open, Rafuse believes that companies can save huge amounts of time and money by using a shared repository. If they don't, he says, "I saw in one instance that they had built no less than 12 case management systems instead of having a central code base and manipulating it for their needs."