Integrating open source into proprietary applications has its challenges. Experienced IT execs explain how they did it
Open source is almost like religion: Either you believe or don’t believe that it’s a better solution than enterprise software, says Sheldon Wang, chief technology officer at eHealth Inc.
For open-source evangelists like Wang, who heads IT for the Internet-based health insurance marketplace, there is no limit to the possibilities of integrating open-source applications with proprietary applications. But even believers face integration challenges. Here’s a look at why and how Wang and other IT executives overcame the challenges of open-source integration.
Take Baby Steps
In 2001, Mountain View, Calif.-based eHealth had survived the dot-com bust, but funding, once easy to come by in Silicon Valley, had grown tight. Open-source applications, with their lack of licensing costs, emerged as attractive alternatives to commercial software.
But introducing open-source applications wasn’t easy. The system that ran eHealth’s Web site was large and complicated — with more than 30,000 HTML pages and over 750,000 health insurance underwriting rules. So Wang proceeded slowly.
“It’s a step-by-step process,” Wang says. “First we put in an application server, an Apache Web server. Then, over time, we put in all the Linux operating systems and migrated away from Sun hardware. Then we switched the BEA application server out to JBoss,” he adds, naming just a few of the changes eHealth made. Nine years later, his company’s production environment consists of open-source applications completely, except for an Oracle database. “It’s all [open-source software], from operating systems, middleware, application server, Web server and more,” Wang says.
EHealth has come to rely on open source so heavily that it has established a six-member evaluation team that is solely dedicated to researching, testing and choosing the company’s next open-source applications.
Wang admits that developers occasionally run into software compatibility problems because the open-source components aren’t necessarily designed to their specs. But they resolve those issues by extensively testing during the selection process, adopting a service-oriented architecture in which each component runs independently and interacts with the others as a service, and modifying source code. “This is one of the best parts of open source,” Wang says. “We’ve got the source code and can modify as needed.”
Even if compatibility problems can be resolved, sometimes the software just doesn’t work out or requires extensive modifications. “Timing of the adoption is very important. The mistake we made was adopting too early before [the software] matured,” Wang says.
When it came to system and network monitoring, none of the open-source systems available had all the features eHealth required, so developers implemented several systems and discarded pieces of each one that they didn’t need, says Wang. “The nice thing about this [software] is we can do the stuff without a lot of cost and contracts,” he adds.
Wang advises IT leaders to start small and integrate open-source components one at a time. “Don’t go to a conference and understand the benefits of an all-open-source [environment] and then go back and try to implement everything overnight. That would be a disaster,” he says. “Have a few wins, and win your team over. Then you can do more.”
Two years ago, Econstruction‘s Jason Woerner decided that open source was strategically the direction to head in to update the company’s flagship collaboration software, which is designed for the construction industry.
“We wanted to be able to evaluate software without going through a vendor’s sales process,” says Woerner, vice president of product management at the Toronto-based provider of technology and consulting services to the construction industry. What’s more, he adds, with many open-source applications gaining a large community of developers, “we thought that would transform the open-source vendors into industry leaders. We want to be part of that.”
First, he chose an open-source content management application that was flexible enough to integrate with existing components and was capable of building industry-specific applications. But his development team still ran into two integration challenges.
“The biggest challenge we had was related to authorization, authentication and session timing. We want all of our systems working together such that there can be a single authorized session for each user in the system, and to make this session synchronized across all components,” both enterprise and open source, Woerner explains. “If a user logs in once, they should not have to log in again when working in [enterprise content management] or any other component. If they time out in one system component, they should time out of all components.”
To get common support for authorization and authentication across all components, Woerner’s team wrote a custom plug-in for one of them. “The open-source world has not quite matured when it comes to single sign-on. But the beauty of open source is that this was not hard for us to overcome, or for any organization that has developer expertise,” Woerner says.
His other challenge was selecting the database for the company’s application. He needed to choose one database technology that all components would work with. “We accomplished this, but not without a few hiccups,” Woerner explains. “When a software product says it supports a particular database, be sure to dive deeper into questions like high-availability configurations that involve the database.”
Change Tacks if you Need to
Russell Taga and his team at Howcast.com in San Francisco built the how-to video Web site Howcast.com from the ground up with open-source software. To speed the development process, he tapped open-source vendors’ expertise to perform networking tasks, systems administration and database administration — and it only cost what he would have had to pay one full-time employee, says Taga, who is vice president of engineering at Howcast.
“We get access to top-notch people with all those skills to help us build the cluster that we have,” he notes.
The biggest issue that his developers faced was a lack of thorough documentation. “A lot of times with open-source software, there’s some documentation, but you have to spend a lot of time looking at user forums and Googling for information when you run into problems,” Taga says. “You have to be willing and have time to hunt for solutions to problems.” Otherwise, you should drop the application and choose another open-source or commercially available application.
For example, Howcast tried an open-source application to do asynchronous processing and found that it was unreliable. “Once we started running into problems, we spent a certain amount of time trying to figure out what the issues were. If we felt like we could fix them, we would be more than happy to contribute patches [to the user community],” Taga explains. But in this case, he says, “we felt like the product just wasn’t good enough and chose another alternative.”
Other times, the best solution is a commercial product. Howcast found that for some of its video transcoding, the video quality produced by the open-source application FFmpeg wasn’t up to snuff. So the team opted to go with licensed software.
Today, Howcast deploys 10 to 15 open-source applications. “We always evaluate things on a case-by-case basis. Obviously, our preference is an open-source solution so that we avoid the licensing cost,” Taga says. But if the best solution is licensed software, “we’re more than happy to do that, too.”
Collett is a Computerworld contributing writer. You can contact her at stcollett@aol.com.
