Platform Is Relationships: Voyager, KLN, and the Consortium That Grew Beyond Itself

1. Context

By the mid-1990s, the Keystone Library Network had already proven that fourteen Pennsylvania state universities sharing infrastructure could afford things no single institution could justify independently. The shared economics worked. But KLN was more than a cost-sharing arrangement — it was a set of relationships: libraries that talked to each other, solved problems together, and trusted shared systems with their core operations.

That relational foundation is what made everything else possible. Not just the technology, but the adoption of the technology.

2. The Platform Before the Software

KLN began as consortium economics: shared database subscriptions, shared hardware, shared network costs. But the first real test of whether the consortium was a platform — not just a billing arrangement — came with remote patron authentication.

Students needed off-campus access to licensed databases. The standard answer (IP-range whitelists) only worked on-campus. A proxy server per institution would have multiplied cost and created single points of failure. The only scalable answer was federated: authenticate the patron against their home library's system, return a credential the consortium could honor, handle the complexity centrally.

The Remote Patron Authentication System (RPAS) did that. It was built on the insight that the patron's identity was their library card — their relationship to their home institution — not their IP address. Once that trust model was right, the technical implementation followed.

3. The Migration Problem

As the library technology market consolidated around Endeavor's Voyager ILS, KLN and its member institutions faced migration from PALS — the Program for Automated Library Systems, a legacy mainframe-based ILS that had served a number of Pennsylvania universities, among other institutions. Three of KLN's members were PALS sites. Their data — bibliographic records, patron records, decades of circulation history — lived in proprietary mainframe formats on Unisys hardware. It needed to move to a relational Oracle database on Sun Solaris.

No vendor-supported migration path existed. The data formats were different, the platform architectures were different, and each institution's records carried local variations accumulated over years of independent operation.

4. Why Existing Thinking Failed

The standard migration approach — manual data cleanup, bulk import, fix problems as they surface — does not scale to millions of records across institutions whose data practices diverge in ways nobody had cataloged. Manual cleanup is appropriate for small, known datasets. It is not appropriate for a migration where every institution's records reflect a different local history.

A one-time conversion script, run once and discarded, would leave each subsequent test run requiring from-scratch effort. It would also leave no audit trail — no way to connect a problem discovered after import back to its source in the original data.

The deeper failure mode was institutional: if the conversion work lived only in one place, at one institution, then every other PALS site that needed to migrate was starting over. The consortium's value — shared infrastructure, shared knowledge — would not apply to the migration itself.

5. Approach: Build a Tool, Not a Migration

The decision was to build the conversion as a repeatable, inspectable pipeline rather than a one-time script.

The software needed to:

Parse PALS mainframe export formats reliably, including edge cases accumulated over years
Transform records to Voyager's data model while preserving source information for audit
Produce import-ready output that could be validated before being loaded
Run cleanly against new source extracts as data changed during the transition window

That design made the tool shareable. A PALS site at another institution, or in another state, would face the same source format, the same target format, and most of the same edge cases. The per-institution cost of migration dropped significantly because the hard work of format parsing and transformation logic did not need to be repeated.

Running concurrently with the migration was WebAdmin: a secure web-based administration tool for Voyager that let library staff schedule and monitor bulk processing jobs — import, export, reporting — without requiring direct system access or dependence on hub staff to run jobs on their behalf. Empowering local institutions to manage their own workflows, without needing to ask a central consortium member for help, was itself a platform design decision.

6. What the Consortium Made Possible

The conversion tools were used by Shippensburg University, Bloomsburg University, and a third PALS site in Pennsylvania. They were also used by the University of Georgia system and other PALS institutions nationally.

That spread did not happen because the software was marketed. It happened because the consortium had relationships — with peer library networks, with vendor communities, with the professional organizations where library technologists compared notes. The Voyager User's Group Meeting in Chicago in April 1999 was one of those venues. Presenting there turned local development into shared community infrastructure.

WebAdmin's path was similar, but steeper: Endeavor Software incorporated it into their released Voyager product. A tool built to solve an operational problem at Shippensburg became part of the vendor's commercial offering, distributed with every Voyager deployment. That happened because the work was visible to the vendor through the same relational channels — user groups, conferences, direct collaboration — that had enabled everything else.

7. Outcome

Three PALS institutions in Pennsylvania and the University of Georgia system, among others, used the conversion tools. Every Voyager deployment received WebAdmin as part of the commercial product — the same tool Ex Libris still documents as Voyager WebAdmin in current Voyager releases, decades after Endeavor incorporated it. The RPAS served patrons across fourteen institutions and was adopted by Silver Platter for broader distribution.

The Keystone Library Network recognized the work with its Award for Excellence from the State System of Higher Education in 2000.

None of these outcomes were achievable by building software alone. Each required a platform in the fuller sense: shared infrastructure, trust relationships, professional community, and the organizational will to solve problems at consortium scale rather than institution scale.

Perhaps one of the most personally transformative outcomes happend a few years later. I was at a social event and in the course of the conversation, the young mother I was talking to discovered that I was responsible for the RPAS system. She explained that when her child was born, she was just finishing her master's degree, and that enabling her to dial in (it was 1999) after her baby fell asleep enabled her to spend time with her new baby and complete her degree and start her career. That moment has stuck with me for these nearly 30 years, and continues to drive how I view the impact of my work - that the power of the solution doesn't depend on the slick technology but on who it enables.

8. Lessons That Generalize

A platform is relationships, not just architecture. KLN's technical infrastructure only mattered because the consortium had already built the organizational relationships that made sharing possible. The software followed the trust model — it did not create it.

Empowering local institutions scales better than centralizing capability. WebAdmin was a deliberate choice to give individual library administrators control over their own workflows rather than routing every bulk job through hub staff. The platform grew more capable as it distributed responsibility.

Tools built for local problems generalize when designed with care. The PALS-to-Voyager conversion tools spread beyond KLN not because of a distribution plan, but because they solved a real problem reliably and the consortium had the relationships to make them visible to peers who needed the same solution.

Good platforms grow beyond their original use case. RPAS started as a KLN-internal authentication system and ended up in Silver Platter's product. WebAdmin started as an operational convenience and ended up in every Voyager installation. That kind of growth is a signal, not a coincidence — it happens when the underlying design is sound and the relational infrastructure to distribute it exists.

Vendor adoption is the most credible validation. When the vendor of a commercial system incorporates independently developed tooling into their release, it is because the tooling solved a real problem better than what they had built. That is a higher bar than any internal review.