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.