Question 1. 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.
Question 2. 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.)
Question 3. 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.
Question 4. 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.
Question 5. What Kind Of External Support Are You Using, Or Do You Foresee Using As You Convert Into 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.
Question 6. 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.
Question 7. 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.
Question 8. How Do I Merge Records?
Go to the cataloging search and search for the records you want to merge. Select the records you want to merge. Select which record you want to be the main record and then select the fields you want to merge.
Question 9. Why Isn’t Koha Detecting Duplicate Patrons?
Koha detects duplicate patrons using FirstName, Surname and Date of Birth. Unless all three are an exact match, the patron isn’t considered a dup.
Question 10. The Availability Numbers Don’t Look Right On The Search Results Screen, Why Not?
There is a limit to how many items Koha will check in search results — look at the system preference Mac Search Results Items Per Record Status Check.
Question 11. Why Some Do Items Show As Available And Checked Out In Search Results At The Same Time?
Who an item was checked out to is stored in the ‘issues’ table in Koha. The due date is also stored in items.on loan, which sometimes gets set to null.
Question 12. How Can I Delete Ebook Records In Batch?
If you have a file of urls or ‘bookids’ from your vendor, we may be able to run a script to delete these bibs for you. Send us the file you received from the vendor.
Question 13. When Checking Out An Item, Why Is The Due Date Is Prior To The Checkout Date?
In the circulation and fine rule table, check to see if this item type and patron category have a hard due date set – and if this date is in the past.
Perl Scripting Interview Questions
Perl Scripting Tutorial
Linux Embedded systems Interview Questions
Linux Embedded systems Tutorial
Application Software Interview Questions
Git (software) Interview Questions
Git (software) Tutorial
Docker (software) Interview Questions
Perl Scripting Interview Questions
Docker (software) Tutorial