WebJunction

On September 2, 2003, the Nelsonville Public Library, a medium-sized system of seven libraries serving the 60,000 residents of Athens County, Ohio, started using a new integrated library system. While libraries switch to new ILS software all the time, there was something very different about this event: NPL is the first public library in the world to use the MARC version of Koha, which is open source. That makes NPL's rollout of our new system a significant milestone in library technology.

The Koha website (www.koha.org) contains lots of information about the Koha software, but basically it is an open source integrated library system for automating a lending library. It has all of the basic features needed to run a library, handling:

* an online public access catalog (OPAC) of the library's holdings;

* a database of library users;

* issuing books to borrowers and returning books to the collection;

* borrower requests for library items;

* orders from vendors;

* book budgets;

* transfers between library branches;

and most other functions associated with operating a lending library. Koha version 2, which is what NPL is using, supports MARC21 and UNIMARC bibliographic records.

As you might expect, NPL found that blazing the trail to Koha was a long and arduous process. It started more than two years ago, when we began lurking on the Koha mailing list to get a feel for Koha's capabilities and potential problems. By January 2002, we had seen enough to pull together a "tech team" consisting of the library director, the assistant director, our webmaster, our systems administrator, and our circulation software supervisor. We decided to embark on an experiment: Could we switch all of our automation software, from operating systems to web tools, to open source by the end of this year? We decided that there was no "success" or "failure" involved, just a simple research question with a "yes" or "no" answer. No matter the outcome, we would have gathered a lot of information, and we made plans from the very beginning to share this information with the library community.

The thing that initially drew us to Koha was freedom. We want to use our Web site (www.athenscounty.lib.oh.us) to offer some cutting edge information services to our library users, but we realized that this would require us to have control of our automation and database software. We needed the freedom to change things, to change the code if necessary, because the types of things we want to do are not going to appear in commercial library software for years. (Commercial library software vendors are more interested in the bottom line than the cutting edge.)

Note that while many people refer to open source software as "free" software, it is best to think of it as "free to change" rather than "free of cost." It is possible to set up a functioning Koha system without spending any money, but you would still spend more time on the implementation than you would with a commercial ILS (where you are paying the software vendor to set it up for you), and you would need to have a pretty fair knowledge of web server software (usually Apache), the Perl programming language, and MySQL in order to configure some parts of Koha. So there is still a significant investment required to get Koha working. That being said, Koha is still much less expensive than commercial library software, especially when you consider that there are no annual license fees.

So what sort of problems did we spot as we first researched Koha? The first was the irregular pace of development. Since Koha code development is a "spare time" activity for most of the programmers, the pace of Koha's growth is hard to predict. We found ourselves waiting for crucial modules to be developed, sometimes wondering if they ever would be developed, often suspecting that the answer to our original research question would be "no" - we couldn't switch to a completely open source system. The second was the problem of "splintering." If we took the developing Koha code and finished it to fit our needs, hard-coding the features we needed and leaving out things we didn't need, we would have in effect created a new version of Koha that had departed from the main development tree. That would have meant that we could not take advantage of future upgrades to the main tree. On the other hand, if we mustered our patience and waited, would Koha ever have enough of the features we needed to be a viable automation system for our library? This is a significant problem: How do the programmers know what the majority of libraries will need, and how do libraries know if Koha will eventually have all the elements that are considered crucial?

Our answers came from looking at the history of Koha. Koha was commissioned by the Horowhenua Library Trust in New Zealand to solve a Y2K problem with their commercial system. (The vendor had gone out of business, and the code was closed, so there was no way to fix what they already had.) When HLT first commissioned Koha, they decided to make it open source hoping that other libraries would step in and support development of new features as they were needed. The name of the system, "koha," is a Maori word that means "gift." However, a koha is not just a simple gift that is given away, but a gift that is given to someone (usually upon visiting their home) with the expectation that you will receive a return gift on some appropriate occasion in the future. And that, of course, is also the way the open source community operates -- things work best when the participants give as well as receiving.

It's important that libraries do not look on open source as free software that they just download, press a button, and all their problems will magically be solved. As has been already noted, libraries should approach open source with the notion that they will commit a lot of staff time to understanding the code and how the software does its job. They should also be ready to commit financial resources, just as if they were still paying annual license fees for commercial software. The difference is, with commercial software a big portion of the license fee goes to research and development over which the library has no control, while with open source that same money can fund the development of the software modules that the library really wants. HLT paid their money and received a product that works fine for their needs. We eventually came to realize that this meant other libraries could pay a little more money and receive enhancements to that product that would make it fit their needs -- without having to pay for the development of an entire software package. The libraries would be paying a one-time expense that would probably be less than their annual license fees, so they win. The programmers get a very clear idea of what libraries want (money talks!), so they win. It's a great model for success!

As we watched Koha develop, and while our own ideas about the relationship between libraries and open source were developing, a significant milestone was the release of Koha 1.2.0 in July 2002. For the first time, we saw a product that looked like a viable alternative to our current software. In late August, we held a day-long meeting of the tech team to review everything that we had seen and learned so far in our research project, and we decided that Koha lacked only three important things for our needs: full MARC support, a Z39.50 server module, and a SIP2 or NCIP module, in that order of importance. To fill those needs, we decided to commit some financial resources to Koha development and released an RFP to the open source community for implementing MARC21 support in Koha. Typically, we found that we had not been thinking big enough -- the RFP we eventually accepted provided MARC21 and UNIMARC support, with provisions built-in to allow the code to be adapted to any other 'flavor' of MARC that libraries around the world might prefer. This work became the foundation of Koha version 2.0, which should be officially released in the very near future. We have developed our own Z39.50 server module, using the open source 'yaz' toolkit (of course), and will tackle NCIP next, to extend our current sharing capabilities.

Our transition to Koha then began with moving some of our old data into Koha to see how it behaved. We originally thought we would use a database consultant to assist in moving our data. (This is a task that's typically handled by the "new" software vendor when libraries switch from one commercial product to another.) We eventually realized, however, that the mechanics of the data transfer were not as difficult as identifying which data we wanted to keep and which was superfluous, and those were decisions only we could make. For that reason, we did the data transfer ourselves. Once we had a little of our data transferred and working, we then entered a long phase of debugging, finding mistakes in both the code and our data. We also learned by experience how Koha would handle our data and how our data would behave in Koha, and made changes to both to get what we wanted. Then we transferred the rest of our data and ran Koha in tandem with our old circulation system. This not only allowed staff to get familiar with the new system, it also gave them an opportunity to request changes to screens, customized functions, etc. Once we felt that Koha was "good enough for starters," we shut down the old automation system.

Was it the right thing to do? We think so. Frankly, after experiencing the sensation of having total control over our software, we could probably never go back to a commercial system. In just one month of use, staff have already become accustomed to requesting changes and enhancements and seeing their requests become reality in just a few days -- something that just does not happen with commercial software. We've been able to do things with our new system that we've wished for years we could do with our old system. It's an addictive experience.

Are there things that could be improved in the basic Koha code? You bet! We have already been in discussions with some of the primary Koha developers about some exciting new changes to the search engine -- but that work won't start until after Koha 2.0 is released. And there will always be other things to improve. But the ability to change and improve is one of the real strengths of open source software.

Was our money well-spent? Well, we will "break-even" on Koha in about 18 months, if you are looking just at the amount of money we spent on Koha development in relation to the amount of money we were spending on annual license fees. If you also try to figure in the cost of our training and the time staff spent installing and implementing Koha, the formula becomes more complicated. While this cost was undoubtedly high, it pays off every day in our ability to modify our system to do what we want it to do -- and that's something that's priceless.

Within the next few years, we fully expect that our web site will offer some of the best online library services available anywhere in the world. That's the value we expect to get from investing in Koha