We are two weeks away from an annual techie migration called DrupalCon. This year it takes place in my town, Boston, so I am especially interested. I am also pleased that we’re garnering some local bragging rights once registration leapt passed last year’s Barcelona DrupalCon weeks ago and may even max out very soon. If you are interested in Open Source Content Management Systems (CMS), and haven’t yet registered, let me suggest that you think seriously about attending.
DrupalCon is a conference for people using a CMS called Drupal. It’s one among several popular contenders, both open source and commercial. For the purposes of my organization, it happens to be the tool that seems like a best fit for what we do and what we need. Given the confusion between content management, digital asset management, and digital preservation, it’s probably appropriate to step back a bit to describe what a CMS does, what problems we are solving by using one, and why this particular one meets our needs.
Content Management Systems are the management tool for websites. A good CMS provides tools for setting up pages and displays, for editing editorial content, and for providing common tools such as a spam-protected contact form, calendars, blogs, newsfeeds, and the like. Being able to arrange how these things appear on the web, and to manage them globally makes change simpler. It eliminates some types of coding problems (such as the way hand-crafted webpages tend to each be just a bit different) and makes website reorganization and redesign much simpler. Better, it makes gradual change on a website simpler, so that the people who know your site can learn new ways of interacting with the site gradually. In our case, we are moving from 10 years of accumulated static HTML (about 2500 pages of exhibits, features, and informational pages) into Drupal. We also have some significant database-backed sections of our website, and those won’t immediately change, although we will gradually find ways to create one datastore—ultimately not Drupal, but a digital repository.
Our website is how the public interacts with our organization. In our case, as a digital-only archive, it is the only interface, and is especially important. As I wrote in the opener to this article, there are a plethora of CMS’s. We’re an archive, not a development house. We want our resources spent primarily on archiving, not on developing and maintaining a website, so using software where someone else (or a whole community of someone elses) has done the heavy lifting is important. We wanted something written in a popular, open source language (PHP, in this case, but we also considered Plone, written in Python). We wanted something written in a language for which we can readily find affordable developers because we are a small non-profit, and don’t want to put any more scarce resources into web development than needs be the case. We wanted an open source CMS because we’ve been through the “try to convince a commercial vendor to develop the features we want” route and found it iffy, expensive, and fragile. We’ve also been through the “we’ll just build it from scratch ourselves” route, and found that even more iffy, expensive, and fragile. In an uncertain world, having an accessible codebase (open source) and a slew of developers familiar with the product (in the case of open source CMS’s that mostly means Drupal, Joomla, and Plone) and developing it further, is as much insurance as we can afford.
Non-profits that aren’t museums, archives, libraries, or other institutions with huge digital repositories often find a CMS all that they need for effective communication with the online public. We’re an archive. It was important for us to realize that having nifty tools to manage web displays is not the same as managing our digital assets. There are a host of issues, starting with tracking provenance and permissions and maintaining archival versions of files that are inappropriate for the web (tiff or jpeg2000 vs. jpeg; .avi vs mp3 or mpeg)—issues that are the province of a digital asset management system (DAMS), and managing those issues for the long term (digital preservation)—that are not even considered in the average CMS. We think of Drupal as our core tool for getting the word out. But it’s not our core archival tool. In the coming weeks, I’ll talk about what we’re doing with Drupal that we couldn’t do with earlier systems, and I’ll also talk about digital archiving, and our steps towards setting up a DAMS and a full-fledged digital preservation system, on the cheap, taking affordable baby steps at a time.
But in the meantime, if you’re already using Drupal, or if you want to meet people interesting in using it, from pre-beginners thinking about the subject, to core developers, come to Boston and check out DrupalCon. Even if you are using a different CMS, or aren’t sure why your organization needs one to begin with, DrupalCon is the place to get a sense of how people are using CMS’s; how they see them as tools, and what they’re doing with them. It’s a very exciting time to be considering this subject. See you there.
