Koha: a Gift to Libraries from New Zealand

The Maori word for a gift or donation is koha. It's also an integrated library system from New Zealand. Written for the Horowhenua Library Trust (HLT), it was licensed under the GPL and is now in use by libraries around the world.

In 1999, HLT made a momentous decision. They were using a 12-year-old integrated library system (ILS) that was no longer being developed. They knew the system wasn't Y2K-compliant, and they realized it no longer fit their needs. HLT also knew that buying a new system would cost them a lot of money up front and would require capital improvements they couldn't afford to make (communication lines and gear to support the new system).

Considering all of these factors, HLT, in consultation with Katipo Communications, decided to write their own system. They then decided to release this new system under the GPL, ensuring that other libraries could benefit from the work and also cooperate in future development of the system. This decision has had far-reaching effects.

Koha was developed during the fourth quarter of 1999 and went into production on January 1, 2000. There was a brief flurry of work on the system, and it was released to the world early that year. Koha won two awards in 2000: the 3M award for Innovation in Libraries and the ANZ Interactive Award (Community/Not-for-Profit Category).

Initially, Koha was picked up by other libraries in New Zealand (many of them hiring Katipo for support). One early adopter, Mike Mylonas, caught the vision of open-source software in libraries and began to contribute to the project. Mike currently supports Koha for four private libraries, one for his current employer and three for nonprofit organizations.

It didn't take long for Koha to cross the Pacific. In the fall of 2000 the rural Coast Mountain school district in British Columbia, Canada, was looking for a solution for their library needs. They had been running a home-brew system built on Apple II computers, and it had finally died. Finding the money for a proprietary solution would be difficult (a small elementary school in New England recently received a quote for $20,000 to install a new ILS—proprietary library automation isn't cheap), so they put one of their network technicians to the task of finding a better option.

Steve Tonnesen, Coast Mountain's network engineer, came across Koha and started to evaluate it. It took him about two days to get Koha up and running. Once he had that base to work from, he starting hacking. He cleaned up the circulation interface, added importing tools and wrote a Z39.50 client for querying other libraries. Z39.50 is a standard protocol libraries use to exchange data about books. Word of this new option spread quickly, and he soon had three schools running the new system. Steve's changes went back into the main Koha system, and he became a member of the development team.

During April and May of 2002, Koha development took another big step. Project leadership always had come from Katipo, but the development team was now much more international and new development goals were being proposed. One of the first steps was the beginning of the 1.2 release cycle. These releases have focused on building basic functionality and greater stability. So far, there have been four releases in this series. New features include an installation script, a fully template-driven on-line public access catalog (OPAC), which supports both translation and customization and bundled user documentation.

Right now, development is running in earnest on the 1.4 series, which features a new database schema that supports several flavors of MAchine Readable Cataloging (MARC), the cataloging standard used by libraries. The first development release in this series (1.3.0) was made on September 24, 2002. A second release occurred in October, and a 1.4.0 release is expected to occur in the first quarter of 2003.

Koha is pretty undemanding as library systems go and runs handily on a stock Linux server. HLT is a library with 25,000 patrons at four locations and a collection of 80,000 items. They run over 1,200 transactions a day on a system with dual P3 1GHz processors and 1GB of RAM.

At the Immaculate Heart of Mary School library in Madison, Wisconsin, Robert Maynord installed Koha on an AMD 1800-based system with 256MB of RAM. Coast Mountain's systems run on 200MHz Pentiums with 64MB of RAM located in each school.

Getting Koha running in a library used to be a rather daunting task, but two easy methods now are available. The easiest method is to download the CD image, burn a copy with a CD burner and boot the new Koha server from the CD. You also can use the install script to set up Koha on your hardware.

The CD can be run as a demo system, using the included data, or it can be used as your server. If you choose to use it as your server, you will need to create a set of data files on your server's hard drive. The CD provides an interactive tool to do this.

If you'd rather install your own copy, the process is a bit more involved, but it still is not difficult. Before you get started, you should make sure some basic components are installed, namely Perl, Apache and MySQL. You'll need a few Perl modules as well, but the install script helps you take care of those. The install script has made installing Koha pretty painless. An upgrade script also has been written to help ease the burden of keeping the system up to date.

Proprietary ILS packages are expensive beasts. A larger library may pay well in excess of $500,000 US for the server, clients and software, and it still has yearly license and support fees to worry about. Once a library has bought their system, they experience a high barrier to change as well. Data is most often kept in proprietary formats from which it is difficult to export—in some cases, the data is actually “owned” by the system vendor.

As with all non-free software, customers are left at the mercy of their vendors for enhancements and customizations. Library system vendors historically have been slow to provide innovative new options. Although user groups exist for many of the existing systems, they seem to be more like mutual support groups than sources of feedback for the vendors. A worse fate is in store for those whose ILS vendor goes out of business or is bought by another vendor.

This situation presents a great opportunity for free software. It's an opportunity that's not lost on librarians either, at least not all of them. There is still a great deal of ignorance and inertia to overcome. During an interview for the 2002 American Library Association's (ALA) presidential election this past spring, the candidates were asked what were their stands on free software. One of the responses boiled down to, “We need to support standards and let the vendors work out how to provide the solutions we need.”

More encouraging signs are emerging. The ALA has an information technology interest group, which reviewed open-source software in the March 2002 edition of their journal. Some of the articles were favorable, while others expressed a lack of confidence in free software's ability to produce a viable ILS. The definition of a viable ILS seems to vary considerably from library to library.

Some of the brightest lights come from the small, but growing open-source subculture, within the library community. The best example of this is the Open Source for Libraries group, hosted at www.oss4lib.org, which maintains a news site and mailing list. usr/lib/info (www.usrlib.info) is another group with a similar focus but a less technical approach.

A number of presentations made at library conferences in 2002 offered more encouraging signs. In October 2002, Chris Cormack (one of the original Katipo developers of Koha) was at the Ohio Library Conference to talk about what we've done and where we're going. Open-source software also got on the program at the Michigan Library Association Conference, the British Columbia Library Association Conference and Access 2002, a Canadian conference on internet-based technology for libraries.

Perhaps the greatest indicator of our success is that libraries have started to sponsor the development of features they feel are important. Sometimes this patronage is direct, as with Nelsonville Public Library, which contracted with one of the core Koha developers to finish work on its internal use of MARC. In other cases, the link is less direct, as is the case with recent work done by another developer being paid by a library automation vendor to develop a Koha solution for the vendor's customer.

Librarians espouse many of the same ideals that drive the free software community. They collaborate and communicate; they work hard to share the results of their work with one another. They understand freedom and feel that it's an important value. That more librarians aren't actively using and evangelizing free software is an indictment against us for not letting them in on our secret.

It's important that we not think we'd be munificent benefactors, bringing a sack full of goodies to share. We can learn a lot from librarians as well. They have a number of skills that we, as a community, lack.

One of the key skills librarians bring to the table is information architecture. Librarians have spent a long time organizing information and making it accessible. If these skills could be harnessed in the free software community, we might see less duplication of efforts due to ignorance of existing projects, better cooperation between projects and easier acquisition of information by new developers and users.

Librarians also have been around as a group much longer, and they are fixtures in the academic community as well. This presence, and the established connections that come with it, could pay off handsomely if we used them to help spread the work of free software.

Librarians also could play a key role in creating and improving documentation in free software projects. Librarians tend to be good editors; they also have a good sense of what questions people tend to ask—the kind of thing you really want in your documentation. It also doesn't hurt that they have an expectation that documentation and support will be there. I have received personal mail (and phone calls) from librarians since my earliest involvement in Koha—writing good documentation becomes more attractive when you're faced with the alternative.

Librarians also are more likely to be involved in direct communication with end users than are most free software hackers. They are at the forefront of user-interface questions and internationalization issues. Putting that experience to work in creating user-friendly interfaces and documentation would be a great boon to most projects. Librarians also are much less forgiving of the technology; it has to run, all the time and within much tighter parameters than do a lot of other types of applications.

In recent years, open-source developers have become more political. Librarians still have a significant leg up on us in this area, however. What's more, their political ends overlap significantly with our own. Working together to help ensure open access to information, widespread adoption of free software and improved educational opportunities would be a win for both sides.

Finally, librarians tend to do a good job of engaging the public. They advertise to, interact with and provide services for our communities. They are seen as trusted sources of information, true public servants. If libraries become staunch bastions of the concepts behind free software, we gain a tremendous ally in reaching out to those who don't yet use or understand free software.

A lot of opportunities are on the horizon for Koha. As the 1.4 release series stabilizes, the developers' eyes have already targeted a number of new projects. One of the areas starting to get more attention is translations. French and German teams are already in place, and interest in Italian, South African and Spanish groups has started to build. (A nice side effect of this work is, we're gaining experience here that can help other free software projects.)

Right now, Koha is installed in libraries with collections of up to about 300,000 items. This is still on the small end of medium-sized libraries. Work to enable Koha to scale well past that is already on the drawing boards. The search tools are being rewritten to improve their efficiency and allow new searching options.

Work is also underway to build a reporting API and a number of bundled reports for Koha. These reports range from inventory checking, to financial reports and into more esoteric realms like “weeding”, or removing infrequently used items.

A bundled Z39.50 server and support for NCIP, a library protocol for handling interlibrary requests, are both in development and are being sponsored by libraries interested in using Koha. These new features will allow a Koha-based library to participate in larger library communities, including interlibrary loan programs, and to function as a solution for “union” catalogs, catalogs that integrate all of the libraries in a region.

Members of the Koha community have started a strategic discussion of what Koha needs to provide to continue to thrive. This project is hosted at www.kohalabs.com/projects/koha2010 and welcomes new participants.

So What Is an Integrated Library System (ILS)?

Resources