Monthly Archives: October 2009
Koha Development Team. (n.d.). Documentation. Retreived from http://koha.org/documentation.
This is what I love about the Internet: within a day or so of me writing a blog post that was longer on frustration than research, someone who knows better (in this case, one of the documentation developers for Koha) drops by and gently points out my misrepresentation. Basically, “I’ve just spent several hours looking for information on a very specific problem that I, who am totally not qualified to be a system administrator, can actually understand” is not the same thing as “the documentation sucks.” So, as a sort of mea culpa, I present a resource review of the official Koha documentation.
As far as I know, our Koha install was never really configured for anything (largely because we aren’t really using it for anything except our own amusement), so I sat down and started to work through the Koha 3.0 manual start to finish. (Naturally I got bored partway through, so I didn’t get the whole thing, but I did look at at least part of each section.) There’s a lot of example data already installed on our system, but I didn’t like it for my demos, so I figured I might as well input some of my own while I figured out what was going on.
One thing I liked about the manual is that it’s fairly redundant — a lot of what it covers is explained in slightly less detail in the program itself, particularly in the settings region. This is good in documentation, it means you don’t have to read the manual cover to cover and you can be reasonably assured that it does what it says it’s going to do. It even points out the places where you really, really have to work through something in exactly this order if you expect it to work at all, which is convenient. There’s also a BUG notification for settings which still have some kinks to be worked out; I wished the bug notice linked to a more detailed description of what the problem was, but it’s good to know when there’s something that’s not quite fully functional.
When I gave up on setting up administration and OPAC settings, I moved into the patron setup and cataloging areas. (There’s a setting that basically allows you to bypass acquisitions, which is handy for those of us who aren’t actually acquiring anything.) This was where I started to be properly impressed by the manual, since I have that Technology Geek disease where I won’t read the manual unless I’ve already spent half an hour incapable of figuring it out on my own, but usually it doesn’t take me half an hour to figure it out, so usually I don’t need the manual at all. Still the case here, but when I did check the manual, it provided me with some shortcuts I wouldn’t have figured out too quickly myself and I had no problems finding the sections immediately relevant to what I was doing.
There’s a slight over-reliance on default settings in the manual, I think; because some of our system wasn’t using defaults, there were places where the manual assumed things that I simply wasn’t seeing. I had no problem figuring it out, but there are people who would. Overall, though, I will cheerfully retract my statement that the Koha documentation sucks. The installation documentation is a little thin for those of us with less Linux and system administration experience, certainly, but the manual for day-to-day use is very nice indeed.
In addition to the manual, there’s quite a lot of other documentation, which I haven’t had a chance to look at while playing with the software, but I like the look of it. There are how-tos, step-by-step instructions for common tasks (including how to contribute one of your own); detailed tutorials; and a long list of Frequently Asked Questions. To be honest, I’m not sure what the difference is between how-tos and tutorials, and neither of those sections have very much content at the moment, although of course they’ll expand as more people contribute. The FAQs cover common problems, many relating to issues having to do with how the system settings are applied, which are probably handy for administrators who have permissions to change settings but might be frustrating for people who don’t. Overall, it looks like the actual manual is probably the best resource for staff working with the system on a day-to-day basis, and the other documentation will be most helpful for the sysadmins and others with more complete control over the Koha system.
Giesler, A. (2008). Installing Koha 3.0 on Ubuntu 8.10. Retrieved from http://www.blazingmoon.org/guides/k3-on-u810-1.html.
I had honestly forgotten all about this site until I googled it in desperation whilst trying to figure out how to set up our Library & Information Technology Association student computer’s installation of Koha to be accessible remotely. And I shouldn’t have forgotten, because it was written by Andy Giesler, who ran the LITA group on campus last year and actually did the install of Koha that I’m using now.
What he’s done is written up a nice, plain-english guide to installing Ubuntu, the open-source Linux operating system; Apache, the open-source server software; and Koha, the open-source ILS. All the software is free; the costs are all in the machine and the time and effort you put into figuring out the install process.
One of the problems with open source software, you see, is documentation. Writing help files and installation documentation is probably the least popular part of a programmer’s job, so when a programmer is working for free, for the good of the community, on an open source project, the documentation is going to suffer in an obvious way. That is to say, most documentation for open source software is terrible, and Koha is no exception.
It is possible to get good documentation and support for Koha — you can pay for it. LibLime is one among many companies who offer subscription support services for Koha, and Equinox offers a similar program for Evergreen, another open source ILS. If you can afford the support, you’re still getting a deal on the free software. If you’re trying to figure it all out on your own, it can be a little…trying.
Andy’s writeup of the install process will help lead most reasonably computer-savvy people through installing Koha, which is the first step in understanding how the program functions on a base level. If you want to play with the program itself, though, you’re still left with only the open-source documentation and your own patience.
Update 10/27/09: Yeah, I wrote this post in a flurry of frustration over not being able to accomplish what I wanted to accomplish as quickly as I wanted to. Allow me to rescind my statement: the Koha documentation does not really suck. (I’ve written a new post about it, above.) And, of course, documentation and support are two entirely different things; while you can pay LibLime for support, the Koha documentation is all free online, like the program itself. I will stop writing these posts while frustrated by software, I promise.
A bit more on that project, then —
What I’m doing is basically a kind of low-intensity research on open source software in libraries. I’ve a particular interest in Koha, the open source ILS, since the South Central Library System is in the process of switching to Koha from Sirsi Horizon (and having used the Sirsi-Dynix staff interface, I can tell you, it is about time). I’ll be collecting resources in a del.icio.us account which is feeding to this blog over to your right there, and writing up evaluations on some of them as I go along.
Koha is a fully open-source, standards-compliant and platform-independent ILS, currently in version 3.0.3. As an open source product, it is released for free under the General Public License, and libraries are free to install and use it themselves, for no charge, if they have the expertise to do so. Koha’s parent company, LibLime, offers paid support, as do a number of other companies.
Developed originally in New Zealand, Koha is currently in use on six continents, in a wide variety of libraries and library systems, including the Delhi Public Library in India and the Hawaii State Archives. (Or, for a public library catalog, check out the Grand County, Utah Public Library.) Koha supports a number of Web 2.0 techniques, including tagging, and as an open source product is fully customizable.
There are a lot of other opportunities for open source software in libraries too, though, from OpenOffice to Gimp and more, and I don’t want to neglect those. As budgets get tighter, free software (even if it requires a support contract or extra IT hours) can be a huge benefit to libraries. Above and beyond that, though, is the idea of open source — that people should be able to understand what they use, to craft it to fit their needs, and to have ready access to the resources that are important to them. That’s very similar to the mission of public libraries, and one I think librarians ought to endorse.