Integrated Library System Software: Why Hold Routing, Consortium Fairness and Patron Privacy All Break During the Same Migration

The hold that traveled three hundred miles

A patron at a rural branch places a hold on a popular new novel. The consortium owns 41 copies. Four are on the shelf, one of them 12 minutes away at the next town. The system routes the request to a library on the other side of the state because that copy had been sitting slightly longer in the queue logic, and the courier run means the patron waits nine days for a book that was sitting on a shelf down the road. Multiply that by a few thousand holds a week and you are paying for courier capacity, staff handling and patron patience to solve a problem your software created.

This is the characteristic frustration of public library technology. The catalog works. Circulation works. What does not work is the coordination layer: which copy fills which hold, which items float and which return home, how a consortium shares costs fairly, and how you answer a board question about usage without keeping the borrowing history your state statute tells you to protect.

The vendor landscape is mature and not bad. Koha and Evergreen are open source and both are genuinely capable, with Evergreen designed from the start around consortial borrowing across many libraries. SirsiDynix Symphony and Innovative Polaris are established proprietary systems with long institutional histories. Ex Libris Alma is a serious platform whose center of gravity is academic libraries and their acquisitions and electronic resource workflows, which is not the same problem a public library system has.

Nobody should build a new integrated library system, and here is why

We turn this work down more often than we take it, so take the following as advice against our own interest. An ILS is thirty years of accumulated correctness in areas nobody thinks about until they break: MARC 21 record handling and RDA cataloging rules, authority control, serials prediction patterns, fines and fee policy engines with grace periods and per patron type variation, holds queues, and Z39.50 for record retrieval. Rebuilding that is a multi year project that ends with a worse cataloging module than the one you already have.

What is worth building is everything the ILS treats as an afterthought, on top of an open source core you can extend. Koha and Evergreen both have open data models and real APIs, which means a custom layer is a first class citizen rather than a hack. That is the shape of almost every library project we have delivered that succeeded: keep the ILS, own the coordination.

Hold routing and floating collections are an optimization problem

Most systems fill a hold using a simple rule: the longest idle copy, or the first available in a configured branch order. Neither considers the thing that actually matters, which is total cost and time to the patron given today's courier schedule, today's queue depth and where the item will be needed next.

A routing layer that reads the ILS state and makes better decisions is a contained, high value build. It weighs courier run timing, so a copy that misses today's van is worth less than one that catches it. It considers queue depth at the owning branch, so you do not strip a branch of its only copy when its own patrons are waiting. It handles floating collections properly, meaning items that stay where they are returned, with balancing rules that prevent one busy branch accumulating half the collection while a small branch empties. And it exposes why a decision was made, because the first question staff ask about any automated routing is why it sent that item there.

The measurable outcomes are the ones your board cares about: fewer items in transit, shorter waits, less courier tonnage. Those are real operational savings and they come from arithmetic, not from replacing your catalog.

Consortium fairness rules that no vendor models

A consortium is an agreement between independent libraries with independent budgets, and the software almost never encodes the agreement. Who pays when a member's item is lost by another member's patron. How reciprocal borrowing is balanced when one large member lends far more than it borrows. How purchase decisions are coordinated so eleven members do not each buy fifteen copies of the same title while nobody buys the local history nobody else will. How courier cost is apportioned.

These get settled in committee meetings using spreadsheets assembled from ILS reports by whoever has the skills, which means the numbers are contested and the meetings are long. A build that computes net lending balance, damage and loss liability, and courier volume per member from the circulation data, and publishes it on a dashboard every member can see, changes the character of those meetings. It is not glamorous software. It is the software that keeps a consortium together.

Patron privacy is statutory and it fights with analytics

Library borrowing records carry confidentiality protection under state statute across most of the United States, and the profession's own ethics go further. That creates a genuine tension: directors need to know what is being used, by which communities, to justify budgets and plan collections, while the records that would answer those questions are the ones you are obliged not to retain or disclose.

The engineering answer is to separate the operational record from the analytical one. Circulation keeps what it needs while an item is out and discards the linkage on return, per your retention policy. Analytics runs on aggregated and de identified data written at the point of transaction: item, format, subject, branch, patron category, census tract if your board approves that granularity, and never the individual. Done properly you can answer which neighborhoods are underserved for early literacy materials without holding a single record of who borrowed what.

This is worth building deliberately rather than inheriting. Most ILS reporting modules were built before anyone thought hard about this, and the default retention settings in several products keep more than your policy probably intends. Check yours.

The integration surface is the real scope

A public library system runs more integrations than most mid sized businesses. Self check machines and RFID pads speak SIP2. Inter library circulation between systems uses NCIP. Digital lending through OverDrive and Libby, plus Hoopla and similar services, has its own patron authentication and its own usage data that never appears in your ILS reports, which means your circulation numbers understate reality every year. Add public computer and print management, the courier's manifest system, your municipality's finance system for fines and fees, and increasingly a room booking and events platform.

The value of a custom layer is often simply that it becomes the place where these meet. A single patron identity across physical and digital lending, a single usage picture for the board, and one integration point for the next service instead of a new silo. That is unremarkable engineering and it is where most of the day to day pain actually lives.

What a custom layer should include

• Hold routing that weighs courier timing, queue depth and branch equity, with visible reasoning
• Floating collection rules with balancing thresholds per branch and per collection
• Consortium settlement: net lending balance, loss and damage liability, courier apportionment
• Coordinated purchasing views showing consortium wide holds ratio before a member orders copies
• Analytics written as de identified aggregates at transaction time, with operational linkage discarded on return
• Unified patron identity across physical circulation and digital lending platforms
• Delivery and courier manifests generated from actual transit items rather than typed
• A public facing layer for room booking, program registration and card signup that shares patron identity

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, the sensible shape for a library system is a first release at $60,000 to $140,000 in 12 to 16 weeks covering routing, floating rules and privacy safe analytics on top of Koha or Evergreen. Extending to delivery logistics, a discovery front end, room and event booking and consortium settlement brings the program to $160,000 to $380,000 across 6 to 12 months.

A migration from a proprietary ILS to an open source one is a separate project with its own budget, typically dominated by bibliographic data cleanup, authority reconciliation and patron record migration rather than by software. Scope it separately and do not let a vendor bundle it into an optimistic number.

What drives cost up: the number of members in a consortium, because each has policies and each has an opinion. RFID and self check hardware variety across branches. Municipal finance integration, which is usually a longer conversation than a build. And any requirement to preserve historical circulation statistics through a migration, which conflicts with retention policy and needs a decision from your board before an engineer touches it.

Build versus buy, honestly

Buy the ILS. Always. If you are on Symphony or Polaris and content, stay and build the coordination layer against their APIs where they permit it. If you are considering a move, evaluate Koha and Evergreen seriously: they are free of license cost, extensible, and Evergreen in particular was built for consortia. Alma is worth considering if your system is genuinely academic in character, and is usually a poor fit for a public library's programming, community services and digital lending mix.

Build the layer above when your consortium has fairness arguments that spreadsheets cannot settle, when hold routing is visibly costing courier capacity and patron patience, when your board asks usage questions your privacy policy prevents you from answering, or when you have accumulated four separate systems for room booking, program registration, card signup and outreach delivery that each hold a partial copy of your patron. That last one is more common than any director likes to admit.

How to choose a developer for library software

Ask them what MARC is before you ask anything else. A developer who has worked with libraries knows what a bibliographic record is, why authority control exists, and that item and bib are different things with different lifecycles. One who does not will model your catalog as a products table and you will spend the project explaining why a title with nine editions and forty copies is not a variant of a shoe.

Ask whether they will build against the ILS API or reach into its database, because the second option works right up until an upgrade. Ask how they would design analytics that satisfy a board and a state confidentiality statute at once, since that answer separates people who have thought about libraries from people who have not.

Ask what they have integrated: SIP2 self check units, an RFID vendor, NCIP for inter system circulation, and a digital lending platform are four different problems and none of them is a REST API with good documentation. Get specifics. Finally, settle code ownership in writing before kickoff. You should hold the repository and the infrastructure accounts, and if the work extends an open source ILS, agree up front what gets contributed back upstream. At Digital Heroes the library owns the code from the first commit, and in a sector built on shared infrastructure, contributing improvements back is usually the right instinct as well as the generous one.