An exchange between Pat Eyler, then Koha Kaitiaki , and Stephen Hedges, then Nelsonville Public Library Director, in January 2003. Koha went live at the Nelsonville Public Library the following September.
When did you first consider using Koha?
We started lurking on the Koha list about a year ago, though now I don’t remember how Koha first came to our attention. In January of this year, I’d seen enough to pull together a “tech team” consisting of me, 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.
What was the initial draw of Koha?
Freedom. We want to use the Internet to offer some cutting edge information services to our library patrons, 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.)
What drawbacks did you see with Koha?
The same drawbacks that plague many of the smaller Open Source projects, I suspect. First is 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 is 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 mean 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?
You’ve made a decision to contribute to the development of Koha. 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 well. What are your thoughts on this model?
We’ve come to realize that this may be the only viable model, and perhaps the answer to the question I just posed. 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. Open Source requires just as much commitment as commercial software – you still only get what you pay for. 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 as well, 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 has paid their money and received a product that works fine for their needs. Now other libraries can pay a little more money and receive enhancements to that product that will make it fit their needs – without having to pay for the development of an entire software package. HLT got what it wanted, we plan to get what we want, other libraries can pay and get what they want. The libraries are paying a one-time expense that’s probably 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!
What kind of external support are you using, or do you foresee using as you convert onto Koha?
Very little. We originally thought we would use a database consultant to assist in moving our data from our current system to Koha. (This is a task that’s typically handled by the “new” software vendor when libraries switch from one commercial product to another.) We’ve recently realized, however, that the mechanics of the data transfer are not as difficult as identifying which data we want to keep and which is superfluous. For that reason, we’ll probably do the data transfer ourselves. Otherwise, the tech team is working to learn the tools we will need to maintain the software: perl, linux, mySQL, php, etc. We regard this learning process as part of our investment in Koha. And remember, our original motivation in looking at Koha was the ability to offer some cutting edge services, so we’ll need to have a thorough understanding of the software for more than just maintenance purposes.
What are the major milestones in the conversion process?
A big one was the release of Koha 1.2.0 in July. 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 absolutely critical things for our needs: full MARC support, a Z39.50 server module, and a SIP2 or NCIP module. To fill those needs, we decided to commit some financial resources to Koha development. Our future plan is to move some of our data into the current version of Koha to see what changes we will need to make in the Koha tables. (And we would then suggest to the Koha developers that these types of changes should be built into some sort of configuration utility or template, rather than being hard-coded.) Once we have a little of our data transferred and working, we will transfer the rest and plan to run Koha in tandem with our old circulation system. This will not only allow staff to get familiar with the new system (Koha), it will also give them an opportunity to request changes to screens, customized functions, etc. Once we find that Koha has become the system of choice for the staff, we will shut down the old automation system.
When will your patrons be able to see Koha in action?
We expect that Koha will take over from the old system sometime during the summer of 2003.
What do you think you’re going to see in terms of an ROI on your investment in Koha development?
I expect that an initial investment of about $10,000 will save us about $10,000 every year, beginning in 2003. We might also seek some technology grant money to extend our initial investment. I think our real ROI will not be financial, however. 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.
