Implications of the transition towards library services platforms
What is a Library Services Platform?
Library services platforms or LSPs for short represent the current iteration of library management software. These platforms are distributed systems by nature and leave the trodden path of monolithic products by providing APIs for customized application development, which is by itself a considerable improvement in comparison to the rather limited possibilities that traditional integrated library systems (ILS) provide. LSPs are able to achieve this by implementing a couple of architectural changes to the underlying system, which will be discussed in a dedicated section.
To grasp what makes an LSP different from an ILS, it is useful to think about how ILSs emerged. Integrated library systems arose from a scattered variety of software solutions for specific tasks that were consolidated into integrated systems, hence the name that combined the functionality in a more streamlined experience, revolving around centralized databases (Breeding, 2015).
LSPs could be described as a software suite with an ILS at its core, that revisits the concept of standalone software solutions targeting specific use cases but differs by now providing a platform on which these applications are able to communicate and profit from shared resources, as well as integrating with the underlying core. This may sound a lot like the concept of an ILS but is very different in nature. Where the ILS strove for consolidation, the LSP tries to enable expandability. The caveat here is that the individual components of the LSP are not necessarily part of one retail package that institutions are able to purchase, but rather appear as a broad catalogue of specialized solutions, even by different competitors, due to the expandable nature, which is the result of standardized APIs and interoperable standards (Breeding, 2015).
Inevitable Issues
Chad (2016) critizises that these claims are exaggerated, at least based on personal observation. He states that there “…remains a very significant lack of interoperability between the various components that make up the library technology ‘ecosystem’.”, which is the result of a lack of foresight on the vendor side, especially regarding anticipating their own future products. Already existing solutions that are widely used may not support the integration into new LSPs because the software was not laid out with API integration in mind. This leads to a widespread issue called vendor lock-in. Vendors that create tools that are already on the market may only support integration with their own LSP or might charge a surplus for the usage of third-party components (Chad, 2016). A notable exception are discovery interfaces, which are often designed to work with different backends, although this trend is also seeming to come to an end (Chad, 2016).
Therefore, the development of open-source LSPs is imperative. Not only do open-source solutions enable customers to change the fundamental parts of the platform for better integration with already existing tools, they also tend to have much better documentation which is a necessity for executing these changes. The creation of an LSP that actively supports multivendor configurations is far superior to proprietary products with limited access to the underlying system because institutions are able to integrate existing workflows into a new LSP, if the vendor provides the necessary API and are also able to choose the right tools for their use case, while not being bound to the solutions that the original LSP-vendor provides. This should be the ideal that all market participants strive for, because library systems are very dependent on flexibility due to the nature of the work that is done in the corresponding institution. Circumstances may change quickly and the software has to be able to adapt to that (Cote & Ostergaard, 2017).
Unfortunately, it seems that the competitors prefer to create ecosystems that they are in control of. From an economic point of view, this might seem beneficial but actually goes against the core idea of an LSP. The LSP functions as a base for a multitude of services that can either be products of a vendor or the result of cooperation in open-source projects, and this flexibility is the key to set the difference between the LSP and the traditional ILS, as well as to create an open market of targeted products to address specific needs.
Architectural Differences: ILS vs. LSP
Where ILSs are based on a functional approach, LSPs revolve around flexible metadata structures that are used to build custom components that resemble the functional components of ILSs while providing much greater flexibility concerning different media types, e.g. electronic resources (Breeding, 2020). ILSs tend to focus on print but are very capable of handling electronic resources as well, but regarding the back-end management of electronic resources, the LSPs have a notable advantage through the usage of built-in knowledge bases that track subscriptions on a portfolio level rather than by the journal (Breeding, 2020). Through rich data models and corresponding APIs, electronic resources can be properly integrated into user-facing services, such as OPACs, but predominantly discovery interfaces.
ILSs follow the client-server paradigm and are almost exclusively hosted as single-tenant instances. These instances operate on a single server or server cluster and serve a single institution or organization (Breeding, 2020). Depending on the context in which the institution operates, they may use an on-premises solution or might work with a dedicated server inside a municipal or university data center, which enables institutions to directly access the shared database (Breeding, 2020). The LSP, however, is often implemented as a SaaS3 -solution as multitenant instances for multiple institutions. All institutions share the same underlying software and therefore the same version and software libraries (Breeding, 2020). User- and staff-facing features are realized as web-based components that communicate via APIs to the back-end and databases, respectively. The tenants profit from shared resources, e.g., shared knowledge bases, discovery indices, and community resources, such as user-generated content, while maintaining strict separation of user data, financial data, or other types of highly sensitive data (Breeding, 2020).
FOLIO
Folio is the most prominent example of an open-source LSP. Despite being backed by companies like EBSCO, namely, because of their lack of an LSP integrated with the EBSCO discovery service, the project is open-source and openly licensed under the Apache-2.0 license and already supported by a variety of independant vendors. FOLIO is built on modern web technologies and therefore quite flexible concerning future development. The system could function as an open platform for third-party components in the form of independently developed applications, as mentioned before and properly embrace the platform character of LSPs. FOLIO is also a rather rare specimen, because it can theoretically be hosted as an on-premises single-tenant solution, although this is not very efficient. Multi-tenant instances as consortium projects might be more feasible.
A rich application ecosystem might render the products of competitors like OCLCs WorldShare Management Service or Ex Libris’s Alma obsolete, as FOLIO or a comparable open-source solution could provide components that could encompass almost all digitizable workflows in institutions, spanning from project management to third-party app integration or even native solutions to CMS-applications for managing content on the institutional website. Indeed this would require a widespread adoption of an open-source LSP but would not be unheard of.
Open-Source & Innovation
(Schrape, 2019) illustrates the importance of open-source licensing of critical infrastructure to create de facto industry standards helping with
interoperability, as well as reducing R&D budgets by incentivising vast open-source developer communities to contribute to projects through the opportunity to monetize their solutions. LSPs are essentially a way to open the niche market of library software to a larger group of developers that can enrich the field with new perspectives and diversify the very specialized vendor ecosystem.
Consequently, the big players in the market will have to open their platforms as well and have to work on industry-specific standardization, which will successively lead to an adoption of the proposed platform model to enable compatibility with solutions that already exist for LSPs like FOLIO.
Opportunities
The introduction and widespread adoption of open-source LSPs or at least LSPs that embrace the platform model could lead to a radical shift in in-teractivity between not only institutions and their patrons but also lead to the creation of entirely new services that are not commonly associated with libraries, e.g. social networks that are scoped locally or regionally and tightly integrated with core library services. Cooperation within library associations could enable competitive products like book cover or patron review APIs, which companies like Amazon or Thalia could subscribe to, to enrich their own product descriptions. Patrons could profit from blockchain-based tokens that could function as a reward for generating content for the just mentioned APIs, and this are just some quickly envisioned examples.
The other side of the story is that the possible renunciation of proprietary software opens up new possibilities of personal development of the institutional staff. Due to the open APIs of all LSPs, librarians and library staff in general are incentivised to think about projects or new services from a more technical point of view, acquire new skills and contribute in-house solutions to the open-source ecosystem.
This will hopefully lead to a less vendor-dependent market, where library staff plays a much more active role in digital innovation and digitization of library processes, but that remains to be seen.
Bibliography
Breeding, M. (2015). Chapter 1. Introduction and Concepts [Number: 4]. Library Technology Reports, 51(4), 5–19. Retrieved July 24,
2021, from https://journals.ala.org/index.php/ltr/article/view/5686
Chad, K. (2016). Rethinking the Library Services Platform. Higher Education Library Technology Briefing Paper [Publisher: Higher Education Library Technology]. https://doi.org/10.13140/RG.2.1.4989.4481
Cote, C., & Ostergaard, K. (2017). Master of “Complex and Ambiguous Phenomena”: The ERL’s Role in a Library Service Platform Migration. The Serials Librarian, 72(1–4), 223–229. https://doi .org/10 .1080/ 0361526X.2017.1285128
Breeding, M. (2020). Smart Libraries Q&A. Smart Libraries Newsletter, 40(10), 3–4. Retrieved July 25, 2021, from https ://librarytechnology .org/ document/25609
Schrape, J.-F. (2019). Open-source projects as incubators of innovation: From niche phenomenon to integral part of the industry. Convergence: The International Journal of Research into New Media Technologies,
25(3), 409–427. https://doi .org/10.1177/1354856517735795
