Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Sizing up open source: Not so simple

Stacy Collett | May 7, 2013
Choosing open-source software is more complicated than picking traditional software. Is your IT department prepared to contribute code fixes to the community?

But there are other things to consider when looking at open-source systems, such as the culture of the community, the consistency of the product's quality, and how quickly the community responds when security fixes and patches are needed.

"It's important to evaluate smaller, open-source projects differently than larger, corporate-sponsored open-source products," says Tomas Nystrom, a senior director and global lead for open source at Accenture.

There are hundreds of thousands of small open-source projects or libraries, such as NAS and Spring, that rely heavily on user communities. Then there are open-source products, such as Red Hat Linux, which are managed by, and often owned by, companies that are in the business of selling software.

Sprint Nextel decided that a well-established product would best meet its needs when it ventured cautiously into open source, having grown tired of paying vendors millions of dollars in maintenance fees for Web and application server software, even as the need for support declined.

"We had built an internal team who was responsible for the Web and apps servers, and we believed we could move to an open-source product and still be successful," recalls Alan Krause, director of enterprise application integration at Sprint. But going it alone was a scary proposition for the CIO and a vice president, who both wanted the security of having a vendor to lean on if problems arose.

"There really was some trepidation there," Krause recalls. So the organization chose JBoss Enterprise Application Platform as its new middleware and Red Hat Enterprise Linux as its new operating system. It also used Red Hat's consulting team to help with implementation and let a Red Hat relationship manager serve as liaison with the open-source community.

"We're kind of dipping our toe into open source," Krause says. "We're still paying some maintenance for it, but it's significantly cheaper than what we were paying before."

When looking at open-source products like Red Hat, the selection criteria are no different from those that apply to commercial software, Nystrom says. "They're considered to be normal vendors with high-quality products that are comparatively cheap."

As open-source products gain traction at companies like Sprint Nextel, IT departments will feel more comfortable turning to smaller, open-source projects to foster innovation, Nystrom says. "If you're building something custom, it's typical that you use [open source] somewhere during development," he says. "It's almost impossible not to use it if you want to build a very modern application."

In such cases, Nystrom recommends a bottom-up approach for choosing open-source projects.

"Developers and architects know what the communities are like and which are the libraries that are in much use today," Nystrom says. "They have a clearer view of which library we should use for which purpose, or which version of some type of persistent API we should be using here, or what's the best log-in library. So you can narrow down the number of libraries that are relevant for the enterprise very quickly -- from hundreds of thousands to probably less than 100, depending on what you want to build." And from there it's a quick move to a few "usual suspects," he adds.

 

Previous Page  1  2  3  4  5  6  Next Page 

Sign up for MIS Asia eNewsletters.