Another hallmark of open source is the support available in community forums, particularly for the more mature or widely used systems. But choosing to rely on community support instead of signing a service contract can be risky.
"People can Google for 90% of the problems they run into, but the last 10% may be killer if it's a mission-critical system," says Gartner's Driver.
It's important to understand the business impact of a catastrophic failure and have contingency plans in place to remediate the problems, he says. Reducing your risk might mean limiting your use of an application based on its maturity and the level of community support available, or choosing to pay for vendor or third-party support.
"If you have no service-level agreement, contract or warranty, you have shouldered the burden of responsibility," Driver says. "If you're able to do self-support, it's an upside, but if you can't, you have created unforeseen risk."
Of all the open-source software NPC uses, Brisbin opted to pay for support only for SpringSource tc Server, which it uses to deploy Web-based applications in an internal cloud. He went that route because the application server deployment is pushing the envelope of common developer knowledge. "We can't go out to a mailing list of 150 developers and ask questions, because not many people are doing this the way we are," Brisbin says. But he says he's happy that the contract didn't require him to purchase a license, and that it cost just a couple thousand dollars.
Applying governance
Organizations serious about using open source are also advised to establish policies and governance practices to monitor and control its use. Driver estimates that only 20% of organizations using open source have such policies in place, and in the Computerworld survey, most respondents said they didn't measure ROI. Taking such a risk can lead to unforeseen costs; for instance, even if you think you're reaping benefits, with no benchmarking or cost comparison, that could be an illusion, he says.
"People can be getting a negative ROI and firmly believe it's positive because they've gone from a [capital] expense to an [operating] expense," he says. In other words, the savings on license fees could be outdone by the salaries of employees who must spend eight to 10 hours a week updating, testing and patching the software.
In some cases, companies are realizing savings but can't prove it. "The key to minimizing the potential downside and maximizing the upside is governance," Driver says. "Without that, you're shooting in the dark."
At the New York State Office of Temporary and Disability Assistance, Chan is creating a direct comparison between the cost and performance of the new IT environment and the older one. He cautions that it requires an investment of resources to run tests and create meaningful benchmarks.
And even if you're only planning to use the software internally, it's important to ensure that the legal department understands the numerous types of licenses available, Driver says. "Restrictions vary, sometimes dramatically," he says. "You don't want to get a letter from your lawyer with an injunction because your open-source solution violated someone else's intellectual property."
Fitting open-source technology into your current infrastructure is another thorny issue. Three years ago, Roy Mentkow, director of technology for the city of Roanoke, Va., decided to transition from Microsoft Office to OpenOffice. However, for some users, desktop applications were heavily integrated with Lotus Notes workflows. "We had to ensure OpenOffice worked well with Notes on an application-by-application basis," Mentkow says. "That was something that snuck up on us."
In the end, the city migrated about half of its 900 users, resulting in $140,000 in savings. Still, Mentkow says, the savings won't come all at once but rather when those desktops would have been upgraded to a new version of Microsoft Office.
It's also important to look beyond another widely touted benefit of open-source software: the ready pool of developers who are familiar with the technology and see the prospect of using it as a retention or hiring plus. While it's true that developers are plentiful and eager to work with open source, that expertise can come at a price.
"If you asked a developer if they'd like to work with open-source or commercial software, eight times out of 10 they'll say open source," Lyman contends. And some developers may charge less than developers who work with commercial products.
Hamadeh says that with SugarCRM, it's even possible to "have a local student come in and program something in a couple of hours," Hamadeh says, or a tech-savvy business person can create custom modules. But, he cautions, while there are some SugarCRM consultants who will do a great job, they can be expensive, so having internal IT talent can help you avoid added costs.
Brisbin points out that the success of open source at NPC is due largely to the fact that its developers have a breadth of knowledge and are willing to work outside of narrowly defined silos.
"We have small development teams, and we cross areas of responsibility," he says, noting that he routinely moves among RPG, Java, Web front-end development, PostgreSQL and the underlying application system. "There is a critical mass of information you need to have as a developer to do open source effectively," Brisbin adds.
And then there's one of the more hard-to-quantify costs: cultural change. Mentkow says Roanoke's move to OpenOffice involved changing the culture as much as it did changing the desktops. "Cultural change does not happen in moments," he says. "As we move to different platforms and different standards, what we have to see is an acceptance of those changes."
Sims adds that it's easier to achieve cultural change at organizations that value resourcefulness and courage, since moving to open source represents a break from the approach that involves seeking traditional answers to difficult problems. "People still say you can't get fired for buying Microsoft or Oracle -- how about, you should get fired for not coming up with the best scenario that meets your company's unique criteria, regardless of conventional wisdom," he says.
As open source matures, companies will begin to get past the misconceptions, understand the implications and balance the benefits with the downsides. "Most of the time when there's a problem, it's because there's an assumption of 'It works, and when it doesn't, we'll fix it ourselves or find the answer on the Internet,' " Driver says. "Or there's an assumption that the cost of acquisition can be extrapolated to total cost of ownership. But there's a care and feeding cost to everything."
Brandel is a Computerworld contributing writer. Contact her at marybrandel@verizon.net.
