Investigating OSS ILS Options

tracker

Last updated September 27, 2014.

At the time of the ILS selection (2004 to 2005), some of our member libraries asked very tough questions concerning the risk of installing an OSS ILS. To answer their concerns, the IT Department did a great deal of investigation into the two available OSS ILS options: OpenBook and Koha. In the beginning we preferred OpenBook over Koha. Unfortunately, the code for OpenBook was never released so we were not able to test it. This left Koha as the only OSS solution available to us. The Evergreen project, the other main OSS ILS option today, had not even been begun development.

Originally, we had some serious reservations concerning Koha. In order to understand our apprehensions, we need to describe how Koha came into being. The Horowhenua Library Trust (HLT) – a small rural library system in New Zealand– discovered in 1999 that its old circulation system was not Y2K compatible and that commercial software was way too expensive for its budget. So Rosalie Blake, Head of Libraries, approached a local firm called Katipo and proposed they create an OSS ILS. After a lot of discussion and some trepidation, HLT agreed to commit to the project. This project became Koha. The word Koha means “the gift that keeps on giving” in Maori, the New Zealand indigenous language. Within the meaning of the word “koha” (pronounced ko-HA) is also an unspoken understanding of responsibility that this gift is to be shared and enjoyed many times over.

The HLT’s original requirements for Koha were rather basic: that it run at a reasonable speed, be easy for staff and patrons to use, have a graphic interface accessible through a web browser, and require little upgrading of hardware, and provide decent financial reporting. Sticking to the idea of OSS, Koha was written using Perl for the LAMP platform.

We first tested an early version of Koha in 2001 and found that it lacked MARC support. It also did not have an acquisitions module, had no reporting module, and the fines system was very different from how we were used to calculating and tracking fines. In 2002, Nelsonville Public Library in Athens, Ohio, scaled a major hurdle for US Koha adoption by funding a project that added MARC support to Koha. After Nelsonville migrated to Koha, we visited them to see how Koha worked in August 2004.

The trip was informative but helped us identify another big issue with Koha: slow search transaction speeds. We noticed that the response time at Nelsonville from the patron/staff clients to the servers was barely acceptable. Koha had what is commonly referred to as a scalability problem. What worked fine for a library with less than 50,000 items would not work well for a library system with 400,000 items. The main cause of this issue was that all search queries were made directly to the MySQL database. This included every word in every MARC record, patron data and all transactional data. Every search, every checkout had to be resolved through the MySQL tables. The big resource hog was the MARC Index. With databases of less than 400,000 MARC records this was not an issue, however over that limit Koha's speed became extremely slow. Nelsonville addressed the issue by running a separate search server and cached, in memory, popular search terms. CCFLS had a larger MARC database and we did not want to use a work around so we decided the best solution was to modify Koha.

Since we did not want to install software that wouldn’t fully meet our needs, and at the time did not have the staff needed to modify the code, the only available option was to hire a firm to modify Koha to eliminate the bottleneck. Eventually we found a firm to do the work for $35,000. That firm was LibLime, founded by Joshua Ferraro, a former employee of Nelsonville Public Library who had been a member of the team that implemented Koha there. Mr. Ferraro suggested we fund the integration of IndexData's Zebra indexing engine into Koha, which would be used to index and search MARC records in Koha, offloading the majority of queries from the MySQL database, relieving the bottleneck, and opening the way for larger libraries to adopt Koha. The IndexData Zebra Index had already been identified by the Koha community as the best way to fix the scalability bottleneck. Zebra was chosen because it too was an OSS product, could be used to offload catalog queries from the MySQL database, and could support MARC and a variety of other data formats. Zebra was also picked due to its successful use in other large database projects requiring a fast index.

The discovery of the speed issue with Koha caused some concern from the member libraries in the CCFLS system. There had been a great deal of disagreement between libraries when we originally selected Winnebago in 1991. More than ten years later, some of the bad feelings remained between the two camps. It manifested this time in the debate as to whether we should select an OSS ILS or a proprietary ILS. Once the libraries discovered that the “free” OSS option would now cost $50,000 ($35,000 for software modifications and $15,000 for new servers and hardware), the IT Department had to highlight other benefits to convince our libraries to buy into an OSS ILS.