Koha is intended to be: a library catalogue front end/OPAC a library system intranet a circulation tracking system
The name comes from the Maori word for a gift or donation. The programme was written by Katipo Communications for the Horowhenua Library Trust, in response to a need for a library programme that would run at branch libraries connected to the central library by ordinary phone lines. See http://www.library.org.nz/koha.htm (Or Appendix 2) for the full story.
Kaitiaki is the Maori word for Guardian. When the Koha user and developer community realized some sort of combination Benevolent Dictator/Juggler might be a good idea, they chose a name that would reflect what they felt his/her role would be. The Kaitiaki is currently elected from among the membership of the developer's list -- this includes the Katipo staff as well as representatives of several of the libraries and the far flung contributors of code, documentation, and kibitzing. This person is also responsible, with the advice and consent of the community, of trying to decide target dates for things like releases and features scheduling... and trying to help bring some order from the chaos ;). He also helps coordinate efforts and agendas, particularly through the mechanism of the every-few-weeks IRC meetings. Traditionally, the Kaitiaki also handles things like release announcements to sites like OSS4lib.
Katipo is a company. See http://www.katipo.co.nz/ for more information. It is named after a small native spider. The Katipo spider is a dune-dweller and New Zealand's only native poisonous creature.
They are in the Maori language, the language of the people native to New Zealand.
It's a small district on the west coast of the North Island of New Zealand, wedged between the Tararua mountains and the Tasman Sea. It's about an hour's drive north of the city of Wellington, and has population of 30,000. The name means erosion or landslide in Maori.
For vowel sounds, think French: a as in far; e as in egg; i as the e in me; o as the a in paw; u as the oo in moon, dipthong ai as y in sky For consonants, wh is pronounced variously as h, w and f; we use the f pronunciation in Horowhenua. Other consonants as you would expect, with the p a little softer and less explosive than in English. The stress is always on the first syllable, with a secondary stress on the third syllable in Horowhenua. So:
koha (kaw_ha)
horowhenua (haw_raw_fen_oo_a)
katipo (kah_tee_paw)
kaitiaki (ky tee a kee)
*If you are serving a community where Spanish is spoken, you may want to use a different name to refer to the software. The reason forthis is that the Maori word "Koha" (gift) sounds like the Spanish word "coja" (cripple).Good question. :) The Koha developers think this is most likely be a database(ie MySql) issue, primarily. Big server, lots of RAM is better for heavier use. It come down to what is an acceptable number of seconds for any given lookup to complete. Our guess is that it would be most important for circulation side of things. Librarians generally don't want to wait for more than a second to complete a return, for example. This would require some benchmarking with real data. The next question would provide a rough guideline, although we're pretty confident that Koha could be scaled to libraries larger than CMSD and HTL. To date, no speed complaints have been received.
As far as hardware and operating system:
HLT (3 branches, 80,000 books, 25,000 patrons) Dual Intel Pentium III 1 Gigahertz processor 1Gb of RAM mirrored Maxtor 20Gb 7200rpm disks Debian Linux "woody" (the testing distribution) Administrator comment: "The above appears to be somewhat overpowered." CMSD (8 branches, 2,000 to 8,000 books per site, 1,000 patrons) Pentium 200 MHz to 300 MHz machines (1 per site) 64 MB of ram Respectively: HLT - Horowhenua Library Trust, New Zealand CMSC - Coast Mountain School District, British Columbia, Canada |
[The Following is a comment from Simon Blake, simon AT katipo.co.nz> on the subject]
Were I specifing a new box for Koha, given current prices I'd put as much RAM as I could into the machine - 1.5Gb of RAM costs (I assume) around US$100-150 at the moment, and with that much RAM in the box, most of the Koha database will be in memory rather than on disk, and this does brilliant things for the performance of MySQL. So, lots of RAM is crucial, and then as much CPU and disk performance as you can afford. Bear in mind that Koha will work fine on a low spec machine (say, a Pentium 150 with 32Mb RAM), it'll just be slow, and the slowness will increase as usage increases. So you can run it up on most any machine that can run MySQL and Apache, and see how it goes, and if it's too slow then you can throw money at the problem until you get the performance you want. You'll need to tune MySQL to use all that RAM, here's what Chris has in the MySQL config at the moment:
set-variable = key_buffer=256M set-variable = max_allowed_packet=1M set-variable = table_cache=256 set-variable = sort_buffer=1M set-variable = record_buffer=1M set-variable = myisam_sort_buffer_size=64M set-variable = thread_cache=8 |
Make sure, also, that your disks are setup correctly, with the highest possible DMA support - hdparm is your friend. I'd observe, also, that long term Koha should get faster, and thus need less in the way of resources to run it - there are some fairly inefficient table structures in Koha, a hangover from the previous system HLT ran, and as these get ironed out and removed, I'd expect Koha to get quicker.
Library cards employ Check Digits. Check digits are numbers that are based on a mathematical formula devised to help detect typical data entry errors. Koha library cards employ a 7 digit number and the last "number" may be an X - Let's refer to the card number as ABCDEFG.
To calculate the check digit:
Calculate= (4xA) + (6xB) + (3xC) + (5xD) + (2xE) + F G is the remainder when divided by 11. If the remainder is 10, then use "X".
The standard for Koha is a barcode standard. The library would get a batch of barcodes from the printer with checkdigits included. Here is an excel spreadsheet to generate koha compatible card numbers http://developer.koha.org/HLT2.xls
Brief history of cardnumbers and koha:
Horowhenua Libraries get their cards with a barcode and a number on them. The number conforms to the checkdigit routine. So koha didnt need to generate cardnumbers. It just needed to check that the number entered conformed to the checkdigit routine.
Go to your admin page, and set AutoMemberNum? to 1 - that will get koha making its own card numbers. Otherwise, make a little routine that generates numbers that fits that checkdigit. But what is more pertinent I guess is how to change the checkdigit routine so it fits your existing numbering scheme. At the momment the there is no easy way. Apart from hacking at the perl.
The undelete biblio option at the bottom of this page
http://hlt.katipo.co.nz/cgi-bin/koha/maint/catmaintain.pl is a quick way to undo a mistake - and it is tucked away in an admistration 'bit' of Koha. It would be pretty cool (and might eventually happen) to have an undelete borrowers option on a page somewhere which retrieves from the deleted borrowers table (as opposed to the borrowers table).
Currently, Koha has a custom backend database for storing bibliographic information.
It is currently possible to import MARC records, one at a time. Full MARC support is coming for both the database and the front end.
You can import information from Marc format (always have been able to I think it was one of the first things someone tried to do). However there is work very near completion on a more comprehensive support for Marc - so that you can get the information in more automatically, and also store and potentially export it back out again in Marc.
Information about MAchine Readable Cataloging (MARC) dhttp://www.oasis-open.org/cover/marc.html/para>
Nope.
Koha is distributed under the General Public License (GPL). More information on the GPL can be found at: http://www.gnu.org/licenses/licenses.html#GPL The gist of the license is that you are free to use, modify and distribute the program at no cost to yourself, provided that modifications you distribute are also released under the GPL. Obviously, we'd appreciate an email about it... and the chance to add anything we find useful to the primary Koha package.
Koha is open source software. In open source software, software developers give away the fruits of their labour in the hopes that others will help them develop the software.
See the INSTALL file included in the distribution, or the manuals 'Step by Step' section.
If you're in New Zealand, a mirror is at http://www.koha.org/download/ Otherwise, try http://sourceforge.net/project/showfiles.php?group_id=16466 Is there a config guide or menu for what to put into the SQL tables for preferences, etc for a new blank installation? Nope, we are sorely lacking that. What you need in the system preferences table to use the simple acquisitions module: insert into systempreferences (variable,value) values ('acquisitions','simple'); Then, from the index page of the intranet page (eg http://hlt.katipo.co.nz/ clicking on acquisitions will take you to the simple acqui screen and you should be able to start loadin in data from there.
Insert into the printer table something like: insert into printer (printername,printqueue) values ('No Printer','nullip'); And in the branch table try: insert into branches (branchcode,branchname) values ('T','Test');
We use the users table for doing authentication with Apache::AuthDBI?, so it contains the users and passwords for valid users to connect to the librarian part of koha.
Nope we are sorely lacking that. What you need in the systempreferences table is to use the simple acquisitions module. That is:
Insert into systempreferences (variable,value) the values ('acquisitions','simple'); Then, from the index page of the intranet page (eg your equivalent of http://hlt.katipo.co.nz/ ) clicking on acquisitions will take you to the simple acqui screen and you should be able to start loading in data from there.
See the Install section in Book 1. The -very- short answer is, you can get by with most free versions of Unix(GNU/Linux, etc), Apache, Perl (and some additional modules).
Katipo, the company that built the original Koha, makes a mailing list available to Koha users, who (as is customary with Open Source software) help each other out with questions. Usually most of the development team monitors and comments on this list as well. See: http://lists.katipo.co.nz/mailman/listinfo/koha
Best bet at the moment is to ask the list (above).
Koha is currently maintained by a team of volunteer developers spread across New Zealand, France, Canada, and the United States. There is a sourceforge mailing list for the development team, if you're interested in joining please email info AT koha.org. Additionally, we have had assistance and contributions from Pawel in Poland, who gave us a neat translation script and has helped with installs in Poland.
I imagine you could. Katipo would probably accept new clients. Steve Tonnesen says he could probably be talked into it. In the long run, it should be possible for people with less coding knowledge to supply Koha support as far as installation and use goes.
A Polish package exists at the Sourceforge site (see under "Where can I get Koha?"). We're very open to new languages being added. In addition: If you are a francophone, Paul Poulain [paul DOT poulain AT free DOT fr] notes: "If someone hired me for a french version, my koha dev would be on the top of my list"
Most of the people working on bug fixes and new features are working on them in their own time. They are generally released if and when the bug fix or feature is ready. If you want to speed to the release of a bug fix or feature, see under 'How can I contribute to Koha?' You could also look at the Developer section (Book 3) of the manual, and ask a developer for a pointer to the current version of the features roadmap.
You could try Katipo or Steve Tonnesen or several others on the developer list. It should be pointed out that Katipo and Steve are primarily concerned with adding features that scratch their clients' particular itches. If you want a feature that doesn't appear to be on our radar, offering to pay for it will obviously speed up the process. Alternatively, you can hire somebody local to your organization with Perl programming skills to implement your changes.
Check with a member of the development team: http://lists.sourceforge.net/lists/listinfo/koha-devel
OpenBook was inspired by Koha. The builders of OpenBook rewrote the application in PHP (as opposed to the Perl which Koha is written with) and have created their product entirely from scratch. It is possible that there may be some lingering similarities in the database, but even there we doubt it as they have switched completely to a MARC based database, as far as I know. In addition they added a number of features the Waitt Family Foundation funded Technology Resource Foundation (at http://www.trfoundation.org/) felt were necessary. Under the terms of the Open Source license, "forks" such as this are entirely acceptable. Most of the additional features they added are being created for Koha as well. Last time anyone from the Koha developer team checked OpenBook, likeKoha, was released under the GPL, but moving code back and forth between the two would probably not be trivial, based on the different programming languages, and the different database schemas. However, we _do_ plan to imitate their Z39.50 searching form, as they obviously have more knowledge of Z39.50 attributes than anyone associated with Koha does. :)
Addendum: The above links appear to have gone dead. If anyone from the project or foundation have any additional information,or anyone has copies of their code, we would appreciate hearing from you.
Addendum 2: OpenBook underwent a rebirth, and is currently in testing in some Washington State libraries.
Koha Credits Horowhenua Library Trust Rosalie Blake, Head of Libraries Jo Ransom Katipo Communications Rachel Hamilton-Williams, General Manager (Webmistress) Simon Blake, Technical Manager, Server Administrator Amanda Atkins, Operations Manager Chris Cormack, 1.2 release guru Olwen Williams Finlay Thompson Gynn Lomax Richard Anderson Jeremy Blake, Katipo Koha Project Manager Rebecca Holden, New Koha.org page Steve Tonnesen, MARC import/export guru Pawel Skuza, Polish Language porter Glen Stewart Paul Poulain, 1.4 release manager Pat Eyler, Kaitiaki Roger Buck Adam Thick Florian Bischof Sebastiaan Durand Andrew Hooper Mike Mylonas Mike Johnson Mike Hansen Nicholas Rosasco, Documentation Editor/Compiler |