Developing open-source business policies that work

For the most part, companies seem to be making their open-source policies as they go along. There is a better way.

Share

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, sister publication of ComputerworldUK, 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 organisation 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 Licence) program.

Find your next job with computerworld UK jobs