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.

Choosing open-source software is more complicated than picking traditional software. Is your IT department prepared to contribute code fixes to the community?

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.

"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.

West Texas A&M chose the CAS project for its single sign-on system because CAS had been successfully deployed at Texas A&M University in College Station "and the references were solid," Webb says. His team also attended user events and higher-education conferences related to CAS as part of the decision-making process.

Main story continues on next page

Community Involvement

Open Source Gives Back

Several nonprofit open-source organizations now help companies give back to the community by providing their programmers with opportunities to volunteer their time and talents to benefit social causes.

Through the work of nonprofit organizations such as Benetech, FrontlineSMS, The Guardian Project, Mozilla Webmaker and Wikimedia Foundation, so-called humanitarian free and open-source software has emerged as an important tool in tackling global social challenges, including civic engagement, disaster relief, education, healthcare and human rights.

Several tech companies already connect their technologists with opportunities to contribute their skills to projects that benefit social causes -- as VMware does through its #ContributingCode initiative, for example. But any company can get involved in such initiatives. One source of information about these efforts is SocialCoding4Good, which is running a pilot program with several nonprofit organizations that develop humanitarian free and open-source software.

What can companies and employees gain by giving back? Plenty, according to one of several nonprofit groups that organize open-source projects to improve the lives of people worldwide.

"It creates a tremendous professional development opportunity for employees," says Gerardo Capiel, vice president of engineering at Benetech, which sponsors open-source projects benefiting literacy and education, environmental conservation and human rights. Some programs leverage their company's existing technologies and can influence how they affect the world. Others let programmers choose their own cause from a list of nonprofits.

Contributing to social change can have an impact on employees, as well. Programmer Abhi Mahule was looking to donate his skills and time to a cause when he learned about Benetech, which wanted to build an Android-based e-book reader for the visually impaired. Mahule took an existing open-source e-book reader and adapted a version for Android that could "read" books aloud as audio. He built a prototype, and Benetech secured funding from the U.S. Department of Education to bring it to market. Today, thousands of people use the app, Capiel says.

The project "helped me [hone] my technical skills," says Mahule, but adds that the intangible benefits were more significant. "It was a source of joy and a nice feeling that in a small way you're able to contribute," he says. "You should always look out for a larger cause for the greater good. This is the perfect opportunity for that."

- Stacy Collett

It Takes a Village

For many open-source projects, the developer community is the lifeblood of the software, and those who are new to open source should know that these communities all operate differently.

The well-established Linux community, for example, has operated under founder Linus Torvalds' "benevolent dictatorship" since its inception. But developers of new projects often keep tight control of their communities as well.

WibiData, a Hadoop-based user analytics company that helps organizations build big data applications, provides part of its software stack as open source to make it easier for developers to build big data applications on an HBase NoSQL database.

"Right now, 99.5% of the software is written by our own team," says Aaron Kimball, chief architect at WibiData. "It takes a relatively long time to get people to use it, and for every 50 people who use it, one might start helping to contribute."

Then there are the radically democratic models. Developers who donate a product to the Apache Software Foundation, for instance, must reach a "lazy consensus" with the community, which means "you need some number of individuals to give your idea a thumbs-up and for nobody to give it an explicit thumbs-down -- and if they do, they are obligated to work with you to make the changes," Kimball says. "It's designed to slow things down in some ways so all users can be invested in this and through consensus arrive at the best solution." Although the developers who participate most actively in writing source code are expected to be the ones who are listened to first, he adds.

Is It Better to Give Than to Receive?

IT departments might think that when they buy into open source they also have to actively participate in the community to ensure its survival. But that's not always the case.

With widely used open-source products like Red Hat, "[vendors are] very much in control of the community," Nystrom says. And while they do take from the community, "they still control the product," he adds. "They're not dependent on the community for the product to be stable and go forward."

Sprint Nextel currently relies on Red Hat consultants as its liaison with the open-source community, but Krause believes the company will need less hand-holding as time goes by. "We will eventually move away from Red Hat being our support system and work directly with the open-source community," he says.

For users of smaller open-source libraries or projects, communities are much more important.

"There's just a group of people who put this together, and there might not be a commercial entity behind it," Nystrom says. In these cases, developers are expected to contribute, but what if they refuse?

One open-source user says it's hard to contribute, or "pay it back," when the product is industry-specific.

When Hallmark Services Corp. (HSC) in Naperville, Ill., was overhauling its back-end systems, it bought a license for the open-source code of Healthation, a commercial off-the-shelf system for administrating healthcare business transactions.

Taking an open-source approach reduced the amount of labor required to complete the project, enabling HSC to finish more than nine months early and save $4.8 million in labor costs, according to Neal Kaderabek, CIO and vice president of financial services. HSC is a co-developer of the software with Lisle, Ill.-based Healthation, and it has the right to exclusive use of functionality that it developed -- it doesn't have to make it available as open source.

"We rarely check anything back in -- we just take it out, modify it and make it unique to our business," Kaderabek says, adding that HSC shares less than half of what it develops with the community. "Frankly, we think that sets us apart from our competitors, so why would we want to let the world share it?"

He acknowledges that Healthation was disappointed that HSC wasn't contributing to its open-source community. "Their view was that's what makes their product more attractive to the industry. But in this case, I just felt like it was our secret sauce," he says.

1 2 Page 1
Page 1 of 2
The 10 most powerful companies in enterprise networking 2022