An OpenRS 2026 mid-year update
This update follows the OpenRS 2025 Technology End-of-Year Report. Since then, our work has concentrated on a question that sits underneath many of the practical challenges facing OpenRS: how do we preserve the operational advantages of deeply integrated direct consortial borrowing while making participation possible for libraries whose systems cannot support that level of integration?
The result is ORS-Appliance: a deployable software appliance that gives a library a point of presence in the wider resource-sharing world.
It is not a physical appliance, and it is not simply a client for one OpenRS hub. It is a stand-alone system that can sit between a library’s local environment and one or more resource-sharing networks. It can support highly automated DCB participation where the local system permits it, staff-mediated participation where it does not, and a gradual transition between the two.
This post explains how that idea emerged, what exists now, and what conversations we believe it should open.
From ReShare to OpenRS DCB
The software that later became ReShare approached consortial resource sharing through a combination of ISO 18626 and a management application deployed for each participating library.
ISO 18626 carried requests between libraries. NCIP connected the local application to the library management system. Resource-sharing activity was mediated through a dedicated staff interface, based on the original application written by K-Int before the ReShare project was established.
That remains a strong model for traditional interlibrary loan. ISO 18626 is particularly well suited to communication between independently operated resource-sharing systems. It works well where organisations have not tightly coordinated their local circulation workflows, where requests may be based on bibliographic citations rather than shared private identifiers, and where the item supplied may be non-returnable.
When the MOBIUS DCB procurement arrived, however, it exposed a different class of problem.
In a direct consortial borrowing system, library users and staff should interact almost entirely with their own library system. The DCB platform works behind the scenes, coordinating otherwise independent circulation systems so that a wide-area loan looks and feels as much as possible like a local one.
The operational benefits are considerable. Staff do not have to learn and monitor a separate application for routine transactions. Work does not have to be entered, checked or reconciled twice. Requests can move more quickly. Training overhead is reduced. The cost of each transaction falls because the act of consortial resource sharing becomes part of the standard circulation flow rather than a parallel specialist activity.
DCB systems achieve this partly by reducing the problem to its most valuable core: returnable print lending between cooperating libraries.
ISO 18626 describes a much broader resource-sharing world, but it does not carry the range of circulation operations needed to make two library systems participate in a single tightly coordinated DCB transaction. NCIP is much closer to an idealised description of that circulation conversation. In practice, however, vendor NCIP implementations rarely expose enough of it, particularly for workflows such as pickup anywhere.
In the early stages of MOBIUS it therefore became clear that we would need to work directly with proprietary library-system APIs. ISO 18626 did not carry the required messages, while the available NCIP implementations did not provide the fidelity needed to coordinate the full transaction.
That decision gave rise to the OpenRS DCB solution.
What the existing DCB model does well
The existing OpenRS DCB architecture can provide an exceptionally high level of integration between systems from different vendors. To library staff and users, the network can behave much more like one large virtual library system.
That is not a superficial advantage. It removes duplicated work almost entirely. It allows local circulation systems to remain the primary operational interface. It makes wide-area fulfilment part of an existing library workflow rather than an additional system that staff must remember to check.
For consortia composed mainly of libraries with strong, mature DCB adapters, this model works extremely well. Nothing in ORS-Appliance is intended to discard those benefits or force those libraries back into staff-mediated ILL workflows.
The difficulty lies in the cost and shape of the adapters themselves.
The adapter problem
A DCB adapter is not a simple connector. It is a complex, stateful component that must observe and reconcile activity across several systems at once.
A transaction may be changed by a user, by library staff, by the host library system, by another library, or by the DCB coordinator. The adapter must detect those changes, interpret them correctly, recover from partial failures and keep the participating systems aligned.
In many cases this requires polling because the host system provides no usable event stream. That makes adapters compute- and database-intensive. Concurrency is unavoidable, and the system must cope with events arriving late, out of order or more than once.
In the current architecture, much of this complexity is concentrated in a single application. Each new adapter requires detailed knowledge of the OpenRS workflow engine, Java, multithreaded state reconciliation, protocol exchanges, circulation practice and the proprietary API being integrated.
That is a rare and expensive combination of skills. It is also a skillset much sought after in fintech and many other areas of software engineering.
The result is that adapters are expensive to develop and maintain. Adding support for another library system is not a trivial extension. More importantly, some systems cannot be supported at all because their APIs do not expose enough information or control to sustain the required conversation.
This creates a structural adoption problem.
Some OpenRS members are fortunate enough to operate consortia composed almost entirely of libraries for which first-class adapters exist. Others have a long tail of unsupported or unsupportable systems. A consortium may have twenty libraries ready to participate and five whose local systems cannot be integrated to the required level.
If every member must have a full adapter before the network can start, the consortium is forced to solve its hardest integration problem before it can complete its first transaction.
That is an all-or-nothing proposition, and it places the greatest burden on the libraries least able to absorb it.
Finding a better system boundary
There is a discipline in systems analysis that matters particularly when building distributed systems: boundary setting.
Decomposition is not about creating the greatest possible number of services. It is about finding boundaries that reflect the real structure of the problem.
Get those boundaries right and complex work becomes understandable, replaceable and scalable. Get them wrong and no amount of interface polish will save the result. You cannot polish a turd; at best, you create a gilded cage for its users.
We did not write the original resource-sharing application because we believed that model was worthless. It simply was not the right shape for the MOBIUS problem.
Equally, our decision to build tightly integrated DCB adapters did not mean that ISO 18626 had no future in OpenRS. It meant that we first needed to learn where each kind of integration belonged.
Looking again at the original ReShare model, OpenRS DCB and NCIP suggested a new boundary:
What if NCIP became the contract between the DCB coordinator and a library’s local point of presence?
NCIP is a strong abstract description of the circulation conversation needed by DCB. Its weakness has been incomplete and inconsistent implementation.
If OpenRS controls both ends of the conversation, however, we are no longer constrained by the subset selected by a library-system vendor. We can define an OpenRS NCIP profile that carries the full conversation required between the coordinator and the library-side component.
That gives us a protocol-shaped boundary rather than an in-process Java boundary.
The adapter can remain complex, but the complexity no longer has to live inside the core workflow engine.
Two new concepts
This work has produced two related concepts.
The first is the declarative adapter.
A declarative adapter communicates with the OpenRS DCB coordinator using a defined protocol rather than a Java interface embedded inside the DCB service. The first concrete implementation uses NCIP 2.02.
This means that a new integration can be written in any appropriate language by any organisation, provided that it fulfils the agreed contract. A consortium, hosting provider, library-system vendor or independent developer could implement an adapter without first becoming an expert in the internal structure of the OpenRS DCB service.
That contract includes security as well as NCIP messages. OpenRS DCB layers OIDC-based authentication over NCIP 2.02 and uses the ILL directory to share the public keys used for JWT validation. Interoperating implementations must therefore integrate with the OpenRS authentication layer, not only implement the NCIP operations.
The same principle applies to the ORS-Appliance ISO 18626 implementation. It does not accept unsecured speculative requests and then rely on IP allowlisting as its only security boundary. Interoperating ISO 18626 peers must integrate with the authentication layer too.
The second concept is ORS-Appliance.
ORS-Appliance is a stand-alone resource-sharing application that can act as the library-side endpoint of that contract. It can connect a local system to an OpenRS DCB coordinator, communicate with external resource-sharing peers using ISO 18626, and provide a staff interface where human intervention is required.
Together, these concepts move system-specific variety away from the centre of the DCB platform and towards the edge of the network.
The appliance as a library’s point of presence
ORS-Appliance sits between a system that wants to share resources and the wider set of peers that may want to lend or borrow.
On one side, it can connect to a library management system, repository, digital asset management system or another local source of supply.
That local connection might be a high-fidelity proprietary API integration. It might use NCIP, webhooks or scheduled file exchange. It might automate only part of the workflow. At the far end of the long tail, it might present clear instructions to a member of staff who carries out the required operation manually.
On the other side, ORS-Appliance can participate in a tightly coordinated DCB network through the NCIP-based declarative adapter. It can also communicate directly with other resource-sharing systems using ISO 18626.
This makes the appliance the library’s point of presence in a wider resource-sharing mesh.
It is not merely a thin client for one OpenRS hub. A library may use it to participate in a particular consortium, communicate with established ISO 18626 peers, join specialist or geographic groups, or make use of other fulfilment routes.
We are not trying to give libraries a client to only our walled garden.
We are trying to give each library an interoperable resource-sharing capability in which a particular consortium or hub is one valuable choice rather than the only possible destination.
Automation is a spectrum
For an existing MOBIUS member with a mature adapter, ORS-Appliance need not change the visible workflow. Requests can still appear and progress automatically through the library’s normal circulation interfaces.
For another library, the appliance might automate discovery and messaging but ask staff to print a pull slip, select an item or confirm shipment.
For a system with no useful API, the library might upload MARC holdings and patron data while staff use the appliance to coordinate the circulation actions that cannot be performed electronically.
This is not a retreat from automation. It is a way to make automation incremental.
A consortium could begin operating on day zero, before every adapter has been completed. Every member would have a working route into the network. Some transactions would be almost entirely automatic. Others would require the same kind of staff intervention already familiar from conventional resource sharing.
As integrations improve, manual steps can be replaced one at a time without changing the wider network contract.
That creates a practical migration path:
Manual participation → assisted workflow → partial integration → full DCB automation
It also provides a lower-risk route for cautious libraries that want to toe-dip in a new approach.
They do not have to replace an established service or commit immediately to a consortium-wide transformation. They can join a limited network, route selected demand through the appliance, measure the results and expand when the value has been demonstrated.
For libraries that previously considered OpenRS but could not win support for a more innovative wholesale change, this may be a much more realistic adoption model.
Absorbing variety at the edge
The architectural purpose of ORS-Appliance is to absorb variety.
Resource-sharing environments vary enormously. One library may expose a modern event-driven API. Another may offer only a partial NCIP implementation. A third may be able to export records over SFTP but provide no usable circulation API.
Another supplier may not be a library system at all. It may be an institutional repository, a digital collection, an open-access source or a human-mediated service.
Trying to place every one of those behaviours inside a central DCB workflow engine creates a monolith whose complexity grows with every participant.
ORS-Appliance moves that variety towards the edge of the network. The central DCB coordinator deals with a consistent contract. Each appliance deals with the particular capabilities and limitations of its local environment.
This does not eliminate complexity. Each local integration may still be difficult. What changes is where that complexity lives, who can work on it and how failure is contained.
An adapter could be developed independently in Java, Python, JavaScript, Go or another suitable language. It could be maintained by K-Int, EBSCO, another hosting provider, a consortium, a library-system vendor or the library itself.
An institution could use ORS-Appliance as supplied, extend it through webhooks, or write a replacement that implements the same NCIP contract.
This democratises the adapter ecosystem without weakening the high-fidelity workflows that make DCB valuable.
It also allows the platform to scale out. Instead of concentrating polling, reconciliation and state management for every library inside one increasingly large service, work can be distributed across appliance instances close to the systems they represent.
Putting ISO 18626 back in the right place
This architecture gives ISO 18626 a clear place in the OpenRS model.
Within a tightly coordinated DCB network, NCIP can carry the rich circulation conversation between the coordinator and the appliance.
Between autonomous resource-sharing organisations, ISO 18626 can carry the looser request and supply conversation for which it was designed.
ORS-Appliance can mediate between those worlds.
A library participating in an automated DCB consortium could still send or receive an ISO 18626 request from an external peer. A consortial request that cannot be filled internally could eventually be offered to a broader group. An appliance could seek an open-access or repository copy before beginning a conventional returnable-loan workflow.
Non-returnable document delivery could sit alongside print lending without forcing every transaction through a DCB-shaped process.
There are also more speculative possibilities.
Instead of requiring every potential supplier to contribute records to a large central index, a request might be broadcast to an appropriate group and interested suppliers could return offers. The requesting system could then select the most suitable route according to availability, cost, speed, policy or format.
That federated solicitation model is not the immediate definition of ORS-Appliance, and it should not distract from the practical work already under way. It does, however, illustrate what becomes possible once a library has an independent and interoperable point of presence.
What exists now
This is not only an architectural proposal.
The proposed boundary exists in working software, and ORS-Appliance already supports a fallback deployment in which a library without a full adapter can participate through staff-mediated coordination.
The current development direction includes:
- A stand-alone ORS-Appliance application
- An NCIP-based declarative adapter boundary
- Integrated DCB and ISO 18626 request handling
- Staff workflows for pull slips, manual intervention and return processing
- Repeatable smoke tests against a clean end-to-end deployment
- A vendor-neutral discovery service
- A white-box deployment intended to make a complete OpenRS environment practically runnable
- Support for identity integration through SAML and OIDC
- Webhook-based extension points for local automation
- File-based onboarding routes for systems that can export data but cannot support real-time integration
Some of these capabilities are already demonstrated in the current smoke-test environment. Others are active development areas rather than finished production features.
The important point is that the architectural boundary has moved from theory into implementation.
A complete system, not only a component
ORS-Appliance is being developed alongside a vendor-neutral white-box OpenRS deployment.
The aim is to make it possible to stand up an end-to-end working resource-sharing environment without first assembling a set of separately negotiated proprietary components.
This does not mean that every production consortium should operate the software itself. Hosting, implementation, support, logistics, service management and high-value consortial integration remain important services.
It does mean that the underlying system should be inspectable, runnable and portable, without artificial technical barriers.
For established providers such as EBSCO, ORS-Appliance offers a possible route to more varied deployments. Large, deeply integrated consortia remain important. The same architecture could also support smaller networks, gradual adoption and high-volume, low-cost services.
That may include transaction-based charging or other usage-led models that would not be economical if every participating library first required a bespoke adapter project.
No commercial model has been decided. The architecture creates options, and those options now need discussion.
Licensing and sustainability
The latest ORS-Appliance work has been privately funded by K-Int during a gap in external project support.
We would therefore like to discuss releasing the new work under the Functional Source License, using an Apache 2.0 future-license variant.
Our intention is straightforward.
Libraries should be able to inspect the source, run it, evaluate it, modify it and use it for their own resource-sharing activity. We do not want to create artificial technical barriers to grassroots adoption or experimentation.
At the same time, a commercial provider should not be able to take newly funded K-Int development, immediately offer the same software as a competing hosted service and contribute nothing towards the cost of producing or maintaining it.
The FSL provides a period during which competing hosted use requires a commercial agreement, after which the relevant release converts to the stated permissive future licence.
The purpose is not to exclude hosting providers. It is to create a defined period in which organisations earning revenue from the software negotiate a sustainable relationship with the people funding the work.
The precise licence variant, conversion period, definition of competing use and boundary between existing Apache-licensed OpenRS components and new FSL-licensed work must all be documented carefully.
This should therefore be treated as a proposal for discussion, not as a final licence announcement.
What ORS-Appliance changes
ORS-Appliance does not replace OpenRS DCB. It changes the boundary around it.
It preserves the ultra-lean workflows available to libraries with high-fidelity integrations.
It gives libraries with incomplete, unsupported or unsupportable systems a viable way to participate.
It allows automation to grow incrementally instead of making complete automation a precondition of entry.
It enables adapters to be developed independently and in different languages.
It reconnects OpenRS with the wider ISO 18626 resource-sharing world.
Most importantly, it makes the library, rather than the central hub, the fundamental addressable participant.
A consortium can still provide the shared policies, discovery, logistics, trust and collective value that make membership worthwhile. A hosting provider can still deliver and operate sophisticated networks at scale.
But the library’s connection is no longer necessarily a proprietary umbilical cord to one central system. It becomes a reusable point of presence from which the library can choose the networks, peers and services appropriate to its needs.
That is the emerging idea behind ORS-Appliance:
A practical gateway between any library and the wider resource-sharing world, capable of full automation where systems permit it, human mediation where they do not, and gradual movement between the two.
It is an architectural proposal, a working implementation and, we hope, the beginning of a broader conversation about how OpenRS can serve both deeply integrated consortia and the long tail of libraries that current DCB models leave behind.
Questions for the Steering Group
We would particularly welcome discussion around three questions.
First, does the fallback and gradual-automation model offer a credible route for consortia with a long tail of unsupported or unsupportable systems?
Second, is an NCIP-based contract between the DCB coordinator and a library-side point of presence the right architectural boundary for a more open adapter ecosystem?
Third, what licensing, hosting and commercial arrangements would encourage multiple organisations to invest in OpenRS while avoiding both unsustainable free-riding and the creation of another walled garden?