OpenRS is building an open route through the full returnable print-lending lifecycle for any library. Regardless of local system capabilities, A library can contribute holdings, let its patrons authenticate and request them, and give staff focused local work while the network conversation remains standards-based.
Consortia will always have a long tail of participating libraries using systems that are unable to support the level of automation needed for a DCB style direct print loan within a consortia. ORS-Appliance is addressing that need by providing an interface app between the hub and participating libraries. ORS-Appliance can support any library where a human can help coordinate the system by guiding staff through the resource sharing workflows for the consortium. ORS-Appliance can support libraries with no system at all or paper systems through to the full integration. It also supports direct library to library ILL over ISO18626 giving individual libraries the power to join many consortia and engage in more traditional peer to peer lending without binding themselves to a single upstream hub. ORS-Appliances extensive adoption of NCIP2.02 gives peers the ability to exchange the full richness of DCB functionality without needing the high fidelity APIs required for native DCB adapters.
Think of ORS-Appliance as a libraries point of presence into the global resource sharing network, but a genuine network of peer-to-peer and multiple-consortia relationships rather than a monoculture or monopoly with a single provider. With ORS-Appliance you can switch out your ILS, or join multiple consortia, or exchange ILL requests with any standards compliant ISO18626 system.
This update is based on a clean rebuild and one current evidence run. It reaches return transit but does not yet close the demonstrated loan at the supplier. It does not claim production readiness.
An open participation model
Some resource-sharing systems require one vendor’s local client, private protocol, and broker. OpenRS separates those choices. ORS-Appliance uses NCIP v2.02 at the DCB boundary, so another system can implement the same documented profile without a proprietary SDK. We are also using more of NCIP’s circulation vocabulary as the lifecycle grows, rather than limiting it to a narrow lookup.
ORS-Appliance releases use FSL-1.1-ALv2 and become Apache License 2.0 on the first anniversary of each version. The aim is software libraries can inspect, operate, replace, and integrate—not another closed client stack.
Before the patron request: getting records in
The clean smoke prepared a MARC file for Brain of the Firm, second edition, and a fallback-patron
TSV. It uploaded each to SFTPGo under a route-specific account as .partial, then atomically renamed
it into ready. ORS-Appliance imported the MARC record into Hogwarts and the patron into Unseen.
DCB Admin showing the imported second edition beside the first-edition fixture as two edition-level shared-index clusters.
SFTPGo is the local transport, not the intake boundary itself. ORS-Appliance watches for an atomic file in a routed directory. Production credential isolation, monitoring, recovery, and deployment remain open work.
Institutional login, then discovery
The patron starts in the public catalogue and chooses the institution that should authenticate them. Discovery does not need to own every library’s identity system.
After login, the patron searches the shared catalogue, opens a title, and chooses where to collect it. Host System and protocol mechanics stay out of this journey.
First and second editions form two clusters, with edition and ISBN identifiers visible to the patron; records for the same edition cluster together.
Low-friction supplier work
An integrated Host System may automate local facts. Where it cannot, ORS-Appliance provides focused staff work rather than exposing protocol messages.
The current supplier path can group retrieval work by item location and prepare a printable batch.
Once staff retrieve the item, the key confirmation uses the barcode already on the copy.
This is meaningful progress toward scanner-first work, but not yet proof that the whole routine path can be completed using only a barcode reader.
Requester handling and the return journey
The borrowing library receives corresponding work as the item moves. Staff can record receipt, checkout to the patron, and return shipment through the same lifecycle.
What this checkpoint changes
The product is now easier to explain as one journey: contribute a holding, authenticate a patron, place a request, retrieve by pull slip, confirm the copy, circulate it, and ship the return.
The next evidence update should close four gaps:
- production-safe, collection-scoped record transfer with operator-visible processing history;
- barcode-first requester receipt, checkout, and return;
- projection of return-expected state to the supplier, followed by supplier receipt and finalisation;
- a routine operations run proving the same path without smoke-only identities or fixtures.
We will reuse this lifecycle structure for future status posts. Each iteration will start from a clean run, recapture changed screens, record the tested revisions, and state both the demonstrated boundary and the next missing proof.