Skip to content

Education, Science and Research

Georgia PINES: The Library Network That Built Its Own Software

In June 2004, Georgia’s state librarian announced a plan that could have made a technology manager lose sleep. Hundreds of public libraries already depended on one shared computer system. It held millions of book records and served more than a million cardholders. The state wanted to replace it with software of its own.

Not a small add-on. Not a new website painted over the old system. An entirely new program to handle the work behind a library counter.

Lamar Veatch’s announcement even had a backup plan. If the developers had not made enough progress after one year, Georgia could still seek a commercial replacement. That was a sensible precaution. A library cannot simply stop checking books in and out while someone finishes the code.

The gamble worked. On September 5, 2006, 252 Georgia public libraries began using Evergreen, a new open-source library system built for the network called PINES. Its creators were software specialists working with librarians, not librarians mysteriously turning into programmers overnight. But the people behind the counters helped decide what those programmers would build.

And one of the team’s best design questions was wonderfully simple: What would you ask for if the software could do anything?

The Network Came First

The names are easy to mix up. PINES is the library network. Evergreen is the software that later came to run it.

PINES stands for the Public Information Network for Electronic Services. It began in Georgia in 1999, partly as an answer to the Year 2000 computer problem. At the time, public libraries did not all have the same tools, staff, or budgets. A statewide system offered a way to share the cost of keeping track of books and borrowers.

There was a bigger idea behind it: one library card could work at participating libraries far beyond a person’s home town. A small branch could help someone find a book held somewhere else in the network. A shared catalog turned many separate collections into something closer to one large collection.

The first stage brought 98 libraries into the system. A second stage added 111 more. Georgia used a commercial library system called Sirsi Unicorn to make this possible, and it did important work. Without that first system, PINES would not have reached the scale that later made Evergreen necessary.

By 2004, PINES had grown to 44 public library systems and 249 libraries and bookmobiles. It had more than 1.3 million registered patrons and access to over 7.7 million items, according to Veatch’s June 2004 announcement.

Illustrated map of Georgia with small libraries connected to one shared book catalog and library card
Editorial diagram: PINES linked participating Georgia libraries through a shared catalog and card. It was a network of libraries before Evergreen existed.

That matters because the famous 2006 date was not the birth of the network. It was the day the network changed the software under its feet.

When a Good System Was No Longer Enough

Picture the request from a local branch. A patron wants a book that sits in a library several counties away. Staff need to find the right copy, place a request, follow the book between branches, and know when it can be picked up. Meanwhile, other people are borrowing, returning, renewing, and placing holds on millions of items.

None of this is especially dramatic at one checkout desk. At the scale of PINES, it becomes a hard software problem.

Unicorn was a real, working product. The trouble was fit. Georgia kept asking a system built for more conventional library arrangements to handle a huge group with shared rules and shared resources. The state had already made extensive changes and built extra tools, including web-based reports.

Veatch wrote that the libraries needed a system more flexible and able to grow. His announcement describes vendor demonstrations, technical reviews, and talks with library staff before the decision. The team did not reject every commercial option without looking.

A later GPLS white paper from 2009 adds an important detail: Georgia had been told it could not add more libraries under the existing Unicorn setup. Staff examined other products and concluded that the available choices did not meet the network’s needs well enough.

So the choice was not simply between expensive software and free software. It was between letting a supplier’s design set the limits of Georgia’s library network and attempting to make a system that followed the libraries’ own rules.

Behind the Scenes: A Plan With an Escape Hatch

The June 2004 plan estimated 18 to 24 months for development. It also promised a check on progress in June 2005. If the new system looked unlikely to be ready, the state could seek bids from vendors instead.

That small clause tells us a lot. Georgia was serious about open source, but its public libraries still had to open their doors the next morning. Read Veatch’s original announcement.

“Pretend It Is Magic”

Software projects often begin with a list of what the old program already does. The Georgia team wanted something better than a list of old screens with new colors.

They traveled around the state to hear what people actually needed. In a 2008 interview in Library Technology Reports, a project team led by PINES program director Elizabeth McKinney de Garcia described forums followed by ten focus groups in summer 2004. They sought input from a library community of roughly 2,500 staff members and others.

At first, participants tended to ask for things they already knew a library program could do. One developer offered a way out of that trap: “Pretend it is magic.”

Forget the current buttons. Forget the old software’s limits. What should happen when a reader needs a book, or a librarian needs to fix a record?

That is the most revealing line in this story. The developers were not asking ordinary staff to learn the details of database code before speaking. They were asking the people who did the work to describe the work as it ought to be.

Four programmers formed the development group. A 2006 Georgia Public Library Service announcement identified Brad LaJeunesse (Linux systems administration), Jason Etheridge (support and interface development), Mike Rylander (database development), and Bill Erickson (systems development).

The people who would use the software were spread across Georgia. The developers were based around Atlanta. Email lists, online discussions, test systems, and a project wiki helped bring the two groups together. Library employees also tested the program as it took shape.

Fictional Georgia public library meeting table with librarians discussing borrowing and catalog needs
Editorial reconstruction of a 2004 library software planning discussion. The original PINES team held ten focus groups; this is not a photograph of a documented meeting.

The result was not that every wish appeared in the first release. It was that the project began with a better picture of the work.

What Evergreen Had to Do

A library management system has a less glamorous job than its public catalog suggests. It must know which copy of a title belongs to which branch. It must record loans and returns, protect patron accounts, process requests, and let staff correct catalog records. If it fails, the trouble soon reaches the front desk.

Evergreen combined this behind-the-counter work with a public web catalog. When Georgia announced the 2006 launch, it promised cover images, reviews, tables of contents, and easier searching. These features were meant to help people find books in the enormous shared collection.

It also needed to cope with different libraries sharing one system. A small rural branch and a much larger library might operate under different local rules. They still had to exchange books without maintaining completely separate computer worlds.

Underneath, Evergreen used Linux and an open-source database, PostgreSQL. Its service framework, called OpenSRF, helped different parts of the software send requests to one another. The system used a messaging method related to Jabber, an instant-messaging technology. That sounds odd until you realize the servers, like people on a chat network, needed to pass messages back and forth.

The technical purpose was practical. Work could be spread across ordinary servers rather than depending only on ever-larger, costly machines. Evergreen’s own OpenSRF technical documentation explains this design.

Open source was another choice with a practical result. Under its free-software license, other libraries could inspect, use, and improve Evergreen’s code. Georgia would not be the only organization that could decide how the program should grow.

But free code is not free labor. Someone must install it, maintain servers, move records, train staff, and answer calls when things go wrong. Evergreen removed some licensing barriers. It did not remove the need for skilled people.

A Rather Unusual Use for Instant Messaging

The Evergreen team’s 2008 interview pointed out that its back-end system used the Jabber messaging protocol to let servers talk to each other. It was a clever use of technology more often linked with human chat. The OpenSRF explanation shows why it suited a system with many services.

The Long Weekend When 252 Libraries Changed Systems

By August 2006, the decision had turned into a deadline everyone could understand: the Tuesday after Labor Day.

In its August 21 announcement, GPLS said PINES libraries would close over the holiday weekend to migrate to Evergreen. They were preparing to open on Tuesday, September 5, with the new system.

This was a network-wide switch, not the slow creation of PINES one branch at a time. The 2006 announcement counted 252 public libraries across 123 Georgia counties, more than eight million items, and over 1.6 million registered cardholders. The figures describe that time, not PINES today.

The old Unicorn-based system was being replaced by Evergreen for circulation, cataloging, and the public catalog. Participating libraries had to return to work able to handle the same essential tasks. Readers, for their part, could expect a different catalog on the screen.

Some things were designed not to change. GPLS specifically reassured people that their existing PINES cards would keep working. They did not need to visit a desk and sign up all over again just because a new program had arrived.

Fictional 2006 library return desk with a card scanner, beige computer, books and transition checklist
Editorial reconstruction of the 2006 changeover. PINES libraries closed over Labor Day weekend and reopened on September 5 using Evergreen; the pictured workstation is fictional.

What exactly happened in the computer room each hour that weekend? The public announcements confirm the closure, migration, launch date, and library-wide scope. They do not provide a full minute-by-minute conversion log. It would be easy to invent a heroic midnight scene. The surviving records do not justify one.

What can be said is remarkable enough. A publicly funded team replaced the central software for a very large shared library network on a planned date, while keeping the network’s familiar library cards and mission.

Two Dates, Two Different Stories

1999: PINES began as Georgia’s shared library network, using commercial software.

September 5, 2006: Evergreen went live across the existing network.

Saying PINES was “founded in 2006” erases seven years of library cooperation that made the Evergreen project possible.

A Local Solution Finds a Wider Audience

Evergreen was unusual because it started at such a large scale. In October 2006, library technology analyst Marshall Breeding wrote that open-source library systems still had only a small place in the market. Georgia’s successful switch gave other librarians something concrete to examine, not just a software proposal.

That interest created a new problem: people outside Georgia wanted help using the code. The core team could not spend its working days supporting other states and countries while also serving PINES.

The original developers went on to establish Equinox Software in 2007. GPLS then contracted with Equinox for services that included system administration, development, support, and training. In other words, open-source code and paid professional service could live side by side. The July 2007 contract announcement records that arrangement.

The project also won a 2007 Mellon Award for Technology Collaboration. Georgia’s own library records describe a $50,000 grant to support further development, including work on acquisitions and documentation.

Evergreen did not become the only open-source option for libraries. Koha, which began in New Zealand before Evergreen, had already shown that libraries could use freely shared management software. But Georgia provided a striking example of an especially large public library consortium making the switch together.

As more libraries adopted Evergreen, work continued on features that the 2006 version had not yet finished. That is another difference between a software launch and a finished story: a functioning first release is the beginning of years of upkeep, requests, and improvements.

The Library Card That Stayed

The story has not ended in a museum display. On its current About PINES page, the Georgia Public Library Service describes a network of about 300 libraries and affiliated outlets in 52 library systems, covering 146 counties. It reports a shared collection of about 10.6 million items.

GPLS also estimates that the shared system helps Georgia libraries avoid about $10 million each year in software spending. That is the agency’s estimate of savings across the library network, not a measured profit earned by Evergreen or proof that the software costs nothing to run.

The same agency says Evergreen is in use at more than 1,500 libraries worldwide. Such figures can change, and different sources count branches, outlets, and library organizations in different ways. The larger point is clear without pretending to know one perfect total: code first written for Georgia spread far beyond Georgia.

What makes the origin special is not that librarians hated vendors or that four programmers worked a miracle. The state had already built a shared library service. When the program behind it could no longer keep up, Georgia let the people who knew that service help shape a replacement.

The best result was almost invisible. A patron could keep the same card, visit a local branch, and ask for a book that might be sitting far away. Behind that small request was an ambitious piece of public software, built because librarians refused to accept that the limits of a computer system had to become the limits of a library.

Sources and Further Reading