Get Engaged with Unconferences
Drupal Camp 2009 at Darien Library in Connecticut was my first “unconference.” This informal style of professional gathering, also called “Barcamp” (Library Camp, in libraryland), assumes two things: that everyone in attendance is an expert in one area or another, and that the group of people who show up are the right group of people to be there. There is usually a loose schedule for the day, and in the case of Drupal Camp, a general theme, but beyond facilities and general logistics and perhaps a keynote speaker or two, little else is planned. A successful unconference is predicated upon the presence of attendees who are willing to share what they know, but just as importantly, know what they don't know.
It was by far the most human conference I’d ever been to. Nearly all the people who presented brief "Lightning Talks" or breakout sessions were asked questions that they didn’t know the answer to, and in nearly all cases, another audience member had the answer. It was very gratifying to be in a room full of people who were openly supportive of each other, open to questions, open to making mistakes, open to learning and sharing, and champions of open source software in libraries. The "us" and "them" speaker/audience dichotomy simply did not exist. For me, the give-and-take is what is valuable here; I gleaned many more ideas and leads from this single day session than I've gotten out of the last several traditional conferences I've attended. More than that, I now have a list of people whom I can contact when I run into problems.
So, *can* library techies rock Drupal? Yes we can!
Fellow TS blogger Kate Sheehan wrote about the open source content management system Drupal in January, and quite a conversation ensued. Her post highlighted a letter written by Kyle Jones that appeared in the December 2008 issue of American Libraries, in which he raised the issue of learning curves with open source software, specifically that Drupal’s is very steep and probably beyond the average library techie’s reach. Kate’s post refuted Kyle’s position, and garnered several reader comments on both sides of the argument.
So, which side of the argument do I fall on, after attending Drupal Camp?
Drupal is hard. It has its own vocabulary. Its potential is so wide open that it is literally possible to do nearly anything with it, and while this idea is greatly liberating, it is also sort of paralyzing: Where do I start? What modules do I need? What can I DO with this thing?
But the way I see it, the fact that Drupal has a steep learning curve is no excuse for complacency.
If we want flexible, powerful websites that enable our library staff to create and publish content with a click, that enable our users to find materials, give us feedback on services, and create a sense of community inside and outside our buildings, then we have no excuse for ignoring resources like Drupal. Drupal can be used to create a library website; an electronic resources access and management system; an interface to the library catalog; a digital library; a photo gallery; an events calendar; a donation management system; a blog; or a conference registration system. Nearly anything you can imagine for your library website can be created with the Drupal framework; what’s more, it can be made to look exactly how you want it to look, without exception. The limit for most of us will be expertise--creating a Drupal site that looks and does exactly what you want won't happen straight out of the box. Setting up, configuring, and tinkering with Drupal can require real programming expertise and technical training, the kind that people with titles like "Systems Programmer/Analyst" have--something that this self-taught, humanities-degree-wielding library techie has skirted around for years but has managed to avoid--until now.
The fact that Drupal does have a steep learning curve does not put it out of libraries' reach, but it does underscore the need in libraries for appropriately-trained technical staff who are able to pick up programming languages and software with ease. I think that creating sites in Drupal to what Chris Harris called "Tier 2" in his comments on Kate's post is not beyond most library technical staff, but is probably beyond most librarians. However, any library that truly wants to master what Drupal has to offer needs to have or train technical staff with programming expertise, namely PHP. Also, libraries that want to own their own hardware rather than purchasing hosted web space somewhere will have to hire a systems administrator versed in their OS of choice and in network security, software versioning, backup procedures and PHP.
What did I learn? Or, Drupal for n00bs
After attending Drupal Camp and hearing others talk about how they created modules and sites, I'd recommend these steps to other newbies:
1. Get versed in basic operating system commands. While it's possible to run Drupal under Windows, Drupal affords an excellent opportunity to gain one's LINUX legs. Must-knows: how to create and move around in the directory structure and how to download, move, copy, unpack, and edit files.
2. Do your homework. If you're completely new to Drupal, start by reading Drupal in Libraries, an issue of Library Technology Reports written by Andy Austin and Christopher Harris. The Before You Get Started and Getting Started sections at Drupal.org are also useful, as is the libraries group. The Drupal core code and its thousands of contributed modules are available for download from the Drupal community site, where you'll also find documentation and discussion forums. Don't miss the Drupal4lib group (and list of library sites that use Drupal) and email list. There are a few free introductory videos from lynda.com as well. Know other resources for getting started? Please list them in the comments.
3. Get a cheap hosted site to play with. Even better: find a host who will do a basic Drupal install for you. LifeHacker recently posted a list of affordable and reliable hosts, and I would be remiss if I did not mention Blake Carver and his amazing company LIShost for the library set.
4. Get involved in the Drupal community. Get to know others in libraryland who use Drupal. Attend conference sessions and make connections. If Drupal Camp 2009 is to be taken as a good example, there are dozens of Drupal users in libraries around the world who are happy to share knowledge. Free unconferences like Drupal Camp lower the cost to participate. The travel budget at MPOW was slashed this year, but our leadership felt that Drupal Camp was a good investment.
- There is no single recipe for creating a Drupal website. There are many ways to accomplish what you want to do.
- The best way to learn Drupal is by doing.
- Permissions and taxonomies are hard to get right the first time.
- You will break stuff. By fixing broken stuff, you will learn.
Creating a website in Drupal does take an investment of time and learning, but Drupal is not beyond any library willing to invest in its staff or willing to spend the money to hire a professional company to create and maintain its Drupal structure. The advantages that content management systems like Drupal afford us are many: library staff are able to create and edit content, and patrons are able to contribute. CMSes give us control over our data and over its presentation to users, something that has rarely been true in libraryland. There are no license or maintenance fees with Drupal, and the open source model allows us to contribute our efforts back to the community, enriching all libraries as we go. There's no question that Drupal has a steep learning curve, or that it can be messy and complex to implement, but its potential is too great for libraries to ignore. There is also no question that we can do it.
Having only worked in medium-to-large academic libraries is coloring my perception here. If you're in a smaller library with little-to-no technical staff and a shrinking budget, how might you address the desire to implement Drupal?