Opening the Door to Open Source
- When to use — and when not to use — Open Source Software
- Advice for Optimizing Open Source
This chapter is from the book
This chapter is from the book
This chapter is from the book
When to use — and when not to use — Open Source Software
Special to Flashline
When Cardinal Distribution, subsidiary of medical products conglomerate Cardinal Health, needed a Java application server to revamp its mission critical pick-and-ship warehouse automation system, the decision was shaping up to be a choice between IBM's WebSphere or BEA Systems' WebLogic. Instead, the IT staff opted for an Open Source product: the Tomcat application server from the Apache Software Foundation.
Why, you might ask, would a $51-billion-company, ranked 19th of the Fortune 500, choose an Open Source application when it had a budget for a top-of-the-line commercial product? According to Jon Foster, a consultant and the former director of enterprise architecture at Cardinal Distribution, the decision came down to one key factor: flexibility.
"We'd reached the point where we had to make a deployment decision and the corporate direction [between IBM and BEA] hadn't been set," explains Foster, currently the CEO of IT consulting firm Helm Solutions Group, based in El Dorado Hills, California. "We'd been using Tomcat in our development lab, so we approached upper management and said, 'Look, we can achieve significant cost avoidance by going with Tomcat and, at a later date, swap it out with something commercial if we have to."
While Foster did initially worry about Tomcat's scalability and reliability — given that it would have to support millions of critical transactions each day in Cardinal's two dozen warehouses — he says they experienced no performance problems. To make sure, they put the new application through extensive lab simulations and deployed it on a rolling basis, starting at the distribution centers with the lowest transactions and moving upward.
"In my experience, the things you tend to give up with Open Source aren't reliability and performance so much as the bells and whistles — like a good GUI," says Al McAlister, who worked on the Cardinal project with Foster and is now vice president of software development at Helm Solutions.
While the Cardinal Health story — of a major company building a mission critical system on Open Source software — is by no means a common one, it is nonetheless becoming much less rare. Increasingly, it is possible to find Open Source in large organizations and in more mission critical settings.
Part of the impetus toward Open Source has come from the success of the Linux operating system, which has been gaining ground as an alternative to Unix and Windows. The advent of Web services has had an impact as well. "Web services reduces the barriers to entry for Open Source alternatives," notes Jonathan Eunice, president of IT analyst firm Illuminata. "In the old days, the economics of the world was predicated on investing in IBM's strategy or Microsoft's or Digital [Equipment Corp.]'s strategy. Because everything had to reside on the same box and have the same API set. Now it's easier to have one part of your architecture run on Windows, while another part runs on [the] JBoss or Apache [Open Source application servers]."
Also, Open Source groups have been active in Web services development, according to Jean-Christophe Cimetiere, of analyst firm TechMetrix Research: "Each time a standard is defined, you see Open Source among the first of the implementations."
There are currently a wide variety of Open Source products. To name a few: the Jakarta Struts framework from the Apache group, the OpenOffice.org desktop office suite, and the Eclipse Consortium's development and integration platform, launched by IBM. (For a full listing of Open Source infrastructure components, see Flashline's Open Source Framework Matrix.)
As Foster and other experts will quickly point out, however, Open Source is not for every situation or every enterprise. There are, in particular, three key differences between Open Source and commercial products: price, support, and customizability.
-
Price. Foster estimates Cardinal saved millions by choosing Open Source. But licensing costs aren't the only, or major, part of a development project and they're more likely to be of critical importance to smaller firms, in which the cost of a project can be a make-or-break factor, and which usually can't qualify for discounts from suppliers. "A piece of middleware like a J2EE application server might cost $7,000 per CPU, plus a 20% support contract going forward. Development tools run $1,000 to $10,000. So there can be direct savings by going to Open Source. And for some of these firms, frankly, it's a choice of doing it on a shoestring budget or not doing it at all," notes Corby James, CIO of Noblestar, a Reston, Virginia-based software developer and integrator.
-
Support. Darren Chiappinelli, vice president and co-founder of Sabot Technologies in Sacramento, California, remembers one client — a government agency — that chose the Open Source language Python for a development project, only to later abandon it for lack of support. "They had one person who liked Python and knew it really well, but that person's bandwidth couldn't keep up with the support needs. And they didn't have the budget to train more people or outsource it," says Chiappinelli.
-
Customization. The freedom to tweak the source code is a key advantage - and the very definition - of Open Source. It can make debugging projects a lot easier, since developers can get into the code rather than depending on the vendor for help. And it allows customization to suit special requirements. With a commercial product, a customer must either accept it as-is or, if he has enough clout, convince the vendor to make modifications. Even so, changes can take a long time, notes Sharon Fay, Chief Software Productivity Strategist for Flashline, Inc., and a member of the Flashline Software Development Productivity Council. "One of our customers was using a commercial framework product for the financial services industry. The vendor was working with them to meet their particular requirements but it just took a long time to collaborate and get those changes made. By contrast, I know customers who have picked the Struts framework and did their own modifications. While it also took time, they at least had control over the timeframe and were free to customize it as they saw fit."
In the Open Source world, support typically comes as some combination of in-house expertise, assistance from the Open Source community (via forums and downloadable documentation), and possibly third-party consultants. Generally, the more popular the product, the greater the availability of all types of support. Conversely, for lesser-known Open Source products, it may be nearly impossible to find people with the right expertise.