Developing Open-Source Business Policies That Work: Everyone Is Making It Up As They Go Along

We know your company uses open-source applications. We also know many of you already have an open-source policy. Sort of. As CIO.com discovered when researching the adoption of open-source in enterprise IT, a quarter of respondents have a formal policy in place to control how such software is chosen, supported and deployed. Another 18 percent expected to adopt such a policy in the next 12 months. But those who have some kind of policy aren’t necessarily thrilled with it; just 45 percent said their policies are very effective.

“Somewhat effective” policies are like “somewhat effective” security; clearly, there’s more to be learned. CIO.com asked CIOs and other people in the trenches about what’s working—and what’s not working—with their open-source usage policies. We found that most people don’t really have a formalized policy. What they do have, though, are common concerns. Considered carefully, these issues should help you get a handle on how to better manage open-source software in your company. Once that’s out of the way, you’re in a better position to decide what you want in a formal policy that’s right for your own company.

While a company may not have a formal policy, for all practical purposes, many do have an open-source software acquisition and usage policy. For example, Amy Begg De Groff, IT director for Maryland’s Howard County Library system, says the library doesn’t have a policy on software selection at all for open-source or proprietary software. Instead, she writes, “We have an understanding that we will select the least expensive/most effective software to meet the needs we’ve identified. So, we focus a lot of energy on needs analysis. Then we seek open source solutions first, because we have had such super success with open source solutions (OpenOffice, Firefox, Apache, to name the few key ones.) Each time, we’ve found an open source product to meet our needs. Then, we’ve made sure it was an established product, with a large user/developer base and received good ‘press’ and reviews.”

Formal? No. But, there’s a clear policy here. De Groff’s policy springs from that rarest of things: a mission statement that clearly states the organization’s goals: “Howard County Library uses a wide range of open source computer software in order to: expand access to library collections and services; exceed customer expectations, and to contain hard costs for software licenses and computer hardware.”

Other small enterprises handle open-source deployment issues on an ad hoc basis. Dayna DeLaVergne, director of IT for the H. E. Butt Foundation, a Christian charitable foundation, says his organization generally deals with open-source deployment questions by a discussion of IT personnel, and sometimes the end user, to see if the open-source application is an appropriate solution. “We examine what needs to be accomplished and determine if the open-source solution can meet the need. In addition to considering whether it can produce the desired end result, we consider whether the user is already familiar with traditional software of this type, features, ease of use, user reviews and the likelihood of the need for support,” says DeLaVergne.

Other IT executives are slowly moving to a more formal open-source usage policy. Robert D. Hirsch, vice president and CIO of specialty tool vendor QEP freely admits, “We do not have a policy for open source today. However, it is inevitable that we will need one. Our younger developers have been brought up on open source and see it as a way to build and prototype applications quickly.”

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.”

Several other people CIO spoke with made the same point: Open-source software isn’t a special case, and overall software management is what’s really key to any enterprise. In particular, several mentioned Spiceworks, another open-source software inventory and management program, as being quite helpful in cutting costs and helping bring management order to software use.

For the most part, though, companies seem to be making their open-source policies as they go along.

Jay Lyman, an open-source analyst for The 451 Group, sees companies with open-source champions creating more formal open-source software policies: “Those organizations that don’t have champions—or perhaps their champions aren’t as far along, as experienced or as comfortable as other champions—would fall into the category of ‘make it up as you go.'”

Lyman continues, “We do see organizations attempting to apply traditional software and licensing policies and procedures to open source, but free and open-source software and its licensing are very unique and have more significant implications on things such as development model, business model, etc. So, open source really needs its own dedicated approach to get the most out of it. Here again, the champions tend to know how to go about it, and the organizations that have them are most likely to benefit.

This “make it up as you go along” approach to managing open-source software concerns Douglas “Dougie” Stevenson. Enterprise Monitoring SME (subject-matter expert) at Savvis, a SaaS (software-as-a-service) vendor. Stevenson points out, “You put controls on what goes into production based upon how IT is going to support the services, what the application provides and what it does in your environment. Open source still needs to have user training/orientation, you still need to field issues with it and you still need to adapt it to your business needs.”

So what does all this mean? Open-source management policies deal with the same issues over and over again, whether they’re written up in a formal statement or (as is far more likely) is the collected wisdom of IT executives and staffers. These include:

• Project stability: Can you trust the project to be there when you need it?

• Project support: Can you get support when you need it?

• Internal software management: Does your company know what open-source programs it’s using? How it’s developing and deploying them both in-house and to customers?

In general, companies do not appear to be handling these issues in a formal manner. Some of them, perhaps for the best, are incorporating open-source software management into general software management. As long as these companies avoid producing software for external use and avoid such traps as producing devices that include such programs, this approach should work.

In any case, CIOs should set up a framework to answer these common open-source concerns. That alone will take you a long way toward having an open-source policy that will work both for you and your company.