When it comes to open-source technology, there are three camps. Some companies are fully dedicated to open-source software. Others wouldn’t dare stray from the commercial applications they know and trust. Still others are interested in integrating open source at some level — so long as it doesn’t require overhauling the entire network.
IT managers in the first two camps are accustomed to the “all-or-nothing strategy” that their CTOs live and die by. But what about the hybrid camp? How do companies integrate open-source software without turning their network upside down? Moreover, how do they determine which components can and should be converted? And perhaps most important to the CTO, how do they calculate the cost and the ROI?
Just like any software strategy, examining the opportunities and overcoming the challenges of open-source integration requires the right information and comprehensive planning. Where there is risk there is usually reward. But experts say you need to understand the former before you begin chasing the latter.
Integrating Open Source
Rex Wang, vice president of marketing at Sleepycat Software, developer of Berkeley DB, an open-source developer database, told LinuxInsider that successful projects with open-source components and proprietary solutions are not fundamentally different. Both require a sensible sourcing strategy, thorough planning, and solid execution.
“Open source allows the IT manager can migrate as much or as little of their infrastructure as they want. The availability of source code often facilitates the custom integration with existing systems,” Wang said. “The risk of prototyping is low since the IT manager doesn’t have to pay for license fees until deployment.”
Dan Cobb, vice president of national sales with Kforce Technology Staffing, told LinuxInsider that the best way to integrate open-source is component by component.
“Instead of taking your entire infrastructure, choose one component, such as an application server, and migrate from there with an eye toward minimum impact,” he said. “Remember that new systems require new skill sets to support. So move non-critical systems first, which will allow your support staff to gain the job training even if consultants do the actual implementation.”
Component by Component
Perry Donham, a lead technical consultant at Collaborative Consulting in Woburn, Mass., told LinuxInsider that the “fat rabbit” approach is a good way to determine the components that can and should be converted.
“An organization should determine the most expensive element of its IT infrastructure, and then examine existing open-source alternatives to replace it. Doing so provides the biggest bang for the buck, and the savings it creates goes right to the bottom line,” he said. “Companies willing to take on more risk can iteratively find fat rabbits in the budget, and come up with a list of candidates for their databases, application servers,development environments and so on.”
The next step is to analyze each candidate and compare with others to determine whether or not they are compatible. Armed with this list, an IT shop can begin to plan out design and prototyping phases to test the configuration.
Donham said the wrong approach is to jump on whatever application bandwagon currently making the rounds in the press: “It is much better to find stable, long-term open-source projects with significant user and developer communities; these often have much longer release cycles and don’t generate a lot of press in between.”
Avoiding Integration Pitfalls
That’s one mistake. Another is assuming that open-source software is free. While the license to run the software may have zero cost, the organization still needs a hardware platform on which to run. And there will be at least a temporary increase of development and testing staff during migration. Finally, open-source requires product support costs just like a commercial product.
“The second common mistake is to assume that open-source software is of better quality than its commercial counterparts. While it is true that open-source software benefits from rapid development and test cycles, this can also be a weakness,” Donham said. “The challenge is to correctly identify stable open-source components that are a good match for a company’s existing and projected needs.”
Facing the Challenges
There are, of course, other challenges with open-source integrations. Matt Peterson, CTO of Vintela, told LinuxInsider that free software may not specifically meet the needs of an organization. It often has to be modified and further-developed to fit the company’s objectives and technology.
Then there’s the danger that the open-source solution could move a company away from its core business. “If an IT staff is hired and trained to support an existing heterogeneous infrastructure, open-source projects can quickly demand extra involvement, development, and maintenance without the safety net of a commercial vendor to be accountable for the software,” Peterson said.
“These projects can require entire specialized teams of developers to fulfill the role of the vendor of commercial software. Organizations can be left on their own. This risk is mitigated by careful evaluation and selecting flexible, well-designed, and standards-based open-source solutions.”
Risk, Cost and ROI
As Peterson mentioned, many of the risks can be mitigated by careful evaluation of the open-source software. But what about the cost and return on investment? Remember, open-source software is not free. Without careful planning, experts said open-source software could end up costing you more than its commercial counterpart.
ROI is the real advantage most companies are looking for when migrating to an open source environment. But Evan Blomquist, Linux Instructor with TechTrain and author of Linux for Dummies, told LinuxInsider that ROI can be difficult to measure in dollars. The resultant savings from free and open-source solutions, he added, is often realized in less downtime.
“Since Linux is free and can run efficiently on older hardware, the speculation price can be measured solely by the amount of personnel time required to implement a pilot program,” he said. “If the program is successful results will be obvious, if it isn’t successful then it’s just a matter of returning to the legacy solution.”
Loading ...
What about opensource on commercially available OTS platforms? I am working with opensource solutions that run on .NET for some clients. It can be the best of both worlds.