Public Library Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a library keep getting sold a full system replacement?

The conversation starts honestly. Holds are routed badly, the consortium argues about money, the board wants usage figures nobody can produce without breaching a confidentiality statute, and four separate systems each hold a partial copy of your patron. Someone reasonably concludes that the library system is the problem, and a developer agrees, because replacing a system is a larger engagement than extending one.

The diagnosis is wrong in a way that is specific to libraries. None of those four complaints is a cataloguing failure. Your ILS records bibliographic and item data correctly, circulates accurately, and applies fines policy as configured. What it does not do is coordinate: decide which of 41 copies fills a hold given today's courier schedule, encode a consortium agreement about who pays when a member's item is lost by another member's patron, or separate the operational borrowing record from the analytical one. Those were never in scope for an ILS and no replacement will add them.

The fix is to scope the coordination layer and leave the catalogue alone. Koha and Evergreen both have open data models and real interfaces, which means custom work sits alongside them as a first class citizen rather than a hack, and Evergreen was designed around consortial borrowing from the start. Almost every library project we have delivered that succeeded kept the ILS and owned the layer above it. If a developer's first proposal is a replacement, ask them to price the routing layer separately and compare the two numbers against the same list of complaints.

What goes wrong when you migrate bibliographic and patron records?

Migration is where library projects lose their schedule, and the cause is almost never software. It is data that accumulated across decades of differing cataloguing practice.

Bibliographic cleanup is the largest single task. Records imported from vendors, records typed locally in the 1990s, records inherited when a member joined the consortium, and records that predate current descriptive cataloguing practice all coexist. Authority reconciliation is worse, because the same author appears under three heading forms and merging them changes what patrons find. Item records carry local practice encoded in fields nobody documented, such as a location code that means one thing at the main library and something else at a branch that closed in 2011.

Patron records bring a different problem. Your retention policy, and in most states your confidentiality statute, limits what borrowing history you may hold, and migration is exactly the moment someone proposes carrying five years of circulation history forward so the statistics still work. That is a board decision, not an engineering one, and it must be settled before anyone writes a mapping. Teams that defer it end up with a migration script waiting on a policy meeting.

Scope migration as its own project with its own budget and its own timeline, dominated by cataloguing staff time rather than developer time. Do not let it be bundled into an optimistic software number, because when the two are combined the cleanup gets squeezed and the result is a catalogue nobody trusts.

Why do the self check, inter library and digital lending integrations break after launch?

A public library runs more integrations than most mid sized businesses, and each speaks a different dialect. Self check machines and RFID pads use SIP2. Inter system circulation uses NCIP. Digital lending through OverDrive with Libby, plus Hoopla and similar services, uses its own authentication and holds its own usage data. Then there is public computer and print management, the courier manifest system and municipal finance for fines and fees.

The failures share a pattern. SIP2 implementations differ by vendor and by firmware version, so a message that works on the units at three branches fails on the older units at the fourth, and the failure looks like a network problem to staff. NCIP exchanges break when a partner system changes a code list without notice, and the symptom is holds that silently never arrive rather than an error anyone sees. Digital lending platforms authenticate patrons independently, so a patron record change on your side leaves them able to borrow ebooks from an account you have closed, and their usage never reaches your reporting, which means your annual circulation figures understate real use every single year.

The design that survives launch treats each integration as an adapter with its own monitored heartbeat, logs the actual message exchange rather than a summary, and reconciles rather than assumes. A nightly job that compares patron status across your ILS and each digital platform catches the closed account problem before a complaint does. A weekly count comparison catches silent NCIP failures. These are unremarkable engineering habits and they are the difference between an integration that quietly rots and one that tells you when it is unwell.

What happens when patron privacy and board reporting are not reconciled up front?

Borrowing records carry confidentiality protection under state statute across most of the United States, and the profession's own ethics go further. Directors simultaneously need to know what is being used, by which communities, to justify budgets and plan collections. Those two obligations pull against each other and most projects discover it late.

The late discovery is expensive because it is architectural. If circulation and reporting share one record, the only way to answer the board's question is to retain the linkage between patron and item, which is precisely what your policy tells you to discard. Teams then either keep more history than they should, or build reporting so coarse it answers nothing, and both outcomes are permanent once the data model is set.

Separate the two from the start. The operational record keeps the patron to item linkage only while the item is out, then discards it on return under your retention policy. Analytics is written at the moment of transaction as de identified aggregates: item, format, subject, branch, patron category, and census tract if your board approves that granularity, never the individual. Done this way you can tell a board which neighbourhoods are underserved for early literacy materials while holding no record of who borrowed what. Check your current ILS retention settings too, because several products default to keeping more than a library's written policy intends and nobody notices until a records request arrives.

Should you build custom or configure what you already own?

Buy the ILS. Always. If you run SirsiDynix Symphony or Innovative Polaris and staff are content, stay and build the coordination layer against their interfaces where they permit it. If you are considering a move, evaluate Koha and Evergreen seriously: there is no licence cost, both are genuinely capable, and Evergreen in particular was built for consortia. Ex Libris Alma is a serious platform whose design centre is academic libraries and their acquisitions and electronic resource workflows, which is a different problem from high volume branch circulation, community programming and consumer digital lending.

Before commissioning anything, spend a fortnight testing what your current system will already do. Hold routing rules are often more configurable than staff realise, floating collection thresholds frequently exist and are unset, and several reporting complaints turn out to be permissions rather than capability. Finding that out costs two weeks.

Build the layer above when the complaints are structural rather than configurational: your consortium has fairness arguments that spreadsheets cannot settle, hold routing is visibly consuming courier capacity, your board asks questions your privacy policy prevents you from answering, or you have accumulated four systems for room booking, programme registration, card signup and outreach that each hold a partial patron. That last one is more common than any director likes to admit and it is usually the cheapest to fix.

How do hidden costs get into the quote?

A first release covering hold routing, floating collection rules and privacy safe analytics on top of Koha or Evergreen runs $60,000 to $140,000 and ships in 12 to 16 weeks in Digital Heroes delivery experience. Extending to delivery logistics, a discovery front end, room and event booking and consortium settlement brings the programme to $160,000 to $380,000 across 6 to 12 months. The overruns are predictable.

• Consortium member count. Each member has policies and each member has an opinion, and reconciling eleven opinions about floating thresholds is a governance process the schedule rarely budgets for.
• Hardware variety. Self check and RFID units differ across branches by vendor and firmware, so SIP2 work is priced once and delivered several times.
• Municipal finance integration. Usually a longer conversation with the city than a build, and the schedule belongs to them rather than to you.
• Historical statistics through migration. Preserving them conflicts with retention policy and needs a board decision before an engineer touches it.
• Data cleanup. Bibliographic and authority work is cataloguing staff time, not developer time, and quoting it inside a software number guarantees it gets squeezed.

What separates a library build that works from one that fails?

Four things. The first is that the routing layer explains itself. The first question staff ask about any automated decision is why it sent that item there, and a system that cannot answer gets overridden until it is ignored. Show the reasoning: courier timing, queue depth at the owning branch, branch equity thresholds. Visible arithmetic earns trust that a better algorithm never will.

The second is that the layer talks to the ILS through its interface rather than its database. Reaching into the database works until the next upgrade, and then it breaks in ways nobody can predict from release notes. If something you need is missing from an open source ILS interface, extend the ILS and contribute the change upstream, which is also how the sector's shared infrastructure stays healthy.

The third is that consortium settlement is computed continuously and published where every member can see it. Net lending balance, loss and damage liability and courier apportionment assembled by hand from reports are contested numbers, and contested numbers make long meetings. The same numbers computed from circulation data and visible to all eleven members change the character of the conversation more than any feature does.

The fourth is ownership. Hold the repository and the infrastructure accounts, and agree before kickoff what gets contributed back upstream if the work extends an open source ILS. 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.