CMS as an Alternative to Inertia

I recently posed a question to some library colleagues asking them who was still using listservs and for what purposes. The question wasn't intended to disparage the listserv as a communication tool, but rather to get to the bottom of whether or not listservs are still a useful tool. With the advent of technologies like RSS, it would seem that the usefulness of listservs had run its course and we could now move on to more efficient means of communication. Still, a surprising number of respondents said that they and their colleagues were still using listservs -- primarily because of the inertia. So a clunky means of sharing information that clogs inboxes and demands active (and often quite involved) user management strategies remains heavily used despite a number of ways that can more efficiently manage exponentially larger amounts of information.

I see similarities in how we approach the construction and maintenance of library websites. Why do we still have web development teams that are responsible not only for the creation of a site and new pages, but also the editing of pre-existing pages that may number in the thousands for larger library systems? How can we expect our overworked web dev teams to keep up with the growing demands to make our library websites more accurately reflect the way our users seek, retrieve, and create information online? We can point to inertia as one of the main reasons some libraries are still building and maintaining their sites by hand -- despite, like our listserv example -- the fact that we have CMS tools to help us with the heavy lifting.

So I read "Untangling a Tangled Web" with great interest. The authors cite "the need to make maintenance quicker and easier, as well as a need to position the web site for future development and expansion" as two challenges driving a shift toward implementing a CMS -- worthwhile goals that would inevitably need to be measured against the challenges inherent in a major overhaul of Wheaton College Library's website.

The case study affords readers the chance to take a peek (albeit an edited and distilled peek) into the processes involved in the decision. What we see documented here is a fairly typical process -- review, testing, review, testing, implementation, testing, troubleshooting, the dreaded upgrade, and more troubleshooting. The authors identify speed bumps along what, in comparison to what might have gone wrong, seemed relatively manageable -- if tedious and frustrating. If that sounds flippant, it's because I think we need to allow for all kinds of obstacles and tedium in our planning. The authors affirm as much in suggesting that they should have "expected the unexpected" in the "What Could Have Been Done Differently" section. Most of the other comments refer to needing to tap into the user community, ensure clear communication, and (again) anticipating a steep learning curve.

While the narrative approach here is useful, it might also be interesting to see a graphical representation of the planning process that compares the initial timelines with the actual timelines. For example, I'm curious about how the review process got backed up and how far that backed Wheaton up to the launch of the new upgrade. It seems to me that if the time between the implementation and the rollout of the upgrade/overhaul, it might have made more sense to wait it out and work with the new version exclusively.

This running theme -- plan for a shitstorm -- might be the singlemost important reason for libraries to consider and choose open source options when exploring CMS options. There will inevitably be hiccups in any technology transition, but the ability to weather those storms (and prevent future ones for others) is exponentially better in the open source community. With the advent of so many smaller operations offering support for open source software and the right community of practice using a given system, old arguments based on the technical support for proprietary solutions hold less weight than they used to.