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."
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.
That's not often the case, industry-watchers say. Most open-source applications are essentially commodities, and the platform itself doesn't usually hold many trade secrets.
HSC processes $3.5 billion worth of insurance premiums annually and provides services to about 1.5 million retail insurance members.
The company chose Healthation because it was the only healthcare transaction software Kaderabek knew of that was available as open source. With Healthation, HSC could kick-start its IT transformation project because the majority of new core functions were already in place and the IT team had to customize only about one-third of the system.
"This [open source] out of the gate was leaps and bounds ahead of the design and architecture" of traditional software systems, Kaderabek says. "It was built on latest and greatest technology; it used Web services; it was .Net using SQL server -- which all met our standards. We got more done in a shorter period of time and didn't have to add extra resources," he says.
Kaderabek says that even when evaluating small or industry-specific open-source projects, IT shops should look for vendors that specialize in maintaining an open-source offering. "Make sure there's somebody out there who can say, 'I've done this for the last five years, and I know people who have done what you're doing,' in case you need help," he says.
When It's OK to Give It Away
Contributions to an open-source community don't have to be huge to be valuable. "If there's a low-level feature that's a more convenient way to do something -- that saves everybody time," says WibiData's Kimball. "Sometimes even small changes that may not take more than an afternoon to write will have an outsized benefit on usability."
WibiData initially developed its entire software stack alone, but in September 2012 it decided to make part of that stack available as open source and released the Kiji project in November.
Offering some tools as open source benefits WibiData in several ways, most notably by broadening the company's user base, says Kimball. Fundamental layers of the stack have a low value, and users won't pay for tools that aren't unique to their business, especially if similar tools are available. Open-sourcing those layers introduces new users to other WibiData offerings. "There are plenty of people who can make use of these components who [weren't] customers or potential customers, but now they're using and testing the same software that our paying customers use," Kimball says. "So everybody enjoys increased reliability of the overall system by virtue of it being more widely adopted."
Moreover, open source provides a foot in the door to companies that might not be ready for a big-data tool yet. "If common-based layers of our overall system are widely available through open source, [developers] might just start using it. And later on, when their organization needs to get serious about using an open-source application, it's much easier for us to go in and sell to those business users because our software already runs on parts of their stack. Interoperating with it and getting it to work with the rest of our systems is much easier rather than if they had built this same system in a completely bespoke fashion."
Kiji has received only a few contributions from its developer community so far, but Kimball believes that will change. "For every 15 people who use it, one might file a bug report -- without providing a fix. But it's very early days," he says. "Where this goes is an open question."
The future of open source in general looks bright. Broader adoption will create larger communities for testing and feedback, which in turn will drive innovation in areas such as cloud computing, mobile and big data, according open-source vendors.
The innovation cycle is also creating new business models. "Open source is key to a company's ability to innovate and sustain innovation with financial benefits, interoperability and a supportive community," Webb says. "Those are the things that are going to keep it going."
Stacy Collett is a Computerworld contributing writer. You can contact her at stcollett@comcast.net.
Read more about applications in Computerworld's Applications Topic Center.