Development: From Users to Contributors

tracker

Last updated September 27, 2014.

The FLO CORAL Development Committee

As happy as FLO was with CORAL, there was still room for improvement in the software. There was also an opportunity to participate in open source system development and learn about the resources required to truly participate in Open Source Software. FLO had already been using open source software for a number of years, including Drupal for the content management system, SubjectsPlus for the library guides, IR+ as an institution repository system, and now CORAL, but all of our activities with these software packages were limited to downloading, installing, and implementing. FLO had yet to significantly engage and contribute to any of these open source communities.

It was with this idea of exploring the process of contributing in mind that a group of FLO’s dedicated CORAL users met in August 2013. The FLO CORAL Development Committee (FCDC) consisted of seven members from five of the FLO libraries and two members from the FLO office. In addition to the original seven members of the Electronic Resources Management Task Force, we were joined by Erin Wentz, Assistant Professor and Electronic Resources Librarian, Massachusetts College of Pharmacy and Health Sciences University (MCPHS) and Adam Shire, Member Services Librarian, FLO. The purpose of the committee was to create software specifications, a set of design and technical requirements for our proposed enhancement, and contributing code to the software base; our goal was to be contributing citizens of an open source community. Our plan was to:

  • Create a process within FLO enhancement candidate nomination and selections;
  • Select and contribute small enhancements: those that required only minor changes to the software code;
  • Select and write specification for a large enhancement with the idea of funding the code and database development that would provide a significant improvement or extension of the system functionality.

Enhancement Candidate Nomination and Selection

The first task on FCDC’s agenda was the nomination and selection of enhancement projects for development. There was an existing list of ideas for improvements to software that we had generated throughout the implementation process. In addition, we had noted a number of enhancement requests on the CORAL listserv. Some of these had not necessarily been posted as requests but instead as functional questions, such as “how are users tracking the cost history of a resource?” Using these questions, our existing list, as well as some new contributions, the team created a spreadsheet with the nominations, brief descriptions of the proposed functions and the affected modules. 

Once we had listed all of the possible candidates for enhancement, each team member independently rated the importance of the proposed enhancement on a scale of 1 to 5, with 5 being most important. We averaged the ratings so that each enhancement nomination received one score for importance. Based on the FLO system librarian’s knowledge of the code and database, the perceived difficulty of the enhancement was also rated. For instance, enhancements that only affected the display code were rated as easy or a “1”, while those requiring code changes to several pages as well as database modification were rated as hard or a “5”.

Next, we split the enhancement nominations into two groups: the small enhancements and the large enhancements. Small enhancements, those rated less than a 3 on perceived difficulty, were those that might require only a few lines of code in one module, such as making windows larger. Larger enhancements were defined as those that would take more coding and possibly involve more than one module, and received a rating of 4 or 5. The top five small enhancements were: enable wildcard searching in the “Funds” field; fix the Terms Tools bug so that linking works when related SFX public target names contain a space; change “Name” label; hyperlink the Login URL field; and make edit windows large. The most important large enhancement was the Cost History and Cost Reporting functionality.

Writing the Large Enhancement Specification

In November 2013, FCDC was ready to start building a specification document for the Cost History and Cost Reporting functions. Not only had FCDC rated this enhancement as its most important, it was also a recurring request on the CORAL listserv. In the production system, some cost history functionality was possible by co-opting another field and manipulating the input data, but that solution still did not provide a method for fully recording the cost history of a resource, nor did it provide a means for reporting on the history that was collected.

As a first step in the cost history enhancement project, Kelly Drake notified the CORAL Governance Committee via Benjamin Heet, Electronic Resources Librarian, North Carolina State University, of our plan to develop this aspect of the ERMS and inquired about the process for getting code included in the software. As mentioned previously, our intent was not only to improve functionality for our own use, but also to write code that could be contributed back to the CORAL community. The inquiry was well received, and in his reply, Ben confirmed that the cost history functionality was very much in demand. He also forwarded a copy of a Cost History Specification that had been written by Consortium Luxembourg, a group of libraries in Luxembourg who were actively using CORAL for their ERMS.

With encouragement from the Governance Committee, the requests from the listserv and the Consortium Luxembourg specification in mind, FCDC began the process of exploring and developing the specification. FLO reviewed Consortium Luxembourg’s draft and deemed most of it suitable for our needs. FLO simplified the pricing information in the data entry section and added fields to indicate how that price was generated. We wanted to track, for example, that the pricing of a resource in 2011 was based on the number of full-time equivalent chemistry students, but that in 2012, it was based on the number of full-time equivalent users in all departments. We also expanded the number of reports that could be generated using that data to improve collection development and budgetary decisions. In the four months between then and February 2014, we went through four iterative cycles of specification development and negotiations. Kelly Drake outlined various aspects of the functional requirements through emails, in-person discussion, or screen mockups, and the committee provided feedback, clarification, and alternative directions.

Finalizing the Specification with the Community and Governance Committee

By February 2014, we felt we had completed the Cost History and Cost Reporting Specification and were ready to show the CORAL Community and the Governance Committee. Because the proposed enhancement was very much in line with requests outlined on the listserv and by the Consortium Luxembourg specification, FCDC felt that the Specification would be well received. The document itself was 90% complete, leaving room for additional changes and minor revisions prior to finalization. FCDC submitted the Specification to both the Governance Committee and the CORAL community via the listserv on February 19, 2014.

Listserv members responded with almost immediate and positive feedback and acceptance.

The Governance Committee had a number of questions and suggestions. In the CORAL environment, it is the Governance Committee that is responsible for changes to the code base. As such, they are tasked with understanding how the system is used in order to ensure proposed code changes will be consistent with the current code and in the best interest of the community. The Governance Committee is also more aware of the interrelation of the different modules or functions of the software and can provide input on best practices.

Some of the members were concerned that some proposed changes would conflict aspects of the functionality that we weren’t aware of.  Subsequent to our proposed changes, one Committee member instituted a poll of the known users to determine the actual usage. Based upon that feedback, the FCDC suggestion was accepted. The Governance Committee also suggested that the proposed Reporting function could be combined with the Statistics module, a suggestion that FCDC readily agreed to. After reviewing the functionality and negotiating alternatives for three months from February to May, both FCDC and the Governance Committee felt the specification was complete.

Releasing the Request for Proposals

At this point in the FCDC process, we had completed our proposed goal of creating an enhancement specification. Once finalized, the software specification was posted to the larger CORAL community and other interested parties as a Request for Proposals. We hope to receive and review proposals, award a contract and begin the programming work shortly. When the programming is completed, we will share it with the CORAL community and begin testing and modifying as needed. We feel that we are well on our way to being proud contributing members of an open source community.