D-Lib Magazine
July/August 2017
Volume 23, Number 7/8
Table of Contents
The Best Tool for the Job: Revisiting an Open Source Library Project
David J. Williams and Kushal Hada
Queens College Libraries, CUNY, Queens, New York
{david.williams, kushal.hada} [at] qc.cuny.edu
https://doi.org/10.1045/july2017-williams
Abstract
Sometimes the best tool for the job isn't the newest. It can be an existing tool that only requires a bit of polishing. This case study describes how a new digital services librarian, using a systematic approach, worked with colleagues to inaugurate a technology program within an academic library. In the process a previously-established open source web application was revived, extending its utility to contemporary development platforms. At the Queens College Libraries, an open source room reservation and scheduling system provided an answer to two important questions, and a means for building a new program.
Keywords: Open Source Library Project, Room Reservation and Scheduling System, Queens College Libraries
1 Introduction
The Queens College Libraries were recently afforded the opportunity to create several faculty lines, and a Web and Digital Services Librarian was included among them. As a new position, considerable assessment and planning was required from the successful candidate. But in a climate of budget cuts and fiscal austerity the challenge is often to do less with more, in terms of both technical and human resources.
Concurrently, the college's Benjamin S. Rosenthal Library was awarded a grant for a series of renovations, covering structural and cosmetic improvements over a twenty year period. The first phase of the project introduced new group study spaces, complete with video conferencing and real-time online collaboration technologies. With the arrival of these facilities the department found itself in a position familiar to many academic libraries: needing better tools to manage both new and existing services.
Our initial review of the libraries' web resources revealed many high-priority projects, most of which could be fulfilled using web applications. The availability of open source web development platforms had already popularized browser-based tools, and the time for including them among our candidate systems had arrived. Our first step required meeting with representatives of the college's Office of Information Technology (OIT) to discuss hosting options. As an office responsible for maintaining the campus networking and telecommunications utilities, however, OIT was not prepared to support academic technology. In response, dedicated hosting administered by the libraries' new Office of Web & Digital Services was established, and all existing materials were transferred to these new testing and production environments. Simultaneously, a Content Strategy committee (consisting of domain specialists from the libraries' Public Services offices) was convened to prepare for the next iteration of our online resources.
2 Evaluating an Inaugural Project
Having acquired the necessary technical infrastructure, the next step required bringing a technician on board. Unfortunately, the libraries' Systems Office had elected to concentrate on desktop support after transferring responsibility for catalog and ILS management to the university's central Office of Library Services. So the ideal Web Services candidate would need a background in DevOps, software development coupled with information technology operations, to manage the platforms while customizing and building the systems they provide.
Once the technician was in place we needed to identify an initial project. Our proposal was expected to deliver a highly in-demand resource while simultaneously demonstrating the value of committing to internally-managed library technologies. Consulting with the libraries' Resources Development Committee (RDC), we identified scheduling systems as the best option. With the new Group Study rooms near completion, a means for facilitating their management would more than satisfy our project criteria.
An initial report was prepared, outlining the requirements any application had to satisfy. After narrowing down the possibilities a group of five were compared:
- LibCal, part of the Springshare suite of LibApps hosted library web applications
- Google Calendar, available through the college's Google Apps for Education subscription
- Skedda, a proprietary cloud-based scheduler designed for small businesses
- OpenRoom, an open source application developed by Ball State University Libraries
- MRBS, the "Meeting Room Booking System" and a precursor to OpenRoom
(At the time these tools were evaluated, the RoomMe system from West Virginia University Libraries was still in an early development stage and unavailable for inclusion.)
From an administrative perspective, the system needed to record the following information:
- Requesting party's affiliation (faculty or student);
- room or resource requested;
- available hours;
- minimum and maximum number of students per resource;
- minimum and maximum increments of time per reservation;
- date, start time, and end time.
Perhaps the most important specification was that it be limited to members of the Queens College research community; only active students and faculty are permitted to make reservations. With that technical consideration in mind, any application selected had to support LDAP, the Lightweight Directory Access Protocol, for integration into the college's Active Directory environment. Managing multiple passwords is a common challenge where library resources are concerned, and a safe and secure method for reusing existing credentials would obviate this issue while satisfying the elicited access restriction requirements.
After consideration, testing, and the recommendation of colleagues at Baruch College (who had previously implemented the application as their library's computer resources scheduler), the RDC elected to further explore OpenRoom.
3 Developing a Prototype
OpenRoom was initially developed by the Ball State University Libraries Systems staff to address a problem almost identical to our own: the limitations of their earlier "analog" approach to scheduling [1]. From a technical standpoint OpenRoom was the best option, not only in terms of satisfying our requirements but also due to the availability of the underlying source code. Room requests could be largely automated, and customized reporting would contribute directly to ongoing service assessment.
Upon installing the application, multiple issues were identified that had to be addressed before a functional prototype could be implemented. Some were minor, such as a small tweak to internal mail function calls, but others were more substantial. Chief among these was the deprecation of the original functions provided for interacting with the MySQL Relational Database Management System, as resolved in 2013 with the release of PHP version 5.5. Version 7.0 saw these interfaces removed entirely.
For our preliminary tests it was necessary to build these APIs from source code using the PHP-dev development libraries, but in the long run this would be unsustainable; the code was no longer officially supported, and lacked the features necessary for accessing the full functionality of current MySQL versions [2]. More significantly, it introduced numerous security vulnerabilities. Our hosting arrangement required using contemporary operating system distributions, in large part to satisfy the University's security policies.
The database access functions needed replacement, and the available options were the ext/mysqli (MySQL "improved") or PDO_MYSQL PHP Data Objects interfaces. We selected PDO, due to its improved performance, active development, and support for native prepared statements covering sql protection. A comparison between database queries issued in the OpenRoom "/admin/administrators.php" component illustrates the difference (Figure 1).
Figure 1: Comparison of interface calls in "admin/administrators.php"
Using the mysql interface's mysql_query function call, $admina = mysql_query("SELECT * FROM administrators;"); produces a list of accounts with administrative-level access. However, the same query passed in Object-Oriented form appears as $administrators = model\Administrator::all();. The Administrator class all() method isolates the component file from database access details. The changes introduced by our new version resulted in a safer, currently supported application.
4 Migrating to a New Repository
Upon completing our modifications we wanted to submit them to the original upstream developers. Although OpenRoom continues to be downloaded from its original SourceForge.net repository, active development ceased two years ago following the upload of several bug fixes. The last new version was released in 2012 as 1-4.1. We contacted Ball State University Libraries' Library and Information Technology Services office, along with Brad Faust and Robert Seaton, the original developer of the application, to see if they would review and merge our updated code.
Robert graciously responded to our introductions and offer, informing us that his stewardship of OpenRoom was halted many years ago. He had since moved on to a different position in the University, and the Ball State University Libraries IT staff was now working on other projects. Under the circumstances he offered to "hand over the reins," as long as the original license was preserved.
His proposal offered the perfect justification for launching a GitHub repository within the Queens College Libraries team account. GitHub has the advantage of distributed development and version control, while providing simple documentation tools in a complete code-sharing social network [3]. After cleaning up our new code base we launched a repository for the new version 1-5 (Figure 2). It is our hope that this new environment continues to provide access to the application while encouraging participation and contribution.
Figure 2: The OpenRoom GitHub Repository
5 Conclusion
With the addition of a custom theme matching the libraries' website design (Figure 3), a workshop was put together to unveil OpenRoom 1-5 to representatives of the department's Access Services office. Plans are in place for rolling out an instance during the upcoming summer break, and the college's Music Library expressed interest in using OpenRoom for managing their listening facilities.
Figure 3: OpenRoom Interface at QC
Moving forward, there are many potential areas of improvement within the OpenRoom code, enhanced security and interface improvements chief among them. One of the many benefits of having access to the source is Linus's Law, as described by Eric S. Raymond in The Cathedral & the Bazaar: "given enough eyeballs, all bugs are shallow." Hopefully the continuing interest in the application combined with a new home on GitHub will attract more "eyeballs," and introduce a steady stream of improvements and enhancements.
Beyond the actual benefit of providing an online reservation and scheduling system, OpenRoom created the perfect opportunity for launching a program of digital services within the Queens College Libraries. It continues to be a practical, lightweight, self-hosted, single-purpose application, and we invite all members of the library technology community to participate in its development by visiting https://github.com/Queens-College-Libraries/openroom.
References
About the Authors
David J. Williams is Web & Digital Services Librarian for the Queens College Libraries, CUNY, Queens, New York. Previously he served as Library Website Manager for the Borough of Manhattan Community College, CUNY, New York, New York.
Kushal Hada is Web & Digital Services Technician for the Queens College Libraries, CUNY, Queens, New York. Previously he was STEM Projects Developer for Minot State University, North Dakota.