Tennant, R. (2007, November 12th). Library software manifesto. Retrieved from http://techessence.info/manifesto.
To wrap up my resource reviews for my LIS644 project on the open source ILS Koha, which has turned into a kind of overview on the state of the ILS today, I thought I’d post Roy Tennant’s Library Software Manifesto, written in 2007 to address the “unhealthy” relationship between libraries and library software vendors. Tennant is one of the leading library technology voices, and although this piece is a couple of years old now, I think it’s still important and interesting.
The Manifesto lists consumer rights — such as the right to use the software you have paid for, without having to pay more for it; consumer responsibilities — such as the responsibility to realize that you’re not special, and the vendor has other clients too; and shared responsibilities — such as the responsibility of mutual respect (at least until one party does something unforgivably ridiculous). I think this kind of approach could be very productive in thinking about changes and implementations to a library’s ILS.
I admit it: I’m a library school student, and my knowledge of the ILS selection and management process is limited to a couple of talks and quite a bit of reading, so I don’t have any real experience with how this works. But there’s a fairly small selection of ILS vendors, and librarians on the whole tend to be less than completely familiar with programming and technology implementation, so some of the problems implied by this manifesto don’t surprise me at all. The overall points made by the manifesto, though — librarians have a right to use their ILS to their greatest advantage, and to have some idea of how it works; librarians have a responsibility to treat the vendors and programmers fairly and without unnecessary acrimony — seem to indicate to me one reason why open source ILS solutions like Koha have become popular in spite of their detriments. When you have full access to the source code of your software, you can use it however you want, and you’re going to have to figure out how it works. When you have to contract out or hire someone to do upgrades or added features, you have a much more direct, less bureaucratic relationship with them. Open source projects can get rid of a lot of red tape that can hinder a good working relationship.
Of course, open source solutions aren’t without flaws — the first comment on the post is from someone mentioning that he feels his experience as a software user isn’t taken seriously by open source developers. The tradeoff with open source, I suppose, is that many developers work on open source projects as a hobby, and their income isn’t affected by users’ dissatisfaction. (Companies like LibLime eliminate this problem, but add the bureaucracy back in… nothing’s perfect.) Obviously this is no way to eliminate problems with the librarian/developer relationship, so the best way forward appears to be the one implied in Tennant’s manifesto: for everyone to know a little bit more about what the other side is doing, and to acknowledge both their own and the other side’s priorities in doing so.
Fitzpatrick, S. (2009, November 11). Open source advocates reject SirsiDynix’s warning about OSS. Retrieved from http://www.ala.org/ala/alonline/currentnews/newsarchive/2009/november2009/abramvsoss111109.cfm.
Scandal! Well, kinda. Anyway, it’s jucier than most of what you’ll get when reading about open source ILS implementations, so I was perfectly happy to find this ALA report on a white paper from the Sirsi-Dynix Vice President of Innovation that pretty much proves that open source software is a viable alternative to traditional vendors. (If it weren’t, they wouldn’t be worried about it.)
The white paper itself is extremely negative about open source, although to be fair, it seems to be pretty truthful. Abram emphasizes the small size of the ILS programming community, giving the impression that open source software needs a user base as large as that of Firefox to be worthwhile. The warnings given about open source software are accurate — but they’re the same warnings open source advocates give. Many of the detriments of open source Abram lists apply largely to new software, but neither Koha nor Evergreen, the two major open source ILSs currently available, could really be called new at this point: libraries looking into them now are certainly not early adopters.
The American Libraries article summarizes the library blog and Twitter reaction to the leaked paper, which was generally not too supportive of SirsiDynix’s position. Several bloggers argued that while it might cost more money to train librarians and programmers to get a good open source system running, that training in people is much more valuable in the long run than maintenence fees paid to a proprietary vendor. The article also links to the variety of Web 2.0 tools that are being used to comment on the issue, from a blog post (with moderated comments) to a Google Doc to a Wiki. These documents are fascinating to look at — this is an ongoing debate, and one that will keep many people interested for a long time.
Koha blog. (n.d.). Retrieved from http://www.myacpl.org/koha/.
From the same folks who brought you A Koha Diary is Koha Blog, a resource for modification and customization of the Koha interface. If I were managing a live Koha system, I would subscribe to this blog’s feed and read it every day. (Or, well, as often as it updates, which isn’t very often; it’s much more of an archive than a real day-to-day blog.)
The great thing about open source software like Koha is that, with the right application of effort, you can make it do whatever you want it to. And in the true spirit of open source, the folks at the Nelsonville Public Library are sharing their efforts with the rest of the library community, in simple, straightforward explanations that anyone with a minimum of programming experience can implement.
This kind of stuff (although possibly not these exact tweaks) is also available at the Koha developer’s wiki, but the advantage of Koha Blog is in its simplicity and in the fact that it’s written by librarians for librarians: knowing how to add extra content blocks is useful, but knowing what you’d use them for is even more useful, as in this example.
Breeding, M. (2008). Major open source ILS products. Library Technology Reports, 44(8), 16-31.
This article from last year’s Library Technology Reports offers an overview and comparison of the four most prominent open source ILS products — Koha, Evergreen, OPALS, and NewGenLib, as well as a discussion of the open source phenomenon in ILS products in general.
There are a lot of tables — I enjoy tables — breaking down what kinds of libraries are using what kinds of software, what kinds of population and circulation figures they’re working with, things like that. Koha is a favorite among small to mid-sized public, academic, and special libraries, while Evergreen, designed by a consortium of libraries in Georgia, has been preferred for large library systems. Large individual libraries are still reluctant to adopt the fairly new open source ILS applications. I was interested to discover that open source hasn’t made much of an impression outside of the United States and Canada, although it has been a choice option in some developing countries.
The article continues with a breakdown of the companies that support this open source software (such as LibLime for Koha), a review of the technical backend of an open source ILS implementation, and finally a feature-by-feature rundown of the specific software discussed, based on documentation and demo sites. This would be a great source for a library curious about which open source ILS to explore in more detail.
Hedges, S. (2005). A Koha diary. Retrieved from http://www.kohadocs.org/koha_diary.html.
This webpage is a collection of e-mails collated by the Nelsonville, Ohio public library director, chronicling that library’s transition to Koha. He mentions that the switch to Koha was the sysadmin’s idea — he knew about open source software, and thought that the open source philosophy and the library philosophy were compatable enough that one ought to support the other, and the director put together a team to explore transitioning to Koha.
The e-mails describe a variety of problems associated with the transition, from installation complications to modification details. They’re working with a much older version of Koha than the one currently available — an early e-mail discusses having to add Z39.50 support — but I don’t think that invalidates the usefulness of the document in examining what kinds of problems might arise in the process of adopting open source software and illustrating possible solutions.
There are also a few philosophical discussions on how and why library software works the way it does; I find these some of the best parts of this document. There are discussions on library software design, on the dedication required to fully implement an open source project, and on the ways to promote a real community for a project like this. You can really tell that the people working on this project were excited about it, and I love that.
There are e-mails here from Nelsonville librarians, from programmers, from Koha organizers, all over the board in this project, and it’s fascinating reading for someone interested in how the transition and modification process actually works.
I have only one complaint: the page isn’t well-organized for reading out of order. There are nine linked main sections, but since the whole thing is chronological, they work more to break up the narrative than anything else. I suppose you can always use your browser’s Find feature if you’re looking for anything in particular.
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.