Implementing Open-Source Software for Three Core Library Functions ...

Journal of Electronic Resources in Medical Libraries, 8(1):1–14, 2011 Copyright # Taylor & Francis Group, LLC ISSN: 1542-4065 print=1542-4073 online DOI: 10.1080/15424065.2011.551486

Implementing Open-Source Software for Three Core Library Functions: A Stage-byStage Comparison EMILY G. MORTON-OWENS and KAREN L. HANSON NYU Health Sciences Libraries, New York, New York, USA

IAN WALLS Water Solutions, Goleta, California, USA

An academic medical library developed new open-source systems for three of its core functions over an 18-month period. The authors compare and contrast their experiences working with Drupal, Koha, and Fedora repository in order to share discoveries about the open-source approach. The article compares the projects at different stages, such as requirements analysis, software selection, configuration, training, rollout, and maintenance. New York University Health Sciences Libraries’ (NYUHSL’s) results are not necessarily representative but show a range of possibilities to expect when experimenting with open-source software. The experience was positive and opens the possibility of further integrating the systems. KEYWORDS Drupal, Fedora repository, Koha, open-source software, project management

INTRODUCTION The New York University Health Sciences Libraries (NYUHSL) are a group of academic medical libraries serving the NYU School of Medicine, NYU Langone Medical Center, Bellevue Hospitals Center, and other affiliated sites. With a staff of 62 full-time employees, there were three systems librarians in 2009: a web services librarian, a digital projects librarian, and a Received September 24, 2010; revised November 10, 2010; accepted November 26, 2010. The article is based on a paper presented at the Annual Meeting of the Medical Library Association, Washington, D.C., May 2010. Address correspondence to Emily G. Morton-Owens, NYU Health Sciences Libraries, 550 First Avenue, New York, NY 10016. E-mail: [email protected] 1

2

E. G. Morton-Owens et al.

systems integration librarian (who left the library in early 2010). Each was the lead on one major open-source project: the web services librarian on the Drupal website, the systems integration librarian on the Koha ILS, and the digital projects librarian on the Fedora repository. The Drupal and Koha projects are live, while Fedora repository remains under development. In addition to the three librarians, all of whom have solid programming and database experience, NYUHSL’s information technology (IT) staff includes a Unix administrator, a web manager, and a full-time programmer. NYUHSL successfully runs its own servers rather than using institutional servers. In this paper, the authors consider the three projects in parallel, stageby-stage, even though the stages did not take place simultaneously during implementation. The goal is to reveal common experiences of working with open-source software to other libraries that may consider implementing it.

OPEN-SOURCE SOFTWARE Many people think of open-source software as software they can download for free. Although this is often true, it is not the most salient feature of open-source software. Consider a piece of non-open-source software: Microsoft Word. A user does not have access to the source code that is used to build Microsoft Word. Thus, even if a user has a pressing need to modify a feature in Microsoft Word, he cannot change that feature and rebuild the software into his own version, much less share his version with anyone else. Open-source software makes the source code available to users and allows them to make changes to it. Furthermore, it encourages developers to make the revised version of the source code available to other people. The result is that open-source projects often involve a large number of contributors (thousands, in the case of Drupal), working together on source code that is available to anyone. Under these circumstances, it would obviously be difficult to charge for the finished product. The fact that open-source software is free grows out of the way it is developed, rather than being part of its definition. There exist many companies that make money from open-source software by offering configuration, customization, and support services.

MOTIVATION AND REQUIREMENTS ANALYSIS Drupal NYUHSL’s websites had not been redesigned since 2002. Although the sites were not broken per se, there were many opportunities for communication and efficiency that were being lost. The library also wanted to simplify its web services by offering one website to serve five library locations instead of having five websites. It seemed obvious that the library needed a content

Implementing Open-Source Software

3

management system (CMS). A CMS would make the site more dynamic, allowing global changes and automatic, rule-based display of content. A particular problem with the old site was the difficulty of finding and removing outdated content. A CMS would make it easier to control the inventory of information on the site by date, author, or topic; the librarian could easily display the site’s pages ordered by date to identify potentially stale content, to give a simple example. The library also needed a system that would allow more users, including non-IT staff, to contribute content. If the site were to be complete and informative, it needed to have content from across the library. It was no longer practical for a single person, the web services librarian, to know everything that was going on and create all the content. Finally, the library required a system that was inexpensive or free. It was clear that an open-source web-administered CMS would be the best fit. Most CMSs that are not open source are quite costly, so free was more realistic than inexpensive. Choosing a system that was web-based would make it possible for all staff to participate without having to buy licenses for desktop software.

Koha Like the library’s websites, the online public access catalog (OPAC) had not been updated in many years. Configuring the library’s integrated library system (ILS) to work with other systems such as websites, an open link resolver, the library’s electronic resources database, and people management systems had proven difficult, requiring many ad hoc practices and scripts. The need for a new ILS came to a head when, due to changes in the institutional network security policy, the library’s proprietary ILS vendor was no longer able to access the server for maintenance and upgrades. The medical center’s IT department required the use of one kind of virtual private network (VPN) client, while the vendor would only use a different kind of VPN client. As negotiations dragged on for nearly seven months and no service or support was possible, the ILS fell into disrepair. An open-source ILS would not only prove easier to integrate with other services but also empower the library’s IT staff to provide service, support, and upgrades to the system without having to deal with external network connectivity issues. As with the website, an open-source ILS would be much less expensive than any proprietary option and could be entirely web-based, obviating the previous need to install and maintain desktop clients.

Fedora The new ILS and CMS arose from a need to modernize and improve existing library systems. The digital archive system, by contrast, emerged from two newly recognized and growing needs.

4

E. G. Morton-Owens et al.

First, NYUHSL needs to manage digital collections consistently. The library had carried out multiple small digitization projects, but management was uneven, standards varied, documentation was patchy, there was no solid plan for future maintenance, and no way to search across all digital holdings simultaneously. Second, the library has a responsibility to manage and preserve some born-digital files. Computer files are prone to corruption or accidental deletion, and some file formats and methods of storage may become unsupported as technology evolves. It has become vital to create a space where these digital files can begin to be managed in a digital extension of the traditional archive function. The new system would not be a freestanding project with a beginning and an end; it would become enmeshed in the library’s (and ultimately the institution’s) core functions, as one of its ongoing services. Workflows and processes for the new system were required, as well as standards for metadata and quality and a plan for ongoing maintenance and support. Although NYUHSL’s technical team is large for a medical library, it is small compared to many other institutions that have implemented a local repository system. Assessing the sustainability of the project was therefore a vital requirement. The repository was a major commitment, and preservation of the material needed to be considered in advance. The metadata and digital objects would be created not only by the library but also contributed from outside of the library—the material could not be ingested and then neglected. Before Fedora was selected, the School of Medicine’s Division of Educational Informatics (DEI) had expressed an interest in the repository to archive their online curriculum material. As a result, they became collaborators in the project. This was a welcome contribution; DEI administers the school’s course management tool, Sakai, which like Fedora is Java-based and open source. They also employ several developers and an application architect. This provided extra reassurance that the system could be supported sustainably.

Discussion In all cases, NYUHSL had business reasons to rethink or create the systems. Because the motivations for changing these systems revolved around taking control of, and responsibility for, the library’s own data and customizing the software for specific uses, open-source software was an obvious option to pursue. The fact that librarians wanted to experiment with software that was free nevertheless was important because the low cost made it relatively easy to persuade library leadership to green light an open-source approach to these necessary projects.

Implementing Open-Source Software

5

SOFTWARE SELECTION Drupal The web services librarian, working with the web manager, considered three CMSs: Plone, Joomla, and Drupal. They created a list of requirements, such as a WYSIWYG (what you see is what you get) editor and theming capabilities. They decided not to make a decision based on a raw count of how many points were matched, since it was impossible to rank the importance of the requirements exactly. Each of the three systems was tested in a sandbox and the two web professionals also took time to look at user reviews and support forums. In short, Joomla was found to be relatively unfriendly for users on the back end (a group that would come to include all librarians, not just IT staff) in terms of its terminology and layout. It did not seem as extensible as the other systems. Based on a requirements analysis alone, Plone and Drupal were more or less equal. Plone was pleasant to work with and very polished, but based on Python, a language not used elsewhere in the library systems. Also, Plone had a smaller following in the library community and appeared to have fewer developers and users than Joomla or Drupal outside the library world as well. Drupal ultimately emerged as the frontrunner for institutional as well as technical reasons. Drupal uses PHP, with which the NYUHSL developers were comfortable. NYU Langone Medical Center, one of NYUHSL’s parent institutions, had just chosen to redesign all its sites in Drupal. This meant a team of developers to consult with, right on campus. (The library runs its own server and sites but meets with the medical center’s team regularly.) There is an active and friendly group of Drupal users in New York City that runs semiannual Drupal Camps, monthly meet-ups, and an active online group. Furthermore, Drupal was rapidly becoming known in the literature as the CMS of choice for libraries. In choosing Drupal, NYUHSL had a lot of company—and company turns out to be a crucial form of support when working with open source.

Koha The selection process for the new ILS was simple. The library needed circulation, cataloging, acquisitions, serials, and reporting features in order to maintain its basic operations. It sought a software package with a large enough community of users surrounding it that the risk of it disappearing or otherwise becoming unsupported was minimal. Only two ILSs were sufficiently popular to be considered: Evergreen and Koha. At the time of selection, only Koha had the necessary acquisitions functionality. Both Koha and Evergreen are written primarily in Perl, a language with which the library IT staff was familiar. Koha is based on MySQL, another

6

E. G. Morton-Owens et al.

familiar platform, whereas Evergreen is based on PostgreSQL, a database system the library had not used before. The combination of functionality, comfort with the source code, and a strong supporting community made Koha the best choice.

Fedora There are numerous open-source options for digital archive systems, each with different strengths (e.g., DSpace, EPrints, Greenstone, Fedora). A look at possible use cases for the system showed a growing and diverse list of collections needing storage, management, and controlled access, from patient handouts to electronic theses and dissertations to scientific datasets. Flexibility and extensibility were key requirements, especially in terms of being able to control workflows, define appropriate metadata, adapt to changes in technology, and extend the system into new paradigms as needed. Having a single point of web access to all shared files in the digital archive is important, but in recognition of the fact that many collections have unique strengths and use cases, it is also desirable to support customized access points for some collections. Therefore, the system could not only be an amorphous mass of digital objects tightly bound to a single web interface, but rather there should be support for a series of dynamic, customized web front ends that can move swiftly with Internet trends while maintaining a stable back end that allows for consistent management of the digital objects. Using open-source software seemed the best way to ensure flexibility and that plans to integrate the repository with the website, ILS, and future systems were not constrained by licenses or limited features. The selected software had to be reasonably well established, with good documentation and a strong community of developers and users that were invested in ensuring the survival and progress of the system. In its role as the preservation system and to fulfill the criteria of having multiple access points, the digital archive needed to ensure that the digital objects and metadata were easily separated from the software without loss of metadata or damage to the object. DSpace and Fedora were both considered, but Fedora was the better fit. As a more out-of-the box system, DSpace would have been easier to implement but with less flexibility because it comes with a fixed web front end and set of workflows. Fedora has a web tool for administrators but is not packaged with a front end for public use. It has several APIs that make it possible for tech savvy users to create their own websites. The Fedora community has also created a range of possible web-based solutions, a few of which allow users to create multiple instances to run from the same Fedora install. Fedora also offers a ‘‘rebuild utility’’ that can completely recreate the repository by crawling the XML source files if the software fails.1 Fedora would be NYUHSL’s first Java-based system. NYUHSL’s technical team was

Implementing Open-Source Software

7

comfortable with managing the development of the web front end and with performing the majority of the configuration, much of which involves editing XML files. It was at this point that the collaboration with DEI was particularly helpful—they could contribute their experience with Java applications and their expertise in system architecture. Fedora’s features best fit NYUHSL’s requirements for metadata, adaptability, and security.

Discussion There were viable open-source software packages to choose from in all three of these functional areas: website, ILS, and repository. The software was evaluated point-by-point to see whether it matched the library’s requirements; in the case of the website, where the available software had similar features, the packages were tested in a sandbox to gauge the intangibles. It is also important to assess the strength of the community behind the software, looking for a group that is active, large enough to sustain itself, and has some kind of leadership or direction. NYUHSL’s work with open-source gained momentum over time. Once the library got started with open-source software, librarians gained confidence, and it made sense to use it more to enhance future integration opportunities.

CONFIGURATION Drupal Before starting the redesign of the main NYUHSL website, the web services librarian and web manager undertook a pilot project: the conversion of static web pages for NYUHSL’s three consumer health locations into small but dynamic websites. The several months spent on these sites gave the team confidence in their choice of Drupal and some experience configuring the system. Development of the main NYUHSL site involved not simply converting the older, static website into Drupal but actually rethinking all of the content and presentation and merging five sites into one.2 One result of this decision was that almost no content was moved verbatim from the old site to the new, and no content was ported automatically. There were many challenges in translating design ideas into Drupal. Drupal uses a system of modules that add functionality to the system; the modules are distinct from the core Drupal package. For example, if a developer wants to display a calendar of events on the home page, she could choose from several modules that offer calendar features. For the NYUHSL website, the developers often auditioned several similar modules on a test site to see which was most usable, feature-rich, and stable. Other ways to judge the health of a module are to see how many sites are using it (a metric

8

E. G. Morton-Owens et al.

offered on the module’s home page) and to check whether the maintainer of the module is responsive to questions and bug reports. The modules are not developed by a single company or person; anyone can contribute a module to the project provided they follow rules about how the modules must interact. Thousands are available though conflicts, bugs, and confusion inevitably arise. As one adds modules to a Drupal system to achieve the desired functionality, one’s system begins to differ from other people’s Drupal systems. A site’s set of modules may be unique, resulting in unique problems. This can make it very challenging to diagnose and fix problems in a Drupal system as one builds it up. There are many people in the Drupal community who are willing to help with problems, but it takes time to learn how to articulate issues in ‘‘Drupalese’’ and condense a problem to the relevant details. Important sources of guidance are the DRUPAL4LIB listserv, whose subscribers are mainly library web developers; the issues queue of the module suspected to cause the problem; and acquaintances made in the Drupal community. Some of the obvious places to look for assistance, like the Drupal IRC channel and the main Drupal forum, are too crowded and broad in topic to offer valuable help with troubleshooting. Luckily, once the major development phase was over, modules that cooperated during development continued to work together without problems. On the whole, choosing modules and ensuring they interoperate properly was a major part of the project. Other major parts of configuration included creating an editorial workflow,3 designing a visual theme, and custom-coding certain features such as a way to remind authors to periodically check and update their pages. The web services librarian and web manager wrote a custom theme using CSS. The programmer used PHP to modify some contributed modules to meet NYUHSL’s requirements better and wrote custom PHP pages to interact with databases outside Drupal. It is possible to build a Drupal site without CSS and PHP knowledge because contributed themes and modules are available. NYUHSL’s project, however, required more customization.

Koha The library’s previous ILS had been in operation for more than 14 years. In that time, the library had added new branch locations, moved collections, and come to serve new kinds of users. The codes governing item types and locations, as well as user types, needed to be revisited, and an ILS migration was an excellent opportunity to do so. In particular, the location codes in the previous ILS had been used to store information not only about where an item was within a particular branch library but also what kind of item it was and how it circulated. In Koha, that information is stored in separate fields, so in the data processing stage of the migration the systems integration librarian, with the guidance of

Implementing Open-Source Software

9

the Koha implementation team, mapped the location codes into four distinct Koha codes. It was decided that only active users would be migrated between systems, meaning anyone who was created or active in the last two years or owed the library money or an item. Users meeting those criteria were then bounced off one of the medical center’s people management systems to obtain current contact and status information. The migration was also an opportunity to synchronize circulation rules across all the library’s branches and locations. With the remapped item type and location information, as well as updated users and user categories, the circulation team was able to update the circulation rules in Koha as well as the policies behind those rules, leading to a more uniform circulation experience across all branches.

Fedora Fedora’s flexibility translates into a need for heavy local configuration, which is challenging without vendor support. Much time is spent consulting the documentation, tracking down examples, and troubleshooting errors. Users and developers can also find support in the Fedora community listservs and on the wiki. With no prepackaged public-facing web front end and no fixed workflows, the library must either develop its own or choose from a selection of components and web front ends created by Fedora’s community of users. Most Fedora repository systems are built up, in part, by plugging other open-source tools into Fedora’s core system, for example, Lucene’s GSearch. Having multiple small components makes the system as a whole more agile and persistent in the long term since it is not dependent on one piece. If any of the peripheral components stop being supported, it is not devastating, and if new components emerge with better functionality, it is plausible to switch them without affecting the core system. The library looked at both Islandora and Muradora as possible web front-end solutions for Fedora. The installation instructions for each system describe the stack of tools that must be installed and configured to work with Fedora in order for the front end to function optimally. This removes the burden of some of the decision making in terms of what combination of components to use. Macquarie University’s Muradora system has a lot of built-in functionality, workflows, and standards for handling basic types of digital objects, as well as support for adapting metadata standards to local requirements. One of Muradora’s key features is its highly granular security component. On further investigation, however, it turned out that major development of Muradora had temporarily slowed and its security component was added to Fedora’s core installation in the latest version.

10

E. G. Morton-Owens et al.

Although Muradora was a viable option, it was determined that the University of Prince Edward Island’s Islandora software was a better match for the institution’s infrastructure and requirements. The Islandora project is well supported and has a growing community of users. It has the advantage of being a Drupal module, which opens up possibilities for integration with the library’s websites and ensures there will be internal staff capable of further developing the repository’s public interfaces. Islandora also supports using multiple Drupal sites to access a single Fedora installation, which is in line with NYUHSL’s requirements. In other words, selecting Islandora provides many out-of-the box advantages while also allowing the library to maintain Fedora’s flexibility.

Discussion Open-source software generally offers myriad options, which translates directly into a significant time investment in configuration—it comes down to decision making and testing. Difficulties can arise during configuration, and there is no vendor support line to call. Instead, the user community offers support and advice, once the team figures out where to look for help. Some requirements may not be achievable with current settings or modules, in which case the team may need to write custom code. Sometimes the decision making revolves around choosing modules; systems that allow this help streamline the live system by only using the minimum modules needed. It was not surprising that all three of NYUHSL’s projects also involved technical and policy challenges unrelated to open source.

TRAINING Drupal There were four major parts of the training effort for the new Drupal website. Because there were no vendor training materials, all presentations had to be developed from scratch. Although Drupal has extensive documentation on its website, this documentation is about how to set up Drupal, not how to use NYUHSL’s configuration of it. The documentation on the library’s wiki also had to be written from scratch. Training was important to this project because staff, especially branch managers and faculty librarians, were being asked to take on a more independent role in creating website content, something that was feasible for the first time with this open-source CMS. First, the web services librarian made several presentations for staff about the development of the new site as it was still going on. The goal was to introduce the idea of a CMS. Second, when the beta version of the site was ready, there was front-end training for all staff. The goal in these sessions was to make sure that staff knew how to find the most important pages and

Implementing Open-Source Software

11

resources on the site. Third, librarians and branch managers were trained on using the back end of the system to log in and post news, create research guides, and so forth. This training was required before staff were given permission to post to the system but was also intended to get people excited about the possibility of communicating directly with users. Finally, training was also offered to users at the reference desk and in the form of half-hour sessions similar to the front-end training for staff.

Koha Training for Koha was purchased from a support vendor, ByWater Solutions. This training included three days of on-site training, broken down by module. All staff members who would be interacting with a module were required to attend the relevant training sessions. The systems integration librarian received printed training materials, which were posted to the library’s wiki. As staff members used the system, they came across specific questions that had not been addressed in training, or were part of sessions they had forgotten. The systems integration librarian followed up on a one-on-one basis with anyone requiring assistance.

Discussion All three of these systems require broad staff participation, especially the ILS. Training and documentation are an important part of the success of the project when relying on staff who may not be technically savvy and may forget what they learn in training. Open-source software is often customized by each institution in a unique way. Consequently, training also must be unique and local in many cases. Libraries should account for spending time to create training and documentation when planning open-source projects or else plan to pay for consulting.

ROLLOUT The redesigned website was available to preview starting in June 2009 and replaced the old site on July 14, 2009. It can be found at . The new OPAC was released on September 1, 2009, at . Plans are being made to roll the repository out in stages, starting with smaller, well-defined collections.

MAINTENANCE Drupal Drupal has had 10 minor version updates (6.9 to 6.19 as of September 21, 2010) and numerous module updates since the site went live. (The site uses

12

E. G. Morton-Owens et al.

48 contributed modules as of September 21, 2010.) There have also been several modifications to the visual theme of the site. In making these upgrades and changes, Drupal’s modular design is indispensable. Drupal abstracts different aspects of the software from one another, so that the core software, the visual theme, and the modules that customize the functionality are all separate. The content is stored separately in a database. Changes to one aspect do not affect the others, which makes updates safe. It is possible to make a change to the theme by changing one file and having that design change applied across all the site’s pages. The team usually waits either for an update to Drupal core or for a number of module updates to accumulate before applying them. Initially, the web team did upgrades manually, which involves backing up the site, turning off modules and themes, running update scripts, and finally restoring settings to their original state. This could be done in 10–20 minutes of downtime, usually first thing in the morning. More recently, the team has used Drush, a command-line module, to apply updates much more quickly. Either way, the updates are designed so that they do not disturb NYUHSL’s visual and functional customizations.

Koha The global Koha project is managed by a distributed version control system called Git. Git allows users to download a complete history of all changes to a project, track and publish changes, and integrate changes from any other repository in the world. Multiple versions of the code can be tracked and linked to common ancestors, allowing developers to easily synchronize with the global project regardless of how long they have been working on their own. The best practice would be to maintain a test Koha system that runs directly off of Git, allowing the local IT staff to test and track customizations and bug fixes more easily. When new code is ready to be released for staff use, the production version could be upgraded from the Git repository. Koha will automatically detect any changes made to the underlying database structure and prompt the production database to upgrade itself to match the new scheme through a simple, three-step web interface. As of September 2010, NYUHSL is running the version 3.0x of Koha without regular updates while waiting for the next major release (3.2).

Discussion Drupal and Koha offer similar systems to allow adopters to upgrade the core software without disturbing local customizations. Drupal’s system is somewhat more abstracted than Koha’s because Drupal can be used for any kind of website whereas Koha is specifically an ILS—thus, Drupal’s designers

Implementing Open-Source Software

13

anticipate a greater level of variation between implementations. Routine upgrades to both systems are usually easy, but of course there is always the potential for something to go wrong, and NYUHSL prepares for that by always maintaining recent backups that can be restored easily.

CONCLUSION The adoption of open-source software involves risks. Many institutions are attracted to open-source software because it is free, but it requires a significant investment of staff time and expertise, which can rightly be viewed as an expense. It can be difficult to schedule open-source implementations because each institution is unique and is not benefiting from a vendor’s experience in scheduling and troubleshooting. Issues may arise that take more time to resolve than expected. Open-source projects, in NYUHSL’s experience, were more manageable when the project did not face a hard deadline. In a smaller institution, there is also the risk of concentrating knowledge about the system with one employee. When the systems integration librarian left NYUHSL in winter 2010, there were rocky moments with the ILS as other staff got up to speed. It is initially liberating not to have a vendor saying that certain features or configurations are not possible. The downside of this, however, is that library staff may spend time on attempted configurations that are not worthwhile. For example, the web team built a way for librarians to create subject guides in Drupal that were connected to NYUHSL’s existing database of electronic resources. The result works but is clumsy and not very usable for librarians. Further, it has come to light that its design is probably incompatible with the upcoming Drupal version (7), which means that it may need to be completely reworked after less than two years. Librarians can learn from missteps like these. Open-source software requires librarians and developers to exercise judgment and cultivate expertise. The rewards of using open-source software are important. NYUHSL’s librarians can now develop more projects faster. The library now has seven live Drupal sites; the web services librarian has much more time for new projects as opposed to website maintenance because other librarians are more involved in creating and maintaining content that is relevant to their roles. Also, some libraries may prefer the idea of investing in their own staff’s expertise rather than in outside software. Perhaps most importantly, the library makes fewer apologies for what its systems cannot do. Librarians are no longer in the position of telling users that vendors do not offer certain features; they can consider feature requests based on merit and feasibility, rather than just saying, ‘‘It doesn’t do that.’’ These systems better represent the library because if someone has a new idea or there is a shift in how things are done, NYUHSL can respond.

14

E. G. Morton-Owens et al.

Although NYUHSL’s experiences cannot predict how other health sciences libraries will fare with open-source implementations, the authors hope that this comparison shows a range of possibilities of what to expect. The experience of working with open-source software has been positive and opens the possibility of future integrations between the systems that might be difficult or impossible with proprietary=licensed software. NYUHSL will continue to invest in open-source software, and its librarians and staff continue to grow more involved in the open-source community.

ABOUT THE AUTHORS Emily G. Morton-Owens, MSLIS ([email protected]) is Assistant Curator, Web Services Librarian, NYU Health Sciences Libraries, 550 First Avenue, New York, NY 10016. Karen L. Hanson, MLIS (karen. [email protected]) is Digital Projects Librarian, NYU Health Sciences Libraries, 550 First Avenue, New York, NY 10016. Ian Walls, MLIS, MSCS ([email protected]) is Lead Development Specialist, ByWater Solutions, 787 Laurel Walk, Goleta, CA 93117.

REFERENCES 1. Fedora Server Command-Line Utilities. Available: . Accessed: September 2, 2010. 2. Molanphy, Emily O., and Evjy, Christopher J. ‘‘Pursuing Unity: Combining Five Library Websites into One.’’ Poster placed online from Medical Library Association Annual Meeting, Washington, DC, May 2010. Available: . Accessed: September 2, 2010. 3. Morton-Owens, Emily G. ‘‘Editorial and Technological Workflow Tools for a Busy Website.’’ Presented at the Library Information Technology Association Forum, Atlanta, GA, October 2010.