Sizing up open source: Not so simple

Open-source software throws a wrench into traditional software evaluation criteria. Here's what to look for and what you'll be expected to contribute.

When West Texas A&M University wanted to develop a single sign-on portal for its 8,000 students that would unify its Web applications, student resources and social networking services, a steering committee came up with a list of six criteria for evaluating available software. They would compare software systems' features, mobility, single sign-on capabilities, look and feel, and flexibility, as well as their ability to integrate with existing Web applications.

But this wasn't an apples-to-apples comparison. CIO James Webb threw in a pair of open-source projects to be considered alongside commercial software packages. While it was easy to compare the systems on many of the criteria (the open-source pair won in all six categories), the committee had to add another question: How strong is the open-source user community, and could it help the university achieve its goals? The answer was yes, and the Canyon, Texas-based school chose the two open-source tools: uPortal, an architecture based on Java and XML, which also included support for mobile devices, and Jasig's Central Authentication Service (CAS) for its single sign-on service.

"One of the main reasons we went with the uPortal open-source solution is that Yale, Rutgers and the University of Wisconsin-Madison are the major developers. So I guess you could say it was built by higher ed for higher ed," says Webb. "We know we have an ecosystem of great universities that are contributing to the open-source initiative, supporting it and providing additional features to keep this product innovative."

Open source is the new X factor in software selection. More than 50% of all software purchased will be open source by 2017, according to a 2012 survey of 740 enterprises released by a collaboration of 26 open-source companies. That finding signals a tipping point for open-source software adoption in the enterprise and nontechnical fields such as the automotive, healthcare and financial services industries.

Choosing the right open-source offering could be critical to an organization's success. But evaluating an open-source project holds more caveats and pitfalls than picking traditional software. IT departments must consider the culture of the open-source community, the quality and timeliness of releases, the project's governance model and the availability of support. They also have to consider whether, and to what degree, they're willing to contribute code and fixes back to the community.

Here, organizations that have successfully adopted open-source systems share the criteria they used to evaluate projects and their philosophy about giving back to the open-source community.

'Projects' vs. 'Products'

Many IT departments evaluate open-source systems the same way they assess commercial products. They look for tools that offer superior functionality and lower maintenance and support costs. Many also turn to open source to escape vendor lock-in, foster sustainability within the IT infrastructure and spur innovation in IT operations.

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.

1 2 3 4 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies