Issue 47, 2020-02-17

Managing Electronic Resources Without Buying into the Library Vendor Singularity

Over the past decade, the library automation market has faced continuing consolidation. Many vendors in this space have pushed towards monolithic and expensive Library Services Platforms. Other vendors have taken “walled garden” approaches which force vendor lock-in due to lack of interoperability. For these reasons and others, many libraries have turned to open-source Integrated Library Systems (ILSes) such as Koha and Evergreen. These systems offer more flexibility and interoperability options, but tend to be developed with a focus on public libraries and legacy print resource functionality. They lack tools important to academic libraries such as knowledge bases, link resolvers, and electronic resource management systems (ERMs). Several open-source ERM options exist, including CORAL and FOLIO. This article analyzes the current state of these and other options for libraries considering supplementing their open-source ILS either alone, hosted or in a consortial environment.

by James Fournie


Library technology choices have been under a near-constant process of consolidation, resulting in less software choice for libraries. In a cursory review of Marshall Breeding’s annual Library Systems Report and Library Automation Marketplace reports dating back to 2002, “consolidation” is mentioned almost every year [1]. Many vendors including Polaris and Ex Libris were bought out or merged with other vendors. Consolidation occurs not only with vendors, but also products. In 2011, Marshall Breeding coined the term “Library Services Platform” (LSP) to refer to a new breed of library software which “may replace three or more incumbent systems, usually the integrated library system, the electronic resource management (ERM) system, and a link resolver and its knowledge base” [2]. Consequently, vendors have increasingly pushed libraries towards LSPs, deemphasizing or abandoning standalone options such as a traditional ERM. ProQuest describes its LSP Alma as “A Single Unified Solution, No Matter the Format” [3], implying no need for other software. Innovative Interfaces does not list any standalone ERM option as part of its Sierra software [4]. Through vendor and product consolidation, the options for electronic resource management systems have dwindled without investing in a full commercial LSP dwindled.

Managing electronic resources is possible without migrating to a monolithic commercial LSP. To avoid high costs and vendor lock-in, many libraries have already turned to open-source integrated library systems (ILSes) such as Koha and Evergreen, which allow more flexibility in options for vendor support and development. Likewise, there are great options for implementing electronic resource management without without relying on traditional commercial library software, and without even requiring an ILS migration. Today, three great options exist for adding electronic resource management functionality to existing architecture–the standalone open-source ERM CORAL, the open-source LSP FOLIO, or a homegrown option using non-library specific software. These options provide great alternatives to expensive and monolithic commercial software for managing electronic resources.


CORAL is a stable and mature open-source ERM. Like many early open-source ERM systems such as ERMes, Hermes, and CUFTS, CORAL was developed at a large academic research institution, Duke University. Initiated in 2008, CORAL was built on the popular PHP/MySQL platform. This platform is used by other long-lived open source software such as WordPress and Drupal, as well as open-source library software such as SubjectsPlus and VuFind. The longevity, stability, and ubiquity of this platform make CORAL very easy to deploy for even the smallest of libraries. CORAL has had 35 different contributors in the past 10 years, with 2,308 commits since 2010. Currently, only two committers have been responsible for the only 14 commits in the past year. While this is not exactly a high amount of development activity, CORAL remains very stable. The codebase which began in 2008 is showing its age. However, SirsiDynix, who use CORAL for their BlueCloud ERM system, recently commissioned a facelift to improve the look and feel. In addition, a developer from CalTech is currently working on refactoring the CORAL codebase to improve tests and refactor code to modern PHP techniques. CORAL’s development is coordinated by CORAL Steering Committee. Recently, CORAL joined the Open Library Foundation, which should help provide access to funding and contribute to the longevity and viability of the CORAL project. CORAL’s stability and code and project maturity make CORAL a great option for a small library to deploy and self-host.

CORAL also has a robust Organizations module for helping libraries manage any information about their vendors and consortia. The module allows one to create organizations and assign various contacts to the organization. These contacts can then be assigned various roles such as Sales or Tech Support. The module also allows storing vital login information for administrative URLs, or statistics portals. Often libraries find they are storing this info in multiple locations, and the information can get out of date, lost, or new staff can have difficulty finding it. CORAL’s Organization module helps provide a central storage depot and single source of truth for this information, reducing errors and helping libraries consolidate this information.

Additionally, CORAL’s Licensing module helps libraries maintain their licensing obligations. Resources licensed for use in a post-secondary institution might be used on or off campus, by students, alumni, faculty or support staff, and in different contexts such as coursepacks, interlibrary loan and the LMS. Keeping track of all potential uses allowed or disallowed in a license poses challenges on an individual resource, let alone many resources. CORAL’s Licensing module allows uploading licensing documents and interpreting those documents as a series of “Expressions” such as “Coursepack”, “eReserves”, “walk-in usage”, etc. These Expressions can be compared between different resources. The Terms Tool is a component of the Licensing module which works with the SFX link resolver to allow checking which resources are licensed under a specific Expression type. For example, you could query all resources which allow coursepack usage. The Licensing module also supports importing ONIX-PL data. The Licensing module helps a library maintain a database of information about resource licensing to ensure they are complying with their agreements.

CORAL can also help manage and maintain usage statistics for electronic resources. Often libraries make purchasing decisions based on eResource usage statistics, or must report this information to their institution, consortia, or trustees. The Usage module allows manual importing of COUNTER reports in XML format. At this time it only supports COUNTER v4 and not the new COUNTER v5 standard. Harvesters can be set up to harvest COUNTER data directly from SUSHI endpoints, eliminating the manual labour of downloading files and uploading them to CORAL. There are also nice features such as an area for storing login credentials and URLs for the vendor’s statistics portal, and a tool for identifying statistical outliers. While the general reporting features of CORAL are limited, the CORAL documentation recommends querying the MySQL directly for advanced reporting needs. These tools can smoothen a manual process of downloading reports for myriad sites and consolidating them into spreadsheets.

A major problem addressed by CORAL is the challenge of defining and maintaining a lifecycle for electronic resources. The heart of CORAL is the Resources module, which manages Resource acquisition and subscriptions. In addition to basic information such as renewal and cancellation dates and contact organizations, users can assign a resource to a “workflow”. A workflow is a series of steps that an electronic resource must pass through, such as “review content”, “import MARC record”, “licensing”, “add to proxy”, etc. At each step of the workflow, CORAL can notify via email the relevant group or individual such as the subject liaison, ERM coordinator, systems department or licensing specialist. The group then can take the appropriate action on the resource. Once completed, they can check off their action in CORAL, which notifies the next group in the sequence. Separate workflows can be defined depending on the type of resource (print/electronic, streaming, journals, etc.) or the acquisition type (trial, PDA, etc). Many libraries struggle in their acquisitions workflow, with items getting stalled with a person or department. The workflow may be a “killer feature” of CORAL, helping ensure resources transition smoothly through their lifecycle and no steps stall or are missed.


Unlike CORAL, FOLIO describes itself as an open-source LSP. However, FOLIO’s highly modular nature makes it unique when contrasted with other commercial LSPs. Commercial vendors have promoted the LSP as a replacement for traditional ILS, combing separate print and electronic workflows into an integrated workflow [5]. While FOLIO does share an integrated workflow approach, the FOLIO project also strives to be highly modular. Sites can deploy FOLIO partially, replacing ILS functionality, ERM functionality, or both. The FOLIO Implementation Group includes many sites deploying ERM-only, or “everything except ERM” implementations [6]. Most LSP vendors take an “all eggs in one basket” approach – migration is a big and costly endeavour, with huge impact on operations, as all workflows are touched and migrated to the LSP. FOLIO’s modular nature allows individual functions to be replaced one at a time, saving time and money in the process.

The modular nature of FOLIO as an LSP also gives it more breadth than CORAL. FOLIO has a Licensing module and eUsage module which are very similar to CORAL’s Licensing and Usage Statistic modules in functionality. However, one can also enable FOLIO’s Orders and Invoices modules and gain a full-fledged acquisitions functionality. These modules offer more features in terms of managing the financial side of eResource acquisition. The modules are currently focused on print and individual title acquisition, but development work is happening to more tightly integrate them with the Agreements module. The additional modules in FOLIO allow flexibility as to how many or how few of the ERM components you wish to utilize in your workflow.

The FOLIO Agreements module is the core FOLIO ERM component, similar to a CORAL Resource module, however its approach differs in several ways. Agreements consist of one or more packages, subscription information, and licenses. Unlike CORAL, FOLIO links packages to a knowledgebase. GoKB and EBSCO’s Holdings IQ are both supported as remote knowledge bases, or holdings can be uploaded manually to the “local knowledgebase” using the “Local KB Admin” tool, which can only ingest specially formatted JSON holdings data. The knowledgebase integration allows displaying title-level information in the Agreements interface, to help subject liaisons or other decision makers inspect the content of packages. However, FOLIO does not currently have as many workflow features as CORAL. The Agreement record acts like a giant collaborative document, and library staff must understand what information needs to be added or updated on an Agreement at any given time. Staff can be attached to an Agreement in various roles such as “subject liaison” or “electronic resources librarian”, and then query the Agreements module for all Agreements they are attached to, but it may not be clear what actions they need to take on the Agreement. There are no features yet in FOLIO for defining a specific workflow or sending email notifications. While some libraries may appreciate the knowledgebase integration in FOLIO and flexibility of the Agreements, others may prefer the more rigid workflow supported by CORAL.

FOLIO, as a platform, strives to be developer centric. FOLIO is built on a backend framework called Okapi. Okapi supports multiple tenants, meaning multiple libraries can share a FOLIO instance. Modules, once installed globally, can be enabled or disabled for individual sites depending on their needs. The backend modules are designed to be easy to develop, each requiring a JSON file describing API calls that the module provides. The backend modules are theoretically language-agnostic, but most of the existing backend modules are written in JVM-based languages such as Java and Groovy. The frontend code also features a modular system called Stripes. Stripes is written in JavaScript using Facebook’s popular React framework. Stripes features CLI tools that allow developers to quickly develop a frontend module that matches the look and feel of other FOLIO modules. The Stripes frontend and Okapi backend strive to make it easy for developers to develop modules for FOLIO.

FOLIO’s community is very large and active, but it’s not clear how much of this activity will persist once the project reaches maturity. At the time of writing there were 1123 users in the #general Slack channel. FOLIO has a number of working groups dedicated to different areas of library workflows. The “Resource Management” working group has 31 members listed on the wiki [7] and has an “ERM Sub-Group” with a similar number of members listed [8]. Each of the working groups for FOLIO is a cross section of skills, with product owners, domain experts from libraries, and UX people in addition to developers. Different developers are working on different components of FOLIO. Much of the ERM development is being conducted by a UK-based company, Knowledge Integration, commissioned by the GBV Common Library Network consortium in Germany [9]. Other major development is conducted by Index Data, commissioned by EBSCO. In addition, traditional commercial vendors such as SirsiDynix are involved, as well as open-source vendors such as ByWater. FOLIO is licensed under the MIT license, which doesn’t require any modifications to be open-sourced. All of these raise questions as to how the project will transition from an initial pool of funding, to community-driven and supported development.

FOLIO is generally intended for very large organizations or consortia, and as a result, is much more challenging to deploy than CORAL. An external assessment of FOLIO sponsored by EBSCO was conducted in February 2019 by a 3rd party company called Open Tech Strategies (OTS). The report found various bugs and security issues which were quickly addressed by FOLIO’s Technical Council [10]. In addition, the report found that FOLIO was very difficult to deploy and maintain. Some of these issues have been addressed by the Technical Council. While there is a great deal of developer documentation, end-user and even system administrator documentation is lacking or non-existent. Many essential system administration functions such as creating tenants and enabling modules require making manual REST requests to the API using a tool such as curl. FOLIO’s System Operations and Management Special Interest Group cited the current RAM requirements for a complete system at 32GB, most likely necessitating multiple servers or VMs, or a Kubernetes cluster simply to deploy a complete system [11]. This complexity makes FOLIO extremely difficult for a small or medium library to self-deploy and maintain. However, this complexity is also what allows FOLIO to offer modularity, flexibility and multitenancy features which make it excellent for a consortial environments with differing needs amongst member libraries.

The Anti-ERM

Many libraries have found that they can fulfill their ERM needs through non-specialized software rather than software such as FOLIO or CORAL specifically designed to manage electronic resources. Although the vision of LSPs is a “single unified solution, no matter the format”, there is evidence that these systems are falling short of this vision. A recent study found that “many Alma, Sierra, and WMS libraries are still performing core ERM tasks outside their systems” [12]. Many libraries still need other tools to manage their electronic resources. In 2011, Wilson provided an overview of three libraries using JIRA, Drupal, and Basecamp respectively [13]. Another review in 2016 by Minchew & Slutskaya discussed libraries using MS Access, Content Management Systems, and Trello for electronic resources management [14]. Several articles have also been written on Trello and Kanban in general as a solution for managing electronic resources, such those by Ostergaard [15], McLean & Canham [16], and Finch [17]. Other tools include help-desk tracking systems [18], Microsoft OneNote [19], and wikis [20]. Minchew & Slutskaya note that “there is no one application that can adequately support all of the tasks” associated with e-Resource management, and that “any such application would present a high barrier to entry for its users.” For organizations well in tune with their workflows, or those who prefer to emphasize people-based solution and simple tools, often electronic resources management can be addressed with non domain-specific software such as wikis or Kanban boards at little or no cost.


Libraries all have unique needs depending on library size, type of collection, and staffing. For many libraries, available tools, even if it’s only a spreadsheet or wiki, may be more than adequate for managing e-Resources. For libraries with heavier or more complex e-Resource workflow needs, an ERM solution may be warranted. CORAL is a mature and feature-rich option, with a useful workflow feature. It is particularly easy to deploy for libraries with the capacity to self-host a PHP/MySQL application. For those who can’t self-host, there are several vendors also providing CORAL-specific hosting and support. For libraries who are considering eventually migrating to an LSP, FOLIO’s modularity offers an easy transition path, with ERM as a gateway. FOLIO also offers advanced features such as knowledgebase integration. However, its complexity may provide significant challenges for hosting. Libraries working together in a consortium could share those costs and take advantage of multitenancy and modularity, which offer flexibility for diverse libraries sharing a single FOLIO instance. From a large consortium, to a library which self-hosts PHP applications, to a library with limited technical knowledge using tools-at-hand such as wikis, there is a free or open-source alternative for libraries to help wrangle their electronic resources.

About the Author

James Fournie is Coordinator of Library Systems and Technical Services at Vancouver Community College. He holds a Master of Library and Information Studies degree from McGill University. Prior to joining VCC, James worked as a QA Lead on a platform-as-a-service system at ActiveState Software, and as an Evergreen ILS developer at the BC Libraries Cooperative.


[1] Breeding, Marshall. (n.d.). Library Technology Reports. Retrieved from

[2] Breeding, Marshall. (2015). Library Services Platforms: A Maturing Genre of Products. Library Technology Reports, 51(4). Retrieved from

[3] ProQuest: Ex Libris Alma. (n.d.). Retrieved from

[4] Innovative: Sierra ILS. (n.d.). Retrieved from

[5] Breeding, Marshall. (2015). Library Services Platforms: A Maturing Genre of Products. Library Technology Reports, 51(4). Retrieved from

[6] FOLIO Implementation Group. (2019). Retrieved from

[7] FOLIO Resource Management Group. (2019). Retrieved from

[8] FOLIO ERM Sub-Group. (2019). Retrieved from

[9] FOLIO: celebrating success. (2019). Retrieved from

[10] FOLIO Project. (2019, Feb 19). OTS Project Health Report. Retrieved from:

[11] FOLIO System Operations and Management SIG. (2019, Feb 08) Meeting Agenda and Notes. Retrieved from:

[12] Singley, E. & Natches, J. (2017) Finding the gaps: A survey of electronic resource management in Alma, Sierra, and WMS, Journal of Electronic Resources Librarianship, 29(2), 71-83, DOI:

[13] Wilson, Karen. (2011). Beyond Library Software: New Tools for Electronic Resources Management, Serials Review, 37(4), 294-304, DOI:

[14] Minchew, T. & Slutskaya, S. (2016). The Path of Least Resistance: Using Available Tools to Support the E-Resources Lifecycle, The Serials Librarian, 70:1-4, 236-246, DOI:

[15] Ostergaard, Kirsten. (2016). Applying Kanban principles to electronic resource acquisitions with Trello, Journal of Electronic Resources Librarianship, 28:1, 48-52, DOI:

[16] McLean, J. & Canham, R. (2018). Managing the Electronic Resources Lifecycle with Kanban. Open Information Science, 2(1), pp. 34-43. DOI:

[17] Finch, M. (2014). Using Zapier with Trello for Electronic Resources Troubleshooting Workflow. Code4Lib Journal, 26. Retrieved from

[18] Arch, Xan & Price, Jason. (2009). Tracking Electronic Resource Acquisitions: Using a Helpdesk System to Succeed Where Your ERMS Failed. DOI:

[19] Browning, J. (2017). Title Lists, Tracking, and Tasks: Simplifying Electronic Resource Workflows with Microsoft OneNote, Journal of Electronic Resources Librarianship, 29:4, 264-268, DOI:

[20] Jackson, M., Blackburn, J. & McDonald, R. (2007). Media Wiki Open-Source Software As Infrastructure for Electronic Resources Outreach, The Reference Librarian, 48(1), 19-36, DOI:

Leave a Reply

ISSN 1940-5758