WebJunction

In 1999 New Zealand's Horowhenua Library Trust had a library system that had been used and loved for 12 years. It was simple to operate and ran fast at our branch libraries over an ordinary dialup modem. But it was looking tired, and we were pretty sure the networking system wasn't going to stand the challenge of Y2K.

We started the time-honoured procedure of searching for a new system. As we read through the 25cm high pile of paper that resulted from a (very selective) RFP, we got more and more depressed. It wasn't just that the new offerings were expensive to purchase: the real killer was in the running costs. The support charges were a steep increase, and added to that was a huge 500% increase in telecommunication costs every year, stretching relentlessly into the future.

Now, along with every other red-blooded librarian, we resented sacrificing a huge chunk of a hard-won budget to a telco. What to do? January 1^st 2000 was approaching much too fast for comfort.

One possible solution was suggested by Katipo Communications, a company that had worked with the Library for many years, advising, training staff and supporting library networks. They watched the RFP process with interest, read the documents, and commented "You could do this using the Internet, and that would at least take care of the telco costs".

Katipo had already done an OPAC for Wellington City Library, and lots of database work, and thought (naively?) "How hard can it be to write a new library system?" They offered a proposal.

Horowhenua Library Trust is run by a Board of Trustees, composed of remarkably flexible people. They looked at the spectre of failed software commissions, weighed up the pros and cons, and decided the gamble was worth the risk. We'd give it a shot.

The mission was to have a new system running in the library for the first day of business in 2000. The requirements:

• At the branches it should issue and return at least at the same speed as our old system;

• It should require minimal upgrading of the libraries' existing equipment, (a motley collection of 486 and Pentium hardware);

• It must still be nice and easy for the public and librarians to use;

• And pretty - did we say it should be pretty? We were sick of having only text on screen!

• It needed to do standard ILS stuff, and in particular, we wanted really good financial reporting on book purchases through the year.

With these lofty goals in place it was time for the hard grind. The system would have two interfaces - a web browser for most of the system, but a simple fast Telnet interface for issues and returns. We quickly choose the systems we would use, free and fast all the way. Linux server OS, MySQL database, Perl programming for the web and telnet interfaces. We were missing a report writer, but one would turn up, wouldn't it?

What followed was 16 weeks of incredibly hard work. Drop-dead dates came and went - no-one died, and the project continued.

Koha: What's in a name?

Why Koha? It's a word from Maori, the language of New Zealand's indigenous people, and means a gift, a contribution. Once we'd decided to release our new software as open source, it seemed to fit.

Open source was a concept we had only the haziest understanding of, back in 1999. We knew about free software - bits and pieces of programmes you could download free, because their creators were so proud of them, they wanted the whole world to admire their handiwork. Some worked pretty well, some were distinctly dodgy.

Open Source is not the same as Free. It was originally called Free, but "Free" as in freedom - anyone was free to use it, rather than in reference to the cost. But business being what it is, the concept got muddled. So the term Open Source was invented.

What's the difference? Think of it as cake.

You get a Free cake - you get something to eat. You want another - it's likely you'll have to stump up with cash at the bakery.

But an Open Source cake - you probably don't get anything to eat, but you do get the recipe, and the set of instructions. You can bake it as many times as you want. You can bake it in a round tin, or a square one. If you've got the knowhow, you can substitute currants for preserved ginger or arrange blanched almonds on top. You can do what you like, because you've got the secret - the source code. You can even sell it, but with every cake you sell, you have to supply the recipe. Even if you made major substitutions, you have to show and tell.

Why did we consider releasing our new library system as Open Source?

Katipo convinced the library that this was a good idea for several reasons.

One was to give the library some surety. There has been more than one library in New Zealand that had software developed for it, and wound up with a dodo a few years down the track when the company responsible went out of business, or got taken over (and that's still happening), or lost interest. Katipo is a small business, and we thought it important that the library be future-proofed against anything happening to the company. Another was because neither the HLT nor Katipo saw themselves as in the business of marketing and supporting a new library system. With an open-source system, that's not a problem. Word of mouth markets it, and the users support each other. The more libraries and programmers using and working on a system, the better it becomes.

So we released Koha as Open Source, and we've got to admit, we were stunned by the results. Over 1000 people downloaded the software in the first month - that doesn't mean a thousand libraries installing it, but a thousand open source aficionados sufficiently interested to have a play. And interestingly, every time we release a new version, the downloads hit the thousand or more again - so there are quite a lot of people out there watching. Increasingly, they are also criticising, making suggestions, and asking if and when enhancements might happen. And volunteering to help. Our development community has grown and now includes contributors on four continents. Koha is available in several languages.

Who are these people who have come on board? They come from all over - academics looking for interesting projects for their students and themselves to study; Open Source enthusiasts just volunteering - perhaps looking for software for their personal library, or their club or church. There are others making a partial living from Koha, tailoring it for particular needs, helping librarians with the install process, or working for libraries which have installed Koha, maintaining and expanding the programme for their use. There's an Internet chat room open 24 hours a day for Koha developers, and there's usually two or three active developers lurking there, bouncing ideas off each other, testing possible solutions, conferring.

To our knowledge Koha is used by public libraries, private collectors, university faculties, not-for-profit organisations, churches, schools and corporates. The framework that Horowhenua Library Trust commissioned has been filled out, extended and improved in many ways. Coast Mountain School District, the second user to pick up Koha, designed a new web issue system. Nelsonville Public Library joined the Koha community in 2003 and commissioned major enhancements, embracing the international records and cataloguing standards MARC and Z39.50. They, and the library of UNIDO in Vienna, have carried responsibility for beta testing Koha version 2.0, which we hope will be released as a stable product any day now.

Conclusion

The 1999 decision to commission new software took us down many paths that we could not have foreseen. There were parts of the forest we would probably just as soon not have visited, but there were other parts that we wouldn't have missed for anything. Our understanding of our software is infinitely greater for having traveled this road, although we still ask what I'm sure are very stupid questions from time to time. This is true not just for the staff carrying the responsibility for Koha development, but for all staff. Everyone had to bug-report, and to understand what the system was doing and why.

But it's not a road for the fainthearted. Facing the future without a vendor holding your hand is a scary prospect. What about the manual? What manual? Documentation is often a weakness of open source projects, and there are still gaps you could drive a bus through in Koha documentation. There are manuals for users, but tips for the installer always seem to lag behind the current release.

Koha's success was built on a good strong relationship between Katipo and the Horowhenua Library Trust. Sure, there was a contract, but even more important, there was an absolute commitment that we weren't going to allow this project to fail. The library continues to receive very strong support from Katipo, and it's needed - Horowhenua Library Trust is a small library with only very basic technical support available in-house. Bigger libraries with competent technical staff are better situated, but interestingly, most of the earlier users of Koha are smallish players, where one key stakeholder has been interested in Open Source, and taken the plunge.

Would we do it again? For sure.