March 18, 2018

Open Source Reality Check

Implementation experience reveals pros and cons

In 2009, East Brunswick Public Library (EBPL), NJ, switched from a proprietary integrated library system (ILS), SirsiDynix’s Horizon, to an open source Koha ILS. In 2010, it switched back.

When the library moved to open source, a lot of factors went into the decision, according to Christopher Hyde, East Brunswick’s current IT manager, including economics. SirsiDynix wasn’t developing certain features that the library was interested in, or quoted prohibitively expensive prices for them, Hyde says. The library at first looked into another proprietary option but eventually decided that an open source ILS—in this case, Koha—offered more flexibility at a lower price.

But the next year, EBPL went back to Horizon. The decision was spurred in part by slow checkout times in its circulation module; furthermore, some features it had paid to have developed had ended up causing data problems.

“It wasn’t where we needed to be when we went live with it,” Hyde tells LJ. “We were kind of using, basically, a beta product.” It was requiring a lot of work and time to deal with such problems—so, in the end, the library went back to the product it knew well.

It’s not the usual story that one hears about open source ILSs. Indeed, hundreds of libraries have had fruitful experiences with Koha or the widely used open source Evergreen ILS. But, as anyone will tell you, the reputation of the open source ILS as an unalloyed solution to library problems—a sort of “magic bullet”—is worth examining.

Two major advantages often trumpeted by advocates of the open source ILS are its customizability and its affordability. Both notions are appealing to libraries, especially in cash-strapped times. But a migration to a new ILS is a complicated undertaking—whether proprietary or open source—and unexpected difficulties, such as costs and support issues, can arise.

LJ talked with several librarians about their experiences with open source ILSs to find out why and how they took the plunge—and their encounters are instructive.

ljx110801webRapp1(Original Import)
Staffers (l.-r.) Matt Carlson, Bradley Bonner, and Lisa Hill of King County Lib. Syst., which went live with an open source ILS in September2010

A lot of work, but a lot of control
The open source Evergreen ILS is widely used across the United States, having been first created by the Georgia Public Library Service for the 270-member Public Information Network for Electronic Services (PINES) consortium, which went live with Evergreen in 2006. It’s now used by hundreds of libraries, with companies such as Equinox providing ­support.

One of the most notable examples of an Evergreen migration, and one observed intently by open source watchers, is King County Library System (KCLS), Issaquah, WA—the 2011 Gale/LJ Library of the Year (“The People’s Library,” LJ 6/15/11, p. 24–27) and the highest-circulating library in the United States. It is by far the largest single library system to go open source—and it’s been a tough nine months.

In 2009, the Institute of Museum and Library Services awarded KCLS—along with Ann Arbor District Library, MI; Peninsula Library System, San Mateo, CA; and Orange County Library System, Orlando, FL—a $998,556 (match $1,014,400) grant to develop infrastructure components to help libraries looking to migrate to an open source ILS. In September 2010, KCLS switched on its own highly customized Evergreen ILS, contracting with Equinox for support and development. “The migration is going better than I could have ever anticipated, and at the same time there’s a ton of work to do,” Jed Moffitt, KCLS’s IT services director, told LJ at the time.

When LJ spoke to Moffitt again in July 2011, it was apparent that “a ton of work” had indeed been needed—and a lot had been done. “My first reaction is, ‘I can’t believe I ate the whole thing,’ ” Moffitt says.

Moffitt tells LJ that KCLS went live in September with a “subfunctional” system, owing in part to having to meet a target date for launch. The library hit that date but missing were many features of its previous proprietary system, Innovative Interfaces’ Millennium ILS. Many patrons had difficulty remotely accessing the system, performance slowed, and cataloging and processing functionality still needed a lot of work.

As a result, there were hundreds of complaints from patrons and staff—so many, in fact, that they even prompted a January 2011 Seattle Times story. Staff adapted but have expressed their frustrations to Moffitt. Moffitt says that many major issues have now been resolved but that there remains a lot more work to do. He uses the metaphor of the Battle of Normandy during World War II: “I think it’s safe to say that here at nine months out, we’re well established in France, but we’re still far from Berlin.”

With so much work involved, is a move to an open source ILS worth it? It depends on a library system’s goals and aims and the ability—and resources—to put in the work required.

According to Moffitt, KCLS had two key criteria when it came to installing a customized Evergreen system. First and foremost, the library wanted to have more control over its applications and services. Moffitt points out that many proprietary vendors lack the incentive to do custom work or features for a single library or library system.

He likened that vendor-library dynamic to “a bad parent-child relationship,” saying he disliked having to respond to patron or staff feature requests with, “‘I’ve asked Mom, and she said no.’” With an open source system, he says, “we were Mom”—and the ability to deliver a new feature no longer hinged on outside approval but on technical capacity and resources. Though being “Mom” does bring new responsibilities: the library is perhaps under greater pressure to make good on promises than it would be ordinarily.

Second, KCLS aimed to install an open source system for about the same price as it would cost to repurchase Millennium. So far, he says, KCLS is on budget. Support costs for Evergreen are about 70 percent of its former Millennium support charges, he says, and combined with other expenses (including elevating a staff member who became an Evergreen expert), the tab for the new system is about the same as the old one. Moffitt notes that a library should not expect to save “tons of money” by using an open source ILS. “If you’re a director, and you want to cut your costs by 50 percent, don’t do it,” he says.

While it has required an inordinate amount of work to approximate the functionality of a proprietary ILS, Moffitt says the library has more control over those functions, giving it other advantages, too. For example, Moffitt says, a library could conceivably create its own self-check stations without having to pay additional licensing fees to an ILS vendor.

“It looked much easier”
KCLS’s experience shows that a lot of work can be necessary for an open source migration, especially for a large-scale library system. But LJ spoke to a few smaller systems that have had less rocky experiences.

For example, at La Conner Public Library, WA, about 75 miles north of KCLS, an Evergreen migration was far less eventful, likely due to having fewer moving parts: it has an annual circulation of just 38,000, compared with KCLS’s 2010 circulation of 22.4 million. Wishing to migrate from a proprietary ILS, InfoCentre (now owned by Follett), designed for a school library—in part because it could not generate needed reports—La Conner’s library director, Joy Neal, looked into Evergreen.

La Conner, along with the nearby Burlington Public Library and Upper Skagit Library District, went in on a single Evergreen installation. Hosted on the Burlington server, the ILS went live this past March. Even with Equinox support and another agency hosting its catalog, the costs are still less than an equivalent proprietary ILS installation, says Neal. The switch was so smooth that the library has only received two complaints; most patrons “are thrilled with the new features it has over InfoCentre,” she says, including emailed reminders of books coming due or of holds ready for pickup.

Open source ILSs can also have advantages for catalogs with specific needs. MassCat, a Massachusetts-based online catalog that serves a range of primarily school and special libraries, went from a proprietary tool (Auto-Graphics’ AGent), for which the library did not have a circulation module, to Koha in 2008. According to MassCat manager Nora Blake, many schools had found that proprietary school ILSs were too expensive for their budgets, so Koha, as a group effort, was seen as an economical option.

Blake says that the portability of an open source ILS also was appealing. “If we didn’t like our [support] vendor, we could switch vendors without learning a whole new system,” she says. Indeed, MassCat did end up switching from LibLime to ByWater Solutions in early 2011, with little effect on service to its patrons—a far less painful process than replacing an ILS entirely and convenient for a system with no dedicated ILS developers on staff.

The best fit?
Rogan Hamby, a systems administrator and librarian at Florence County Library System, SC, and a 2011 LJ Mover & Shaker, is also the administrator of the South Carolina Library Evergreen Network Delivery System (SCLENDS), a consortium that includes one-third of the state’s county library systems and the State Library of South Carolina. All use a shared Evergreen ILS, with facilities migrating from a wide range of proprietary ILSs by companies like SirsiDynix, Polaris, The Library Corporation (TLC), and Follett. (SCLENDS also contracts with Equinox for support.)

Like other IT staff whom LJ interviewed, Hamby cites Evergreen’s flexibility and large, independent development community as factors in the migration decision. He adds that open source software needs a growing community behind it, or new users can be left in limbo. “Libraries are fortunate to have two open source ILSs with large, vibrant communities and thriving support companies, Koha and Evergreen,” he says. (As it made additions and adjustments, KCLS has also been sharing its new code with the larger open source community.)

However, Hamby is not blindly an open source evangelist: “You can’t look at open source software as a whole category any more than you can look at commercial as a category,” he says, adding that he has used both open source and proprietary software depending upon what worked best for his organization. “Just as there are good and bad companies with good and bad products, there are good and bad open source projects with good and bad software packages,” Hamby says.

The effectiveness of an ILS depends in large part on the needs and expectations of the library that uses it. The trick for libraries is finding the best fit. The majority of libraries that use ILSs, after all, use proprietary ones, while others swear by open source. In the end, there may not be a magic bullet for libraries, but there are plenty of options.

Author Information
David Rapp is Associate Editor, Technology LJ


Open source code in libraries is nothing new and is an integral part of many systems—though some libraries may not even be aware of it. “I know libraries that say they don’t use open source, and then I find half a dozen open source packages like Apache [web server software] on their Windows servers,” says Rogan Hamby, administrator of the South Carolina Library Evergreen Network Delivery System.

For years, ILS companies have been bringing significant open source elements into their products. For example, since 2008, library automation company VTLS has been working with New York’s Queens Library, the 2009 Gale/LJ Library of the Year (“The Politics of Excellence,” LJ6/15/09, p. 28–31), on the library’s daVinci Open Library Platform. The platform includes heavily customized components created by both VTLS and library staff and features many open source–based elements, including a Drupal-based content management system, an Apache Solr search platform, a MySQL database, and Fedora Commons digital asset management. Queens Library’s daVinci ILS went live in January 2011.

Open source code also makes it possible for independent development communities to form, in which those with the requisite coding skills work to improve or add functionality to the code and then share that code with the larger group of users. Usually, a core of developers contribute the bulk of revisions, but others are encouraged likewise to contribute if they have identified a desired enhancement and have the expertise required to build them.

There’s something of a middle ground, as well, for those not inclined to rework major elements of a system: in the proprietary world, though core code is often kept under wraps, several companies have opened their application programming interfaces (APIs) to allow users to access data via user-created applications. For example, when Darien Library, CT, migrated to a Polaris ILS late last year, the ability to support the open source catalog interface SOPAC 2 was a key consideration. Polaris gave the library access to the ILS’s API and SQL database, which allowed Darien developers to improve SOPAC integration significantly.

The trend toward more openness is spreading. In April, Innovative Interfaces announced its new ILS in development, the Sierra Services Platform. It includes a PostgreSQL database and Apache Lucene index, both open source components. Although development of the ILS will remain in-house, the company is also planning an online “Developer’s Sandbox,” including tools for outside developers to test applications against Sierra APIs, as well as a “Developer’s Community.” Twenty-five academic and public libraries signed on in July as development partners or early implementers of Sierra. OCLC’s Web-scale Management Services offers open APIs to create and share apps, and Ex Libris’s in-development Alma library management services will also allow libraries to develop their own adapters and plug-ins.