Vendors were provided with a set of questions to which libraries in Østfold kommune wanted answers. I'm trying to answer them here.
To answer this question, we need to ask what do a library systems try to achieve today? Library systems facilitate the aims of the library; most libraries agree that these include:
- providing access to materials to patrons
- helping patrons to find materials they are looking for
- promoting goals of learning, creation and recreation
This is a broad spectrum of aims that can be responded to by spaces, events/activities and systems. For our purposes, we need to look at how these aims and their responses can be supported by systems.
Typically, modern library systems comprise distinct functions for carrying out acquisitions, cataloguing, circulation and access. Library systems may additionally integrate with other solutions to provide (added) functionality (accounting systems, external patron databases, etc.), or implement functions not traditionally viewed as part of a library system (events calendars, room booking, etc.)
The reason these functions are provided is twofold, one is to run the library from an administrative perspective and the second is to provide services to patrons. Under a functional view, we often use the term "module" — a module for circulation, a module for serials, a module for statistics — which is a useful abstraction for administrative users, but which belies a technological distinction: these are not technologically modular as there are dependencies between e.g. circulation and statistics and description.
Technologically speaking, in current systems, there are two visible trends. One is often described as "integrated", where everything is part of the same system and integration with third parties occurs by copying data between systems; this leads to a situation where master data generally resides in the library system. The second can be described as "distributed" where different systems components are master of their domain such that the components share data with each other, but no data is stored in a way that there are two master versions of the data.
The library system of the future will have the needs of the individual library at its heart. With flexible development and configuration options, it will provide simple ways of customising the software, from back office, to front-end in a way that makes it possible to try new ideas (changing metadata, altering search weightings, etc.) and add value with immediate effect directly in the platform without reference to a vendor or community process.
The platform of the future will look and feel more like modern software both from a user perspective and from a developer perspective. Access to all levels of the software via dedicated APIs that are in use by the software itself will be the norm; gone are the bolt-on APIs of yesteryear.
We will recognise modern systems by their ability to host and work well together with software from other vendors, whether they are library systems or not. We will recognise the ability to run the software in our own environments or in managed cloud environments — whether they come from a vendor or Google, Amazon, etc. We will recognise the system's modularity via containerisation and see the documentation of these modules directly without reference to the vendor — and this will be the system's sales pitch because the vendor is proud of their product and its capabilities, and the library is unfraid of evaluating technical details of the system
We will also recognise library systems of the future by their clear paths to get data both on and off the platform — and this data will be available at time of evaluation.
The data model in use in the platform will reflect real-world needs in terms of search, circulation and extensibility and will not be tied in any way to data formats that are inappropriate as data models such as data-exchange standards like MARC or BIBFRAME; modern systems will nevertheless be able to consume and produce all of these formats and more.
The library system of the future will come with a liberal licence that empowers the user, not the vendor — the vendor-customer relationship will be changed in a market not dependent on keeping dissatisfied customers on a platform through time and cost of migration. And vendors will realise that the areas of profit exist in helping libraries realise their needs, rather than in creating monolithic one-solution fits everyone with cost differentiation. A sale will no longer be the end of the story.
In the library system of the future, the library is in control.
Largely, library systems will plod on as they have done. Incremental feature creep and choosing areas of development at HQ based on what seems profitable. Libraries will continue to add local colour that will fail when APIs are changed via mandatory upgrades.
Some libraries will move to free and open software and help develop these platforms via financial support or active local development.
Libraries will increasingly move to vendor-sourced, cloud-based offerings from vendors who will offer low entry prices and attractive migration packages with a similar feature set to today's systems. Such offerings will incorporate more and more functionality traditionally seen as beyond the scope of library systems, such as events calendars, and feature integrations with external systems via standard protocols.
Costs will increase.
MARC will not die, nor will it cease to be at the heart of most systems. It will continue to create a weak user experience when used erroneously in systems as a data model and allow bibliographic data to be circulated in a relatively painless way when used for data exchange.
Some systems from more flexible developers will cease to use a core data model entrenched in MARC thinking and move to document-oriented, schemaless storage, inadvertently re-inventing MARC-as-a-core-data-format and all its issues. More forward thinking vendors will provide flexible options for data storage informed by the developments in libraries since the 1970s and founded in strong models from other domains. Whether or not linked data will be the way that this is done remains to be seen, but the core data format will be able to express the description of bibliographic items more explicitly and with entities and strong data typing rather than strings.
Libraries will increasingly look to save money because the value returned from buying off-the-shelf and total cost of ownership will seem disproportional; they will use open-source solutions provided by low-cost vendors.
Collaborative library systems are a misnomer — library collaborations are a thing and using systems within such constellations are a thing, a system that claims to enable collaboration is simply a fiction. Collaborations are administrative before all else. For the collaboration to work, there must be several things in place in the institutions that cannot be facilitated by software.
Working together is hard. Looking for partners based on needs and desires before locality is a wise decision — partnerships with libraries with very different needs and roles causes a tension that is difficult to work with and likely negates any positive outcome. If all parties are strongly in agreement as to what is needed and what is to be prioritised, then things are easier. Institutions will need to dedicate staff to running the collaboration and ensuring the fulfillment of its benefits.
Some libraries aim to save money. Buying a system that claims to "save money" generally means a reduction in service level, or more commonly, simply moving the cost somewhere else in the production chain. And it is highly likely that the total cost of ownership will only increase when moving to a system that facilitates even limited collaboration
Some libraries imagine that collaborating on creating data collaboratively is a way forward, but this assumes that the data they are creating isn't already available for free from the national library. Perhaps they were thinking of adding some other value — will this added value be supported by a new "collaborative" system? Perhaps linked data will do something here? Does the system support consumption, creation and management of linked data — or does it just do plain-old crosswalking?
Libraries must tell vendors what benefits they need in terms of support for outcomes they have planned. In this way, vendors can respond to their needs rather than speculating on benefits that will not come to fruition.
What are the objectives of a public library, of a science library, of the library community. Which principles should be followed, which rules do they need to meet the objectives. Answer these questions and then tell me what kind of tools we need.