Options for Enterprise Open Source Applications Continue to Grow

The next time you have a project in need of a software solution, try an experiment. Go to open-source collaboration site SourceForge and spend five minutes running a search. The odds are good that you’ll find an open-source project related to your problem. Free. No sales calls. No negotiations with vendors.

Granted, no service contracts or tech-support numbers either, most likely. But given the low barrier to entry, it’s easy to understand why thousands of companies are tempted to use open-source for, at the least, those projects that fall shy of the mission-critical line. And for those CIOs nervous about the support and licensing issues that surround open-source, well-known vendors are increasingly releasing some of their own code to the open-source community. IBM, for example, in January released 500 of its software patents to open-source software developers. Sun Microsystems Inc. has announced that it will release its Solaris operating system under an open-source license.

Of course, if you’re looking at open-source precisely because you want to get away from those very vendors, maybe there’s a better alternative: a cooperative of like-minded, open-source-loving CIOs just waiting for you to join. The options for using open-source have never been greater, and you owe it to yourself — and your company — to take a close look.

Power of Cooperation

One of the challenges of using open-source is simply finding a product that meets your needs and your quality standards. While many developers need an e-mail client or Web browser (hence, the rabid developer base for open-source projects such as The Mozilla Foundation’s Thunderbird and Firefox), finding a spontaneously developed tool to integrate your three retail-specific supply chain applications isn’t as likely.

And even if your SourceForge search uncovered such a tool, there’s no guarantee that the developers wrote it with the care your enterprise requires. (To at least partially address this concern, VA Software Corp. offers SourceForge Enterprise Edition (SFEE), which helps developers create shared code environments among known collaborators, and the Tapestry portal, which lets Enterprise Edition users access information about other SFEE projects.) Plus there’s the “Where did this code really come from?” legal question. To assuage these fears, some organizations have turned to cooperation with peers for their open-source development.

One of the most high-profile examples is the Avalanche Corporate Technology Cooperative, a collective development effort founded by a group of Minnesota-based companies, including Best Buy Co., Cargill Inc. and Jostens Inc. Last spring, the group formed to identify opportunities for open-source development projects that could benefit all the members. The goal of this cooperative is to pool resources so that interested companies can jump into new projects while spreading out the risks and expenses. Some of the members, for instance, are too small to create full-blown development efforts on projects such as building an open-source desktop reference environment, but by combining efforts, they can all reap the rewards. Avalanche currently has a half-dozen projects under way, including one to create a reference design for an open-source desktop and another to build a business activity monitoring engine.

“We’re relative novices in the whole open-source area,” says Mike Thyken, senior vice president and CIO at bedding manufacturer and Avalanche member Select Comfort Corp. “We started looking at everything it was going to take to get a Linux/open-source world put together, and we saw that it was very redundant between companies.”

So Select Comfort joined Avalanche, contributing a membership fee of $30,000 as well as some time from technical architecture experts inside the company to Avalanche’s Linux reference environment project. As a result, Select Comfort expected to receive deliverables on a Linux desktop and server architecture early in 2005, all for a “fairly modest” investment of money and time, Thyken says — far less than if the company had attempted the project on its own.

Aside from the efficiencies of cooperative development, Avalanche members can receive other benefits as well. Avalanche’s licensing agreement restricts the cooperative’s code to members only, eliminating the fear that valuable code will simply be spread far and wide, without competitive benefit to the contributing members. And then there’s the question of putting pressure on commercial software vendors.

“One of the original premises was that the balance of power had swayed quite heavily to the vendor side,” says Jay Hansen, CEO of the cooperative. “The IT consumer wanted to take back a little bit of the control over their own destiny.”

Financial services companies are getting in on the open-source action as well. What began in 1997 as an internal effort to consolidate integration development at international investment bank Dresdner Kleinwort Wasserstein (DrKW) has become Openadaptor, a Java-based open-source integration platform.

“The most common thing you have in a bank is communication between systems,” says Steve Howe, DrKW’s vice president and head of open-source initiatives. In the late 1990s, the company set out to create a standardized programming interface that would keep internal developers from having to reinvent basic code for every new project. The code behind the interface was shared with all of the company’s developers, and each was able to make suggestions for — and sometimes even changes to — the source code. The result was a dramatic decrease in development time for connectors.

The system worked so well, in fact, that DrKW hired software development collaboration provider CollabNet Inc., which hosts collaborative development environments for both commercial and open-source projects, to release its connector platform in open-source as the organization Openadaptor. DrKW wagered that if other organizations got involved, it would result in further enhancements to the platform. The idea worked. The core software currently sees more than 8,000 downloads a month of the organization’s site. And while no one knows exactly how many corporations are taking part, Howe says that Deutsche Bank AG, Hallifax Bank of Scotland, Hewlett-Packard Co., J.P. Morgan Chase & Co. and The Royal Bank of Scotland Group PLC are all involved.

Howe notes that Openadaptor is a case of an open-source product unlikely to see a commercial competitor. “The really good thing about Openadaptor is that it’s really lightweight. There’s not much real impetus for the vendors to put that sort of thing out; they couldn’t charge very much for it,” he says. In other cases, the project could have a more dramatic impact on an existing vendor. Such is the case with Sakai.

Costs and Competition

The Sakai Educational Partners Program is a set of projects spearheaded by universities looking to provide common platforms for a variety of tasks. One of those tasks is the creation of an open-source course management system — one aimed directly at a technology space currently occupied by Blackboard and other commercial competitors.

According to Sakai community liaison James Farmer, a recent survey of 22 universities currently using Blackboard found that 100% planned to drop the commercial product in favor of Sakai code. But Farmer is clear to point out that this project isn’t about vendetta; it’s about saving money. Having an open-source, cooperative development option would let schools reduce their costs by skipping commercial alternatives completely, or indirectly, by using the threat of open-source to “put some restraint on price,” Farmer says.

Malcolm B. Brown, director of academic computing at Dartmouth College, agrees with that assessment, noting that he wouldn’t be afraid to use Sakai as leverage with his vendor. But he says cost is secondary to functionality. An admittedly happy Blackboard customer (he had zero downtime on his course management system last term), he says that the school is nevertheless keeping an eye on Sakai to see if it can provide a better product than the commercial alternatives. “The promise of Sakai is that it’s written by universities for universities,” Brown says, noting that university developers should be more aware of the complex relationships that can grow between educators and IT. “It can be tough to make all [the instructors] conform” to an application, Brown says. “The platform needs to be customizable and nimble.” And if Sakai can deliver on those needs, he says, Dartmouth would consider moving to its platform. But for now, he notes, “It’s too early to see how this is going to play out.”

Getting the bulk of educational institutions moved to a single platform would save money in another way as well. “If you can interchange content, you will sharply reduce the cost of instruction,” Farmer says. For instance, “McGraw-Hill produces 24 versions of its materials to support all the electronic teaching systems,” including Blackboard. “If they could reduce to one standard, they could cut the cost of their media support by 80%. Textbooks are expensive because faculty members are judging not just on textbooks themselves, but on the quality of the other materials available for their online courses.” Sakai, if widely adopted, would provide that single platform.

What began as a cooperative effort among four schools — Indiana University, MIT, Stanford and the University of Michigan — has grown to include more than 50 schools, including the bulk of the most prestigious purveyors of higher education in the world.

But while these cooperative efforts all are success stories (at least for now) it doesn’t mean every corporation should immediately look to join a cooperative or start its own.

“If you’re not comfortable using anything other than packaged software, we’re probably not for you,” says Andrew Black, vice president and CIO at Avalanche member Jostens.

Vendors Open Up

For companies not inclined to stray far from the warm comfort of packaged products, there are more open-source options offered by the vendors themselves. Reacting to pressure from existing open-source projects and intrigued at the idea of expanding their developer base dramatically for minimal costs, many large vendors are even releasing some of their own products as open-source, offering the software’s source code for free and allowing users to make changes as they see fit. Computer Associates International Inc., IBM, Novell Inc. and even Microsoft Corp. (on a tiny scale) have released source code for community use and development. And a number of smaller vendors — including Chalex Corp., Gluecode Software Inc., JBoss Inc., SugarCRM Inc. and MySQL AB — are built on an open-source foundation.

Customers need to look at such pronouncements with a skeptical eye, however, as many vendors may see open-source as an easy way to dump old products. And in those cases, the open-source effort benefits no one.

The idea of having “one throat to choke” when something goes wrong, the legal indemnification some vendors provide against lawsuits concerning open-source and the simple comfort of not having to vet one more software application can make vendor-released open-source appealing. The vendors, meanwhile, tout open-source as a means of helping themselves by reducing development costs and getting customers directly involved in the development process, and they even candidly note attempts to jump-start fading products (for example, CA with its Ingres relational database) or give birth to ideas that might not have been profitable commercial ventures (IBM’s Eclipse development environment project).

But the temptation exists to simply euthanize products by handing them to the “community,” thus abdicating further support responsibilities. “Sometimes engineers and product managers make assumptions,” says Jeff Hawkins, vice president of the Linux Business Office at Novell. “A common one is ‘Gee, I don’t have the resources on this, so let’s make it open-source,’ or ‘We don’t really care about this anymore, so let’s release it to open-source.'” But, Hawkins says, this almost guarantees open-source failure.

“[You] have to examine [vendors’] motivations,” DrKW’s Howe agrees. “I think a lot of people are effectively end-of-lifing products in an open-source way. That doesn’t work because you end up with a lot of dead software out there that no one’s updating.”

That very concern struck Shaf Rahman, group technical director at International Customer Loyalty Programmes (ICLP), which puts together loyalty marketing programs for companies, after he heard that CA was going to release its Ingres database — on which many of ICLP’s core systems are built — to open-source.

“I think in the back of my mind there was that thought that ‘They’ve absolved all their responsibilities and given it to the people.'” But his fears were calmed after he saw the orderly manner in which the company handled the transition, plus the fact that CA was clearly staying in control of the project and carefully vetting any potential contributions to the source code. This provided both indemnification for any potential legal hassles and a well-known source for support services. As a result, Rahman has hopes that Ingres will be revitalized, gaining both new features and, more importantly, new prominence in the marketplace. “In the past, I’d try to recruit people and they’d say “Ingres? How do you spell Ingres?'”

Some observers see the trend of vendor-released open-source as a sign that certain parts of the software stack — particularly those at the low end that have become ubiquitous (think operating systems and integration tools) — simply have very little commercial value left and thus are better supported by their communities, freeing up R&D resources for high value-add products.

“Things like [Microsoft] Word and Excel have become relatively static,” says Ian Campbell, president and CEO of Nucleus Research Inc. “That’s why you see Linux on the desktop with the [open-source OpenOffice productivity suite] as a reasonable alternative.” And, he says, as time goes on, more products will fall into the “best as open-source” category.

Lead or Get Out of the Way

Open-source advocates have their own worries, of course. One concern with open-source is the threat of the nuclear lawsuit, the legal case that could declare certain open-source licenses unconstitutional (think SCO vs. the GNU Public License) or make the burden of intellectual property protection so onerous that software communities are crushed under the weight. But observers argue that legal uncertainties are a fact of life with commercial software as well.

“Is there risk? There’s probably some,” says Bernard Golden, author of Succeeding with Open Source and founder and CEO of Navica, an open-source consultancy. “But you need to look at all the risks, including the risk of not doing the project.”

Simply banning open-source probably isn’t an option, however. As just one example, software development researcher Evans Data’s numbers have shown an almost 200% increase in use of MySQL by database developers since 2001 — from 16.4% to 48.5%. And as large open-source projects such as the Eclipse development environment gain steam, the temptation to download and use the tools — rather than wait weeks for a purchase order to clear accounting — will do nothing but increase.

But like anything in IT, the best way to approach open-source is with a plan, with skepticism and with the understanding that you’re going to need to roll up your sleeves.

“The more you put into something, the more you get out of it,” says Mike Milinkovich, executive director of the Eclipse Foundation. “Open-source is no different.”