5 common mistakes in using open-source software

Few technology initiatives have generated as much interest among chief information officers as the open-source software movement. The open-source model offers attractive license-free infrastructure technology; large, multiuser applications; and desktop applications. Built by development communities, applications evolve and improve as community members offer their revisions to their peers, who reject or accept the changes into the applications' code.

But as open source becomes more mainstream, users discover that the model isn't immune from many of the deployment pitfalls that plague commercial software, including integration hassles and support and maintenance costs.

The following list delineates those pitfalls. The core list was created by Drew Ladner, general manager of the government group at JBoss, a company that distributes license-free open-source middleware, including application server and Web portal technology. The company also provides consulting and support services. Before joining the company, Ladner served as the Treasury Department's CIO. He was president of Zuri Technology, a consulting firm, before taking his current position last June.

Other open-source users and consultants responded to Ladner's list of common mistakes.

Failure to account for full life cycle costs

People forget to consider the full life cycle costs of software, including open source. "The pitfall is that people say, 'We can save money because we're not paying licensing fees,'" Ladner said. "But the reality is you have to look at the whole life cycle, which is the smart thing to do from a business standpoint."

Post-acquisition life cycle costs include financial hits taken during the development, deployment and management phases of software implementations.

"Open source is not free," said John McManus, deputy CIO and chief technology officer at NASA. "You may not have to pay for the code, but it doesn't free you from having to exercise your brain and do whatever integration is required. If you don't think about maintenance, operation and integration costs, you may put zero dollars in your budget for an open-source project and then wonder why you're eating through money so quickly."

Lack of full planning for projects

Consider long-term operations and maintenance when planning open-source projects. "Open-source users may not think through [operations and maintenance] to make sure they have the right support services," Ladner said. "We're talking about enterprise-class software implementations. Any good CIO will want to make sure the software they're using is well supported, whether it's open-source or commercial code."

Users should have someone to call if a problem arises, especially for mission-critical and warfighting applications, Ladner added.

One of the biggest mistakes open-source users make is to think that because the internal staff has access to source code, in-house IT people can handle all support tasks, including revisions, patch management and bug fixes. But those tasks take time away from normal IT duties. "If you expect your developers to provide support, that's a huge hidden expense," Ladner said. "Leave development to developers and ensure that professional providers are the ones you depend on to support critical applications."

McManus said some maintenance agreements may be beneficial. But he cautioned that some service providers may have different motives for offering support contracts, some of which don't necessarily mesh with the needs of public-sector agencies.

"I respect the fact that some companies are seeing an opportunity to help those without domain expertise, while also opening up a revenue stream for themselves," McManus said. "But other companies are just looking for additional revenue streams, and that's unproductive. If you want to commercialize your software, you should make a clean break. Sometimes, it's difficult to separate the companies with the best intentions from those that are profit-driven and those whose intentions fall somewhere in the middle."

Treating open-source software just like any other software

If IT managers don't document and communicate savings and other benefits of open-source projects, senior managers may be reluctant to see the technology as a viable alternative in the future. IT managers should share their experiences "so agencies can improve on the IT strategies and policies that are in the process of being formulated," Ladner said. Poor communication leads to misconceptions and wrong assumptions about open source, he added.

Information sharing should extend beyond internal communication, McManus said. "The biggest pitfall is when people don't understand how to engage the [open-source] community properly, they don't get the full value of what open source brings," he said.

"If your whole mentality is, 'I've downloaded the software. I'm done'" with the network of people who develop and support the code, he added, "you miss out on an opportunity to become part of that community."

Opportunities for collaborative engineering and sharing best practices are the biggest benefits of remaining connected to the open-source community. In some cases, agencies may waste time developing custom code and enhancements that are already available within the product's community.

By not participating with the larger community through contributing new code or offering bug reports, users violate the philosophical foundation of the open-source movement, McManus said. "Even just saying, 'This piece of code didn't work for me,' can be helpful to others," he added.

"Sharing your experiences is what really makes open source such a valuable model," McManus said. "As long as people participate, [the products] grow and evolve. It's critical, especially when pursuing [service-oriented architecture] software development, to be responsible individuals. You can't take and not give something back. There's no free ride with open source."

Selecting inexperienced partners

Selecting the right partners for an open-source project is important. "Open source is a large ecosystem, with large and small systems integrators who are delivering software and services in a new way," Ladner said. "Some agencies may have relationships with certain preferred partners, and that's terrific. Just make sure the partners have the right level of open-source experience."

The downside to inexperience may be poor technology choices and implementation delays. Ladner advised agencies to research each integrator's open-source training and certification records. Agencies should ask for references for past open-source implementations. If a trusted integrator is lacking, "it makes sense to augment that current partner with one that has more open-source expertise," Ladner said.

Thinking too small

Although some agencies are including open source with commercial products as part of their project evaluation mix, some see open source as a niche technology or one best-suited to small agencies, Ladner said. "The reality is that in the private sector, companies are formally embedding enterprise-class open source into their IT architectures and strategies," he added.

A mistaken belief that open source requires special expertise can cause agencies to be reluctant to take on ambitious open-source projects, Ladner said.

"Some people tell us, 'Open source sounds great, but we don't have the talent,'" Ladner said. "This is an interesting attitude because [open-source technologies] are products just like the proprietary alternatives. The only difference is that people get it for free then pay if they want to call someone for help. It doesn't take smarter developers; it takes the same skill set as propriety" software.

Others say that is only true to a degree. In-house expertise may be necessary to fully benefit from communitywide technical support available for open-source products, said Richard Monson-Haefel, a senior analyst at the Burton Group, a research firm based in Midvale, Utah.

"Using the normal support channels for open source works if you're able to ask the right question," he said. "However, the bedside manner in mailing lists is not always the same as with commercial support services," especially if someone asks what more experienced users consider to be a stupid question, he added.

Joch is a business and technology writer based in New England. He can be reached at ajoch@monad.net.