[Web4lib] Koha

[Stacy Pober]

> I was wondering if anyone on the list works at a library that uses
> Koha. If so, would you recommend it?

Which version of Koha?  Open source? Proprietary offshoot?

What kind of hosting/support?  Self-hosted with solid in-house IT support?
Or software-as-a-service where someone else provides server space, support
and you lose a great deal of control?

What will the costs be for your library?

Unless you can be more specific about what kind of "Koha" you're talking
about, it's hard to recommend or not.

Open source software is usually free, which makes users much more tolerant
of its shortcomings. When you spend money, your expectations are much
higher.

It's kind of like silverware. If someone sold you plastic utensils at the
same price as the sterling silver set you're using, you would probably be
disappointed. But when you get flimsy plastic utensils free with your
take-out food, you're happy enough.

The library where I work is part of a group sponsoring the proprietary
offshoot of Koha called Liblime Enterprise Koha (LEK).  Our last ILS was
Voyager. Because we're in a group that is paying for "enhancements" to be
developed for LEK, our annual cost is the same as if we'd continued to use
Voyager.  But Voyager is a stable system and is not a work in progress as is
the case with LEK.  If you count the productivity lost because of staff time
taken up with beta testing and finding workarounds for the missing features
in LEK, then it's actually more expensive than sticking with a commercial
ILS.

You may be familiar with a free utility called MarcEdit, which is aptly
referred to as the librarian's Swiss army knife. Well, Liblime Enterprise
Koha is more like the librarian's spork. It's an awkward hybrid of open
source and proprietary software.  It has all the disadvantages of
proprietary software  (high cost, vendor lock-in...) combined with the
disadvantages of open source software (buggy, lacks important features, poor
documentation...)

There are many functions one would expect in any ILS that don't work in
LEK.  Basic OPAC features are missing. For example, there's no phrase search
available, hyperlinked subject headings don't work properly, truncation
cannot be turned off, there are no stopwords, etc., etc.  (Most of these
problems are also in the official open source  Koha releases as well.)

New versions of LEK are released every few months and the releases introduce
new bugs, and sometimes alter essential functions in unexpected ways. Our
library  has no direct vote on which features are going to be funded. We
cannot opt out of moving to a new release without asking for a special
exemption, and the exceptions are not always granted.  Some support requests
get immediate attention, and some are ignored until there have been repeated
requests, and some are not answered at all.  Sometimes the response is an
explanation that a particular feature simply does not work in Koha and will
not work without additional development funding.

The library staff have to test and learn to use a new version of the ILS
every couple of months.  Testing, learning new features and reporting bugs
can suck up a tremendous amount of time.

Some of the enhancements are not very useful.  They probably sounded
promising when they were being proposed but they are awkwardly designed
(e.g. a very limited ability to batch edit records) or they perform a
function that is not useful to most libraries (e.g. a search for records
that were previously deleted from the catalog.)

Liblime was selling Koha as open source two years ago when a group of
academic libraries signed up with them. The LEK software they provide is
based on the open source Koha but has significant differences.  It is not
open source at all -- none of the code for LEK has been released.

PTFS bought LibLime earlier this year.  They've come under considerable
criticism in the open-source Koha community because of the proprietary,
closed-source nature of LEK.  Other support companies are developing Koha
features for their customers and sharing them with the rest of the Koha
world, but this has not been the case for LEK. However, to be fair, PTFS has
a policy on software release where they normally release the code after a
month or two of testing and 6 months of deployment to their customers.
Unfortunately, the contract between PTFS/Liblime and the organization
funding the LEK enhancements has effectively blocked all code release so
far.  You can't really blame PTFS for honoring a contract made long before
they bought the company. (They did release code for another version of Koha
called Harley which was funded by public libraries.)

I haven't worked in a library that uses the open source version of Koha, but
clearly there are some happy users out there. I don't think it's comparable
to a commercial ILS in terms of features.  The open source Koha project has
a strong user base that offers support and advice. That community has been
very generous in offering help to people working with the proprietary LEK
version, but the versions have different features, so there are limits to
that help.

I can't recommend Liblime's LEK spork-like version of Koha at this point.
Maybe in another couple of years LEK will be a system with features
comparable those offered by commercial ILS vendors, but that's not the case
now.  LEK development is far behind schedule, so it's not at all clear when
or if the system will have all the features users expect to see in an
integrated library system.

So, would I recommend Koha? The free, open source version may be right for
certain libraries. I think there's a certain sacrifice of power for
user-friendliness and low-cost, but that might be a fair trade-off for some
libraries.  If you have good in-house technical support and plan to run your
own Koha server, you can just download the current version and try to set it
up on a Linux box.  See if the features available suit your needs.

--
Stacy Pober
Information Alchemist
stacy.pober at manhattan.edu

[The opinions expressed here are my own and do not necessarily coincide with
those of any organization.]