Open source's integration jams -- and how to fix them

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.

1 2 Page 1
Page 1 of 2
7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon