Piloting Open Source CMS - A Small Campus Experience

Some of us are blessed with the responsibility of helping our campus constituents select course management software. We gather the stakeholders, match lists of needs with possible solutions, figure out how to finance and support a solution, and then select from available options. Only the last of these steps is not internal to the institution. Our list of possible solutions includes CMS from commercial software vendors, and in fact most colleges operating a CMS have chosen to license commercial software. Typically, we've turned to commercial interests outside the academy for one of our most fundamental tools in support of teaching and learning.

We've been served well by this model for the past several years. A high percentage of our faculties have embraced their campus' CMS, and most students find them to be easy to use and effective. CMS have become one of the most successful enterprise applications in the academic arena. Many colleges and universities now consider the CMS a strategic element in campus IT.

In spite of this successful implementation history, recent trends have encouraged us to look beyond commercial offerings as Denison considers its next generation course management system. First, the pricing structure for the major commercial CMS products has changed and costs have risen. Some of this is justified; vendors must make a profit on product sales and support (although commercial support is worthy of much more scrutiny than can fit into this article). Further, commercial CMS providers must thrive to continue the expensive research and development required to meet our changing and more sophisticated needs.

Second our faculties have conquered the first and second generation CMS and they still need more- more features that are specific to their pedagogical approaches; greater flexibility; better assessment tools; CMS that keep pace with rapid advances in the disciplines; more interactive possibilities. They want more, more, more … and they are right to do so. Our single most successful enterprise-wide academic application should be extraordinary.

I am charged with the task of ensuring that Denison University has an extraordinary CMS and so I like having choices. To have choices, I need accurate information on which to distinguish among the choices. I want choices of software vendors and plenty of trusted information about what works and what d'esn't. First hand experience is an excellent method for gathering these data.

As a way of increasing our options, Denison University undertook a pilot program with Stanford's CourseWork system. We were looking for greater flexibility in a CMS and possibly lower, long-term costs. In the spring of 2003, faculty members in English, Political Science and Modern Languages taught courses using CourseWork. Some faculty members were experienced with Blackboard, while for others this was their first experience using a CMS.

Installation of CourseWork took about three weeks of effort by Denison's systems engineer, aided at times by our Oracle DBA (neither of whom had prior experience with Tomcat or the Java programming that underlie CourseWork). It took another two weeks of part-time effort to "brand" CourseWork by removing Stanford-specific links and expressions, some of which were cosmetic and some of which were functional (such as the embedded reference to Stanford's e-mail server). Most installation problems took a day to diagnose and resolve based on information gleaned from a listserv. System administration throughout the semester was primarily to assist students recover CourseWork passwords; we did not integrate CourseWork into our campus LDAP authentication scheme for this pilot.

From a support standpoint, the CourseWork pilot was easy. Faculty participants had one hour of instruction at the outset of the pilot, and we offered 30-minute in-class introductions to students. We responded to questions, but the support load was light. At the mid-point of the semester, we met with the faculty to review the pilot. This meeting led to a discussion of the future of CMS at Denison in very broad terms as our faculty colleagues imagined an a la carte approach for selecting information tools in support of specific class functions. In all, the pilot of actual, credit-bearing courses, involved six faculty members and 90 students.

Faculty reported that there was little difference between CourseWork and the market-leading, commercial CMS licensed by Denison in terms of pedagogical outcomes. Many of the challenges were not related to CourseWork, but to CMS use in general (e.g., the digitization of faculty's own discipline-specific materials; students' lack of fundamental technology skills). The separate portalization of each area of college life (classes, campus homepage, events) was seen as fragmenting the student experience, and one faculty member called for us to extend the CMS to an academic portal that more fully integrated Denison's institutional mission.

Managing Risk

Denison's ongoing efforts to pilot an open source CMS are about risk management. We are gathering information about how to balance the need for reliable and supportable systems with features that meet the faculty's and students' needs. Given our experience with the pace of feature development for commercial systems, the cost of support for commercial systems, and our success with carefully selected, widely-used open source solutions (such as Apache, uPortal, Linux and others), it is clear that a carefully selected open source strategy can be no more risky or less productive than a commercial solution.

In fact, we are looking forward to greater flexibility, more relevant pedagogical features and perhaps even lower costs in a future with open source products such as those from The Sakai Project. The Sakai Project is bringing together many of the best technical and pedagogical features of academic software developed at Stanford, Michigan, MIT, Indiana and the uPortal project. Sakai will create a pre-integrated collection of open source tools for course management, assessment, workflow, etc. within a portal framework.

Pilot Programs

In choosing a CMS for campus wide deployment, the key is having the most relevant information to select from among many options. The most comprehensive assessments of potential CMS are not just technical; they must involve our faculty and students in the context of teaching and learning in real courses. For instance, this semester several Ohio colleges and universities are running a follow-up pilot placing full courses within Stanford's CourseWork and Michigan's CourseTools.NG through a program sponsored by The Ohio Foundation of Independent Colleges supported by The Longsight Group (http://cms.ofic.org).

We cannot limit ourselves to that which is at hand. After all, teaching and learning are our core competencies. We should expect that course management systems created by higher education, for higher education, will be extraordinary. Based on campus needs and support infrastructure, both open source and commercially provided CMS should be candidates for campus adoption.

comments powered by Disqus

Campus Technology News

Sign up for our newsletter.

I agree to this site's Privacy Policy.