Means of Production

Universities are wrestling with the possibilities and pitfalls of making homegrown IT products available beyond their campuses. CT examines the benefits of the two major options: open source or a commercialized venture.

• By David Raths
• 02/01/12

No one who's worked in higher education will ever confuse the experience with working in the corporate sector. Colleges and universities are simply not geared for the business of manufacturing or marketing products. The focus--as it should be--is on teaching and research. Given the wealth of talent among IT staff and faculty, however, higher ed institutions do develop cutting-edge IT solutions to in-house problems. In many cases, these same solutions could help other institutions. Are there benefits to distributing these products to a wider audience? What's in it for the institution itself? And how does a school even go about it?

Adapting an in-house product for use by outside customers makes sense only under certain circumstances. In these constrained times, few CIOs are likely to throw their support behind a project if the only return is a sense of self-worth and a lighter wallet. And if the first attempt at such a project doesn't succeed, don't expect a second chance anytime soon.

"A first success is huge," says Patty Gertz, executive director of Jasig, an open source consortium that started out as a special-interest group of Educause and is now in the process of merging with the Sakai Foundation. "You have to convince a CIO that this is worth doing," she says, "and then convince new CIOs all over again when there is change at the top."

Broader Research Community
Among institutions seeking to distribute homegrown products more widely, the main motivation is usually to improve the product while reducing demands on the school's own resources. This usually means going open source. The concept is simple: The more developers and schools that work on a product, the faster its quality improves at a lower cost per participant. It's a collaborative approach that works well in an environment where most schools face resource constraints.

Six years ago at the University of Wisconsin-Madison, for example, IT leaders decided to go the open source route on the school's portal platform, because they thought they would have more control over how the product was developed and could collaborate with colleagues on improving it. "Wisconsin has added capabilities and donated them back to the community," notes Jim Helwig, project manager for the portal infrastructure team at the university, "and the great thing is that the community helps you maintain those enhancements. You are not just on your own."

In 2007, the University of California, Berkeley took a similar approach when it decided to make its Berkeley Continuity Planning Tool open source. The hope was that others would pick it up and help its development with more resources than Berkeley's IT group had internally.

In the first 18 months, there were 100 downloads of the source code, and a number of UC campuses were among those early downloaders. Berkeley officials met with the central office of risk management for UC schools and proposed offering the software as a service called UC Ready to all UC campuses. "The central risk management office ended up underwriting the cost once we showed them it would reduce insurance rates," recalls Shel Waggener, Berkeley's chief information officer.

Making the decision to go open source, however, does not guarantee a bevy of collaborators. Waggener learned that getting other schools to download the source code isn't enough. You need to build an active development community around the product. It's a viewpoint shared by the IT department at Wisconsin. "Open-sourcing a project really takes a lot more than just zipping up your code and hosting it on a website," explains Nicholas Blair, a senior information-processing consultant at the school. "Sure, anyone can download your code, but without help understanding it, it's not really going to go far."

That's why many initiatives get funneled through open source consortia, such as Kuali, Jasig, and the Sakai Foundation. Two years after launching UC Ready, for example, Waggener decided that the project would benefit from additional sponsors. "In 2009, we took it to Kuali with the model of an ongoing community project, and they were interested," he recalls. Now a group of 10 private schools, community colleges, and research universities is partnering on Kuali Ready.

Waggener says the transition to a Kuali team effort has made it a sustainable program, with partners who are engaged and contributing. "If a risk manager working with developers in Indiana comes up with a good idea, it is instantly deployed," he says. "So development happens faster and at lower cost."

Building a Support Network
It's difficult to overstate the importance of building a support network. Indeed, three years ago Jasig changed its modus operandi specifically to address the issue, creating the Incubation Working Group to nurture fledgling initiatives. "It usually starts with a university recognizing that its wants something it has developed to flourish," explains Susan Bramhall, a senior systems specialist at Yale University (CT) who heads the Incubation Working Group. "It realizes that the project requires more long-term resources to make it sustainable than are available at any one school."

An in-house scheduling assistant from Wisconsin is one of approximately 20 projects currently undergoing an incubation process. "Jasig provides the help to properly license your software, set up project governance and direction, and complete a well-rounded public profile," says Blair, who authored the original scheduling assistant. "It provides infrastructure like site hosting, e-mail lists, and a task tracker, but more than anything it's the talented and engaged individuals in the community that are able to help."

Eleven projects have "graduated" from the incubator and are now self-sustaining. A few others were shut down because they didn't gain traction. "The fact that some were terminated just validates the process," says Jasig's Gertz. "We apply our criteria and if long-term sustainability won't be there, we don't continue."

Revenue is generally not one of the criteria used to evaluate an open source project. Schools participating in the Kuali Ready project will pay Kuali an annual licensing fee of $8,000-$11,000, but that money does not come back to Berkeley.

"The potential for the university to make a fortune from this is zero," Waggener notes. "It is cost avoidance. It is reducing my risk. Of all the initiatives we have done at UC, this migration into a community source is the most cost-effective."

Generating Revenue
But generating revenue from homegrown products is possible, as several universities have proved. Purdue University (IN) is the leading exemplar of the trend, with CIO Gerry McCartney carrying the standard for a new approach focused on innovation. "If we are only consumers of products, we are in a weak, weak position," he said during a keynote speech at Campus Technology 2011. "For us, 'hybrid' surely must mean that somehow we figure out how to be producers of products. We need to explore, not only how to create products, but how to bring them to market."

The school has had success with its stated goal. Recently, Purdue signed a deal with SunGard Higher Education to commercialize its Signals student-retention product and is working on five more teaching and learning products (for more details, read "Taking Homegrown Products to Market").

The decision to partner with a company to commercialize a product is not to be taken lightly. Beyond the question of revenue sharing comes a whole raft of issues, including governance, development, marketing, sales, and liability. The Signals agreement, for example, places responsibility for software development, marketing, sales, and support with SunGard, while Purdue continues to contribute work on the underlying risk algorithm.

When pressed about how much revenue Purdue generates from the partnership, John Campbell, associate vice president for academic technologies, remains coy. "I would say that my motivation is to have ongoing funds to continue the innovation," he explains. "This in turn will benefit the teaching and research missions of the institution."

Purdue's current success in this area, however, is no guarantee that gold lies in them thar hills. Yale's Bramhall, for example, did not find advantage in pursuing the revenue route. "Prior to our days with open source software, we did disseminate some software for revenue," she recalls. "In my opinion, managing the distribution and income was as costly--but less beneficial than--the current gain from open source."

At the same time, it's important to realize that open source initiatives also come with their own management demands. Looking back over the first year of Kuali Ready development, Waggener says that the group should have hired a full-time communications person on the first day to answer questions, manage demand, and get the word out.

"The individual members are all answering questions, but it would increase efficiency if one person could answer the basic 80 percent of those questions," he says. "We have done no outreach. Community source has no marketing or sales team."