"In these tough economic times"-- as the contemporary cliche begins-- IT organizations at academic institutions have to make particularly difficult choices about how to support teaching and research. As far as I know, there is no institution in such dire straits that it can literally support only one tool, particularly if "tool" is defined so broadly as to include everything from learning management systems to OPACs, wikis to VREs, to course catalogs, to public-facing content management systems that drive the institution's websites. (I am excluding here infrastructure-ish things like authentication services, email, and purely administrative tools like financial systems. Websites can be administrative, but they can also be a method of dissemination for scholarship, and why have two web content management systems if you can help it?) Still, it's a reasonable thought experiment. If you had to pick just one what should it be?
I'd guess that many people would immediately jump to the learning management system. It's such an integral part of academic support, you might as well go without email. The firestorms we've had when our learning management system has gone down have been absolutely comparable to an email outage. But what sort of public-facing website can you get out of your learning management system? You might be able to pull off a tolerable course catalog, but you'd be facing a lot of furious librarians if you told them they had to somehow make a learning management system work as an OPAC.
The optimal tool to choose in such a dire situation should be immensely flexible. It should provide an intuitive interface for non-technical users to manage content. It should be relatively easy for non-programmers to build custom sites that meet most needs, but programmers should be able to dig into it to go beyond what can be done through the UI. If money is so tight, it should be free, and there should be a broad, active community providing support and building add-ons to expand what it can do; for this to happen, it would almost certainly have to be open source. It should be a tool already in use in higher education, where institutions are building add-ons to specifically meet the needs of their constituency. Ideally, there should be a company out there to provide enterprise-level support and possibly cloud hosting, and a variety of options available for training-- but all of these should be optional.
There is such a tool, and its name is Drupal.
Drupal for higher education
Need a learning management system? Penn State is developing one in Drupal. Got a lot of bibliographic records? There's a Drupal module for that-- and other modules to provide an OAI-PMH interface for those records. You can even import existing records from PubMed, BibTex, RIS, MARC, EndNote tagged and XML. Want to provide a wiki service, but don't want to support another platform? There's a Drupal installation profile for that. Want a platform for faculty to create a web presence for themselves or their projects? Harvard's OpenScholar uses Drupal for that. Blogging? Drupal does it out-of-the-box. E-portfolios? VRE's that are tailored exactly to fit a faculty member's project? An environment for collaborative essay writing? Beautiful, modern websites? Social and scholarly networking? It can be done in Drupal, using modules available on drupal.org, without necessarily having to write a line of custom PHP. The sorts of environments that would have required expensive "custom programming" projects and expertise beyond the means of institutions-- particularly small institutions-- can be built by people who feel ill when they look at angled brackets, without months of expensive training or years of experience.
One of the most remarkable things I've seen with sites based on Drupal is the impression it makes on faculty. The relationship between faculty and IT staff can be tense on both sides. In addition to an impression that IT staff don't understand where they're coming from (see some comments from Project Bamboo on that topic), faculty often react negatively to what they perceive as having their unique project or practice shoved uncomfortably into an ill-fitting box of the most reasonable service institutional IT supports. Want to have public and private data for your classes? Well, you can post the private data to Blackboard, and the public data to Wordpress. Don't like having it in two places? Tough.
But when a faculty member sits down to look at a Drupal site for the first time, and when they create a new piece of content, they see the form fields precisely labeled to accommodate the data they have, thanks to the CCK module or native fields in Drupal 7. The data they enter automatically sorts itself justs the way it needs to, thanks to the Views module. If there's new fields they think of on the spot, or new ways of organizing the data, the ed tech giving them a tour of the site can make changes right there on the spot. That custom feeling, that responsiveness, it accrues a lot of goodwill. Faculty are surprised that the answer is usually "yes" instead of "no", and the end product comes much closer to meeting-- or exceeding-- their specific desires than most other services on campus. And that's important, particularly when it comes to teaching and research projects. The interface for the email service we provide can be irksome, but it's not email that gets faculty out of bed in the morning, or keeps them working late into the night. It's the research and/or teaching (and, on the level of self-preservation and continued employment, the publications and/or course assessments that are the inevitable byproduct.) Responding to faculty members' passion for teaching and research by crafting solutions that fit those projects like a glove-- an attractive website that can disseminate the results of research and attract more funding, publicizing and archiving digitized materials, building an innovative on-line textbook with a mobile interface, solving someone's data management problem-- brings IT professionals closer to the desired "partner" relationship with faculty, instead of being those people who faculty yell at when something breaks, or get in the way when faculty want to do something that isn't supported by out-of-the-box services.
The beautiful thing is, from the distanced, abstracted perspective of academic IT staff, all of these "custom" solutions aren't actually custom systems at all. It's a single platform. Many add-on modules can be used on more than one of the Drupal sites you run; a number of essential ones will probably be installed on all the sites, and-- given a multi-site setup-- can be updated once for all the sites. You don't need to be a programmer to build even complex Drupal sites; ed techs, librarians, web developers, even student assistants can be taught to "think in Drupal", and apply those approaches to new and existing projects. You don't need to hire an all-new staff, and the work of supporting Drupal can be spread out across multiple groups. There'd be some management overhead, but there's some appeal to having a service whose "staff" draws on people from multiple areas, with different perspectives and expertise. (Got a project that needs someone to think through complex metadata? Send a librarian! Got a project that's more classroom-focused? Send an ed tech!)
For many of the academic support needs of higher education IT-- learning management software and OPACs come to mind specifically-- there are specialized platforms that meet users' needs out-of-the-box, and/or more precisely than a Drupal-constructed equivalent could do. If your institution has platforms in place that are meeting those needs well, by no means am I suggesting that they should be abandoned in favor of Drupal. Still, I think there's some comfort in knowing that if for some reason those systems become unsustainable, there's a non-absurd possibility of falling back on a flexible system you already support.
Nonetheless, getting institutional buy-in for Drupal isn't always easy. Here's some objections I've heard:
"It's really hard to learn"
I've never taken a course on Drupal, and I've been using it on-and-off since Drupal 4. That version was legitimately frustrating to use, but I figured it out without much difficulty. But I'm a techie at heart, and messing around with new tools is more play than work. When I want to expand my knowledge of Drupal, I find a new project that's a stretch, and figure it out. That being said, I recognize that most people don't work that way.
I think one of the biggest initial roadblocks for new users, which helps keep the "steep learning curve" truism alive, is that there's a certain amount of jargon you have to understand before you can make much progress with Drupal. I've written up a practical guide to Drupal jargon that I'd be happy to expand if there are other terms that need definitions. I'm also working on a series of pedagogical materials aimed at teaching non-programmers to think through how to approach faculty projects in a way that allows Drupal to make it easy, instead of overcomplicating things or doing them awkwardly, due to unfamiliarity with how Drupal does things. (As I finish them, I'll post them here too for anyone to use.) I'm also in the process of writing up exactly how I've implemented various sites, from the ground up, and all of these are examples from-- or applicable to-- academic contexts.
One of the best things about Drupal is how far you can go just by using the UI. (A consequence of this is that if you ask a programmer to look at the database of a Drupal 6 site, they may quickly become disgruntled, but I hear that things are cleaned up at least a little in Drupal 7.) Ed techs who would balk at angled brackets can independently set up even fairly complex sites with only a little FTP access to the filesystem required (for uploading modules); this, even, can be passed off to someone more comfortable with that sort of task.
From the user perspective, how easy it is to interact with the front end depends on how the site is set up, but anyone developing websites should ideally have some sense of best practices and expected behaviors (breadcrumbs, what clicking on the site logo should do, etc.) From the backend perspective of users who have to manage content, I've been pleasantly surprised at how easy it's been to explain to clients how to add and edit content, including uploading images and other media. On average, it takes me less than a half-hour of face-to-face time to get someone up and running-- and I get very few follow-up e-mails asking how to do things (though just enough of them to convince me clients aren't afraid of me or anything.)
"PHP is slow, messy spaghetti code that won't scale"
Yes, Drupal runs on PHP + MySQL (though you can use other databases, too). If you have to get the approval of someone with a passionate, unmovable hatred for PHP, I'm not sure what to tell you (besides perhaps sending them this flowchart, if it won't get you fired.) There's not much I can say about the nature of PHP, or the amount of sub-par code that's written in it, besides noting that the people behind Drupal core and the major modules-- by all appearances-- actually know what they're doing.
On the upside, if you're already running Moodle, you shouldn't have to have this argument. When it comes to questions of scalability, there's ways of dealing with both a lot of content and a lot of pageviews; check out some notes from presentations about The Economist moving to Drupal and performance and scalability.
"Maintaining multiple stand-alone sites is inefficient, but doing a multi-site install means that one site could bring down all of them"
I'll confess, at work I have a Drupal proliferation problem. It started when we ran our own VMs, and spinning up a new one was quick and easy. We started with one sandbox Drupal. Then another project came along that looked an awful lot like it should be done in Drupal. Suddenly, we had three (sandbox, then dev and prod for the project.) Two by two, our herd of Drupals grew, and at this point I couldn't tell you off the top of my head how many Drupals we have, between all the dev's and prod's of projects live, faltering, and abandoned. I want to consolidate them all as a multi-site install. But this is a mess of my own creation, a common tale of woe that derives from starting a "service" accidentally through a series of one-offs. Any institution that consciously chooses Drupal should think through how they're going to handle multiple sites from the beginning.
There's many ways of doing multi-site installs; ones where multiple distinct sites share the same database have probably the greatest risk of having one site take others down. (There's benefits, too, if you're running multiple sites that nonetheless share a non-trivial amount of content and users; if you're interested, check out Domain Access.) When I sit down to tackle converting my many Drupals into a multi-site, I'm thinking of going the shared code base, separate database route, which would allow me to update modules on all the sites at once, but would still keep the sites separate from one another. You still need a web server (or a cluster of them) that can handle a lot of traffic as browsers request the files stored there, and performance and scalability in general need to be addressed one way or another. While I haven't done much with them myself, I've heard good things about Drush and Aegir, though I've also heard the latter can be overkill, and its more practical aspects-- particularly in a hosting environment you don't have full control over-- may be better implemented through Drush scripts.
Drupal is worth it
For any system or software, there are challenges you have to work through. In addition to the issues addressed above, separating the content in the database from the site/module configuration (also in the database) has been a challenge-- though I have some hope for the Features module. I'm also not a huge fan of theming Drupal, but I've heard better reports from people with better CSS skills than I have. We're also currently (March 2011) in an awkward transitional phase for Drupal: Drupal 7 has been released, but many modules-- including ones that provide niche functionality that's essential for certain faculty projects-- don't have a Drupal 7 version yet. With the projects I'm starting now, I have no choice but to use Drupal 6, or else the end product will fall dramatically short of the faculty member's expectations. I can't forget, though, that going with Drupal 6 means I'll have to go through a frustrating upgrade process at some point in the future. That said, Drupal 7 has only been out for a few months, and hopefully within a year, niche module developers will catch up, or new modules with equivalent functionality will spring up for Drupal 7.
That said, other systems we run have their share of issues. Confluence updates have a way of ruining my weekend. Blackboard is sufficiently non-intuitive that we've got faculty looking high and low for a service that will let them post private files for class, never realizing that they could do it in the same place they enter their grades. For years, we only had a Horizon Information Portal interface for our library catalog, which I found so miserable to use that I nearly hugged the librarian who introduced me to the new AcquaBrowser Library interface.
Drupal is a content management system that could stand in for any of those in a pinch, and give faculty a "custom" environment tailored exactly to their teaching, research, archiving, publication, presentation, collaboration, and/or social networking project-- without the burden of supporting a lot of actually custom code, or having to hire new staff. Being able to say yes instead of no, and "that's easy, I can just take care of that now" instead of "we'll have to re-scope the project and look into staffing options, I'll get you a cost estimate later this week" goes a long way in building bridges between faculty and IT. Better, more flexible support for teaching and scholarship, plus stronger relationships with faculty: Drupal is worth it.
- Drupal.org: an overwhelming place to get started, but all the code and documentation you need is there-- Drupal core, modules, themes, everything.
- Drupal in Higher Education: a group on drupal.org dedicated to the topic.
- Acquia: the company started by Drupal's founder, Dries Buytaert, which provides paid services and support for Drupal.
- Lullabot: personally, watching training videos is my least favorite way to learn things, but Lullabot does Drupal training well. In addition to in-person training, they've got a subscription-based training video archive with a lot of great material. I went to their Do It With Drupal conference a few years back, and it was an invaluable experience.
- My assortment of Drupal materials: I'm reworking the content I've written on Drupal from blog posts into a dedicated area of this site. Much of it is about, or applicable to, Drupal in higher ed, but there's notes and site breakdowns that could also be used in other contexts.
- E-mail me (quinn [at] quinndombrowski [dot] com) or leave a comment if you've got questions or are looking for more information about getting started with Drupal. It's a favorite topic of mine.