Course Management Systems >> It's the Support, Stupid!

• By Mikael Blaisdell
• 12/30/04

In the open source vs. commercial CMS debate, support turns out to be a deciding factor. Here’s why.

At the July Syllabus2004 conference in San Francisco, attendees took a day to head to the UC Berkeley campus where they absorbed session and keynote content, shared information with peers, and participated in vigorous panel discussions. One such discussion, “Is Open Source in Your CMS Future?” tackled the issues around open source course management (or learning management) systems, more commonly referred to as CMS or LMS. Most specifically, the discussion centered on Sakai (www.sakaiproject.org), the open source CMS software released in July 2004. The discussion, led by UC Berkeley’s director of Educational Technology Services, Victor Edmonds, employed the use of personal response software to poll session attendees as issues arose. Interestingly, the polling revealed that for session attendees, a primary concern about open source CMS was the ability to secure dependable support.

Edmonds counters, “It is true that the group identified support as their major concern about adopting Sakai. But I’d bet it would be a major concern if we asked about adopting WebCT (www.webct.com) or Blackboard (www.blackboard.com), too.” Given the consistent concern about support for campus systems in general, Edmonds may have a point. Still, while open source CMS proponents argue that support is likely to be superior for the more consortial systems, anxiety about support for those systems can’t be dismissed and may be a reason why some campus officials insist on a single CMS vendor which can be held contractually accountable for support.

The Argument for Single-Vendor CMS

When you come down to it, the questions are: D'es single-vendor CMS (proprietary CMS products such as WebCT or Blackboard) offer an inherent advantage in the areas of product and user support over the Sakai open source model? Or do the open accessibility of the product source code and the range of potential suppliers for Sakai support mean that open source CMS support actually has an edge over that of proprietary systems?

“Support is an issue for any software,” acknowledges Sebastian Rahtz, Information Manager for the UK’s Oxford University Computing Services. “But ‘support’ is a very broad area; it’s hard to answer for all of it at once.” Vis-à-vis the CMS support discussion, then, a framework needs to be established in the form of a workable definition regarding what is actually meant by CMS support.

Defining CMS Support

While some may disagree about the labels assigned to support categories (and the assignment of responsibility for specific components within the groups may vary), there is a surprising level of consensus about support components in general. Items such as implementation and customization of the software to fit local requirements, integration with other systems, migration of legacy data, documentation, user training, incident handling, diagnosis of bugs, and preparation of fixes in one way or another are all nearly universally understood to be included somewhere under the heading of support.

When it comes to the breakdown of CMS support components, however, Mara Hancock, UC Berkeley’s associate director of Learning Systems & Multimedia Services, divides CMS support into three general categories: Frontline customer support, technical support, and implementation support.

Support on the Frontline

“There is not much difference between vendor-supported and open-source-supported products at this level,” according to Hancock. In both cases, she points out, the same options are available. The scope of the frontline support group’s typical duties, she says, is to respond to immediate problems that prohibit someone from accessing or using the tool. “The issues could range from a lost password to how to perform a certain function with a given tool,” she explains. “These types of questions are rarely, if ever, escalated back to the vendor level.” And though frontline support usually refers to the common higher ed help desk, there’s nothing common about the intensity of help desk interactions, says Ann Watts, Instructional Design coordinator for Des Moines Area Community Colleges (DMACC) (IA).

Look at your help desk. “Until you’ve had to sit and listen to irate faculty members coming to you, you won’t really understand about support,” says Watts. Stress or no, there are two factors about support at this level that should be kept in mind in the proprietary/open source CMS support debate: 1) Frontline support is the last structure to be built for any new technology, and 2) the resources required for providing it are seldom, if ever, seriously taken into consideration in the product selection decision-making process. Yet because frontline support often interacts with larger numbers of individuals than other support structures on campus, you’ll want to look carefully at this support structure when you weigh the pros and cons of proprietary vs. open source support.

Training. Another familiar element of first-level support is user training, and there are a variety of sources for both trainers and course material. While proprietary CMS vendors offer training services on various levels (staff, faculty, and students), universities may opt to augment or replace some of these by developing their own training programs.

On all levels, however, training for Sakai is offered by the Sakai Commercial Affiliates (SCA), typically, for-profit partners which have committed to Sakai and which have full access to the source code of the product (as do Sakai users). Currently, four independent vendors are prepared to offer training and full support services for Sakai, and more are expected to sign up during the course of this year. Currently, the vendors are: rsmart group (www.rsmart.com), Embanet (www.embanet.com), SunGard (www.sungardsct.com), and Unicon Inc. (www.unicon.net.) In addition to the courses and training services offered by the SCAs, universities may elect to develop their own materials and courses, just as users of proprietary support services may do.

Build or contract? Regardless of whether a CMS product is proprietary or open source, a university will have the same basic options when it comes to addressing the need for first-level support and/or training for faculty, staff, or students. The institution may either build its own help desk and/or training programs using in-house resources, or it may contract with another organization (a vendor, in the case of proprietary systems, or an SCA, in the case of Sakai.) Or, it may use a blend of both approaches.

When Support Gets Technical

The next level of support deals with more technical issues and involves a different group of individuals. “I see CMS technical support as a bigger concern than the frontline support for many schools, especially smaller institutions,” Hancock explains. “These are areas where there are problems with the CMS application itself, the installation, or the database.” Pointing out that technical support issues are often dealt with in-house first (moved either from the frontline group or from system administrators to the developers), she notes: “This is where [some schools] worry that they won’t have the expertise necessary to identify and fix the problems, and that they won’t have the support structure in place to get the rapid response that these types of problems require. This concern may be real if they don’t have a technical staff.”

Money and source code limitations. Under the proprietary CMS model, the sole source of higher-level technical support is the vendor, usually under the terms of a contract between the supplier and the institution. Of course, “the rapidity of response from the vendor,” Hancock points out in this scenario, “depends on how much you paid them for the support.” One drawback of this model, for schools with access to technically knowledgeable and skilled resources, is that the in-house developers and systems administrators may be able to identify the problem and the appropriate correction, but may be unable to actually make the changes due to the lack of access to the proprietary code that would be required to implement the fix. The vendors of proprietary systems are seldom if ever willing to release any part of the source code to their customers, regardless of whatever expertise they may possess, because to do so would endanger their control of their intellectual property.

Implementation Support

Unlike common desktop horizontal software products such as word processors or spreadsheets that may be purchased by the user, downloaded from the Web, and completely installed by using a built-in software wizard utility on the spot, major campus systems like CMS require substantial installation design, preparation, implementation and integration services before they can be fully released for campus-wide use by the institution’s general community. Whether proprietary or open source, no CMS runs ‘out of the box.’ This aspect of support is a critically important factor, for the implementation and integration costs can be staggering, especially if proper preparation and design is not completed before beginning the process.

Proprietary vs. open source. Installation and implementation expenses for proprietary CMS systems are additional costs beyond the license fees for the software, notes Hancock, and “will require internal experts to collaborate with vendor consultants to make this successful.” What’s more, where integration with other applications is required, the institution can be compelled to hire two sets of consultants: the team responsible for implementing the new system, and a second team that is expert in the existing application.

On the other hand, “If you’ve got a staff that has development and integrations skills, Sakai will be very easy to work with to install and implement,” claims Brad Wheeler, Indiana University’s associate VP for Research & Academic Computing, and the Sakai Project Board’s vice chairman. Phil Long, senior strategist for MIT’s Academic Computing Practice, agrees that Sakai offers an advantage for those schools with the in-house resources to do their own integrations, and/or for the consultants retained to assist them. “You’ll be doing integration by looking at an API you can see the other side of, as opposed to wondering what on earth they were thinking of when they were writing it.”

What about institutions where the staff is not prepared to take on the systems integration role for Sakai? “If you run an organization with a very lean staff, and want to rent those services as needed,” Wheeler says, “then you’ll need to shop around among the SCAs to find someone who will do your integration and/or help desk services for you. The difference is that you have the options because of your greater access to the source code.”

Strategic CMS Support

Past the tactical levels of CMS support, however, there are some strategic factors that are also associated with the question of supportability. How viable will Sakai prove to be in the next few years? Can an open source product compete with the proprietary companies’ dedicated development groups?

Share, and share alike. “Building the community is the key,” according to Wheeler. “Within a very short time of Sakai’s release, one of the schools came back and said, ‘Here’s what you need to do to integrate it with MySQL.’ This is exactly what you get when you’re able to coordinate the energies of a number of participants in a project like this.”

Pick and choose. Echoing frequent comments in the Linux and other open source software communities, several of the Sakai adopters stressed that the access to the complete source code of the product meant that much more would be done in the area of product enhancement. “Instead of dealing with one company’s development team and their ideas of what is important, you have the ability to do your own enhancements to fit your needs, or to pick and choose from the things that the other schools are doing,” said one university CIO currently transitioning away from a proprietary CMS system. Commenting on the freedom that schools have in the Sakai community, Wheeler notes that while there is a grade book program specifically under development for Sakai, other schools or even private companies might decide to do their own. “I expect in time there will be two or three grade book programs that can fit into Sakai, so that an institution’s administrators can choose the one they like best.”

A Question of Certainty

For some, though, the key concerns about open source support seem to revolve around a need for certainty. DMACC’s Watts is concerned about what she sees as “volunteer” efforts for support in the open source Sakai model. “Sometimes you do feel a little at sea, because you don’t know who might be able to help, and you don’t have a single source that you can go to, to ask your questions.” This may be one reason why DMACC (a solid Microsoft client in other areas as well) chose the MS Sharepoint system for its CMS needs.

Control is all. Patricia McGhee, a member of the Instructional Technology group at the University of Texas at San Antonio, has a different view. When asked about the most significant support advantage offered by Sakai, she replies. “Control.” Scott Siddall, assistant provost for Instructional Resources at Denison University (OH), agrees. “We like to have choices,” he explains, then takes it a step further: “Often, in fact, almost all of the time, proprietary vendors provide inadequate support for their products.”

On his campus, Siddall isn’t concerned about the absence of a single-source CMS support provider. “Getting software and support from two different sources should not be construed as an obstacle,” he says. “Some of the best solutions come from the meritocracy formed online in the open source communities. More than half of the time, I get more relevant, successful, and timely diagnoses from these resources than I can from a commercial software vendor. We’re convinced that mission critical systems can be based on open source solutions.”

Source code is key. In fact, says Wheeler, the search for certainty is not limited to the open source model. “Under the traditional proprietary model,” he asks, “What is the core way to hedge against vendor risk? Escrow the source code! Well, that’s the very essence of the open source approach, that you have the source code.”

The Larger Issue

Underlying the entire CMS support debate is an emerging discussion about overall strategy. Many campus IT executives see this larger issue as key, and Stanford University Director of Academic Computing and Sakai Project Board Member Lois Brooks is one of them.

“The uncertainty we’re hearing about support is shorthand for the strategic re-evaluation that we are undergoing in our institutions,” she notes. “There is no one right strategy. School size, ability to attract IT staff, other investments, and individual institutional priorities all play in the decision-making process.”

Dollars and sense. Chris Coppola, President of Sakai Commercial Affiliate rsmart group also sees the debate in broad strategic terms. Under the proprietary model, he says, “So much money is being spent on the software that very little is left over for proper installation, customization to fit local business practices, training, other staff development, etc. In fact, a primary reason technology [in general] hasn’t had a larger positive impact on learning is because not enough money has been left for the activities that can really make a difference.” He adds, “A key part of the value proposition for open source CMS is that a higher proportion of each dollar spent g'es back to the institution for things that will have an impact on bottom-line results.” The debate is likely to continue for some time.