Why I'm Building a Library System From Scratch

Experiment limits, September 11, 2026. L/30 is an open-source sandbox using synthetic data. The feature inventory describes scope, not a reliability or usability result. This article does not demonstrate production readiness, a successful migration, or shared governance. The next useful evidence is one repeatable workflow, its failures, and an export/restore check.

I'm building an open-source library management system called L/30. It is an AGPL-licensed sandbox for testing what changes when a library can inspect and modify the software beneath its daily work.

Why

The question is larger than whether a particular product is good or its developers are capable. It is who controls the software, its roadmap, and the library's ability to leave. OverDrive, where I worked from 2008 to 2011, is owned by KKR. SirsiDynix sits under Constellation Software; Ex Libris and Innovative sit under Clarivate.

Libraries encounter that structure through contracts, product roadmaps, and the cost of migration. L/30 gives me a way to test the alternative in public instead of describing it only in theory.

The practical goal is straightforward: a library should be able to inspect the code, export its data, change providers, or run an independent instance without losing the work it has already paid for.

What it actually is

l/30 is a full-stack library management system:

• Backend: Python/FastAPI with PostgreSQL and Redis
• Frontend: React/TypeScript
• Search: pgvector for semantic search alongside traditional keyword
• Deployment: Docker Compose, designed to run on modest hardware

It runs at l30.org. Real containers, real code. Updated July 30, 2026: it is an open-source sandbox now, on synthetic data, rather than something approaching customer-testing readiness. I took these systems apart to understand them and rebuilt them in the open; that is what this is for.

What the repository contains

The repository contains a broad set of modules. This inventory describes implementation scope, not production readiness or successful use in a library:

Core ILS: Circulation (checkout, holds, renewals), cataloging with MARC and BIBFRAME support, patron management, inventory tracking, acquisitions.

The stuff that usually costs extra: A learning management system with courses and certificates. Reading programs with gamification. Makerspace equipment tracking. Home delivery logistics for homebound patrons. Event management. A blog module.

The stuff most ILS platforms don't do at all: Fair scheduling that prevents staff burnout. School partnership tracking with impact reporting. Emergency operations with offline mode and paper backup procedures. Semantic search using vector embeddings. Equity-focused cohort tools for literacy matching and immigrant services.

Infrastructure: Dual audit logging (operational + tamper-evident HMAC), CIPA compliance tooling, Z39.50 support, EDI for vendor ordering, board and strategic planning modules.

The surface area is large, and it has grown. Counted on September 10, 2026, the backend declares roughly 4,200 route handlers across 438 modules under backend/app/api/v1, and the frontend carries 698 page components under frontend/src/pages. When this post first went up in May 2026 it said 274 API endpoints and 400+ frontend pages; the second figure is still a floor, the first is not. Those counts show scope and maintenance burden. They do not show that the workflows are reliable or usable.

Decisions I made early

AGPL, not MIT. If someone takes this code and builds a proprietary SaaS on it, the license requires them to share their modifications. MIT would let a vendor fork it, add features, and sell it back to libraries as closed-source. AGPL prevents that while keeping it free for libraries to use, modify, and host however they want.

PostgreSQL with pgvector. Traditional ILS search is keyword-based. A patron searching for "books about grief after losing a parent" returns nothing useful because no catalog record contains that phrase. Vector search understands semantic meaning. Both approaches run side by side. You get the precision of keyword search and the flexibility of semantic search.

Python/FastAPI was the language and framework choice. Libraries that want to self-host need to maintain this, and Python has a larger talent pool among library technologists than Node does. FastAPI gives you automatic API documentation, type checking, and async support without the heaviness of Django.

For deployment I went with Docker Compose rather than Kubernetes. The target deployment is a library running this on a single server or a small VPS. Compose gives you container isolation, easy updates, and reproducible deployments without requiring a DevOps team.

BIBFRAME is in the data model from day one rather than retrofitted. Most ILS platforms are layering linked data onto MARC-era architectures. l/30 supports both, so when the transition accelerates, libraries running l/30 won't need a migration.

What surprised me

The scope of a real ILS is enormous. I knew this intellectually. Living it is different. Circulation and cataloging are the parts everyone names. A working library is also event rooms and 3D printers and homebound delivery and volunteer coordination and board reports and emergency procedures. Every one of those is a module that needs designing, building, and testing.

Equity features aren't add-ons. When you design a system from scratch, you can build equity into the architecture rather than bolting it on. Fair scheduling isn't a plugin. It's how the scheduling system works. Literacy-level matching isn't a separate product. It's a property of how patron records relate to collection records.

Offline resilience matters more than I expected. Rural libraries lose internet. Storms happen. The system needs to degrade gracefully, not catastrophically. Paper backup procedures and data sync aren't exciting features, but they're the difference between "the system is down" and "we can still serve patrons."

What needs to be proven next

The next useful evidence is a bounded workflow that another person can repeat: complete a task, record where it fails, and verify that the resulting data can be exported and restored. Architectural breadth cannot substitute for that test.

The sandbox is public for inspection, but it is not a production service or a migration offer.

The code is open and the architecture is documented. The next claim has to come from observed use, including the failures.

Disclosure: L/30 and MetisLib are mine. Both are open source, neither takes real patron data, and neither is sold to anyone.