• Thousands involved in creation of each Drupal release
• Modules increase flexibility
• Drupal 7 to lower barrier to entry

Drupal is on a lot of librarian’s minds recently as a prime content management system candidate, especially in the wake of the New York Public Library’s recent Drupal debut. Alex Bronstein, a Software Architect at the web-development company CraftySpace, knows Drupal better than most. In addition to his work on library sites, Bronstein is also a developer of the Drupal Core, the essential components and modules of this open source content management system (CMS). In a recent interview, he was able to shed some light on the software design process, and his involvement with development of version 7. (For examples of vanguard uses of Drupal in libraries, see Drupal Done Right, from the November 15, 2009 issue of LJ.) How did you become involved with Drupal and Drupal in libraries? I was working as freelancer helping organizations implement solutions to manage their web sites. At the time there were no good cost-effective solutions for many customers. Most commercial solutions were too expensive. As a result, the solution was typically to write a custom content management solution. However, 2004 I was asked to implement a custom CMS that was able to work with Drupal's discussion boards. I looked at Drupal (then version 4.6) and was impressed with its CMS framework because of its extensibility, which I thought had lots of potential. As a result I started using Drupal to manage web sites. I joined with some other freelance developers to form CraftySpace. Over time we  also began to work with more and more libraries. The result was YourLibrarySite [CraftySpace's library business]. How does the Drupal core get developed? Drupal development is divided into major releases: 5.x, 6.x, 7.x and minor releases: 6.1, 6.2 etc. Within Drupal there is no backward compatibility between major versions, and only the two most recent versions are supported. However, there is an upgrade path between versions. A third version is always in development. The advantage of this structure is that it helps Drupal innovate relatively quickly. Minor releases are only meant to fix critical bugs and security vulnerabilities. These are fully backward compatible. Typically, it takes two years to develop a new version of Drupal. During the first year and a half the code is said to be “thawed” and everything is on the table. This is the time to innovate, suggest new features and functionality, and restructure how the system works. The code is then "frozen" during the last six months, although often this happens in stages until all the code for version is frozen. The purpose of freezing the code is to shift the focus of development from innovating and creating new things to getting the release cleaned up, stable and ready to be released. Typically there is an alpha release, beta release, and release candidate(s) before the actual release. Who works on it? Many people participate in the creation of a new version of Drupal. Drupal is a self-organizing community without formal project management. There are two core maintainers who can "commit" changes. One of these two maintainers is the project lead who empowers the community to participate in discussions about the next version. This happens in the issue queue, groups.drupal.org, IRC, and other venues. It take community energy to move things forward in the development process. The project lead takes all the community feedback into account when making decisions. In addition to the two core maintainers, there are  many people working on the next Drupal release. For Drupal 7, the version currently in development, nearly or maybe even over 1000 people have contributed to the core project in some way, and another several thousand will contribute via add-on modules once the core is stable. Some people contribute by writing and reviewing code. Some people test the in-progress version to identify problems that need to be fixed prior to release. Some people provide ideas for improving the user interface. Some people create documentation. Some people help translate all of the screen text into other languages, allowing Drupal to be used in nearly any country. And there are lots of other ways in which to contribute. All of these are important to a successful release. What do you see as Drupal's strengths for libraries? Drupal has lots of strengths. The framework is highly extensible, which makes it very flexible. The community and development process foster an environment which is innovative. In addition, Drupal has the redundancy of many people working on the same problem from different perspectives. This fosters a diversity of ideas and, as a result, innovation. The Drupal community is also very active and engaged. It is always learning from its mistakes and trying to make things better. One example of this is Drupal profiles, which are meant to make it easier for people to get up and running with Drupal by packaging up modules, themes and configuration settings together. The problem has been that these haven't taken off yet because they are difficult to make and maintain. So one of the goals in Drupal 7 is to have install profiles be easier to make, contribute and share. Hopefully there will one day be an installation profile or several different ones for library web sites. What's important for someone just beginning to look into Drupal to be aware of? Modules, modules, modules! When you download the core Drupal installation, it includes some of the most essential tools for building a simple web site. But by itself, it's really not enough to build what most libraries would want in their web site. I've known some IT directors who have spent half an hour evaluating what can be done with a core Drupal installation, and dismissed Drupal as not a viable option because of how limited that core installation is. But there are 5000 additional modules that can be downloaded from drupal.org. No one needs all of them, but some very impressive web sites have been built with 20-100 carefully chosen modules. Determining which modules to use from the 5000 available can be daunting to someone just starting out with Drupal. Fortunately, in addition to being a piece of software, Drupal is also a community of people who are very generous in sharing their knowledge and experience. An excellent way to plug into this community is through a regional-based or topic-of-interest-based group on groups.drupal.org. I highly recommend that anyone interested in Drupal for Libraries join the groups.drupal.org/libraries group. What Drupal modules do you think are "must haves"? If you want to see what modules are the most used within the Drupal community you should check out the Drupal Project by Usage page. The top ten modules are a good starting point. In addition, most content creators appreciate a WYSIWYG [What You See Is What You Get] editor. There are several solutions out there but I'd take a look at the WYSIWYG module, which actually allows you to choose from several different editor interfaces. For complex layouts I'd reccomend looking at the Panel module which is good for sophisticated site builders.  In terms of theming, I'd recommend using Zen as a basis for creating a subtheme. Two useful module which CraftySpace has developed are Flexifield, which allows you to build compound repeatable fields, and Promos, which provides a convenient UI for managing small bits of content that can appear on a single page or be re-used across multiple pages. I also recommend that libraries keep the open-source SOPAC on their radar [see LJ’s write-up of SOPAC 2.0—Ed.]. The part of the suite that provides the web interface is a Drupal module, and this allows the interface to be customized and well integrated into a Drupal-based web site. It's currently in use at Darien Library, Ann Arbor District Library, and Palos Verdes Library District. What are the new features to look forward to in Drupal 7? Drupal 7 is much more usable out of the box than previous versions of Drupal. One of the biggest goals with Drupal 7 was to lower the barrier for getting started. The community wanted to make the system easier to use; as a result, there has been lots of usability testing done. There are improved contextual links and a better workflow for content editors. The result is an interface in which it's easier to go where you want to and do what you need to. Another big improvement to version 7 is the addition of Testbot, which is an automated testing system to see if a patch breaks something. This will make it easier for developers to fix bugs in a timely fashion. Additionally, there have been improvements to theming and rendering, which will give module developers more control over the screen and allow them to build better interfaces in less time.

---

Karen Coombs (librarywebchic@gmail.com)  is the recently appointed product manager for the OCLC Developer Network, having previously worked at the University of Houston Libraries, TX, and LIShost. She is a 2009 LJ Mover & Shaker