Comparing Open Source Integrated Library SystemsThe Circulation Module of Evergreen & Koha
Alison Jones & Cynthia Ng
LIBR 551: Library Automation & Systems 23 March, 2011 Shirley Lew
Koha & Evergreen Comparison
2
Table of Contents 1. Introduction 3 2. Which Version of Koha? 3 3. Observations and Findings 4 3.1 Patron Maintenance 4 3.1.1 Searching for Patrons 4 3.1.2 Adding Patrons 5 3.1.3 Updating Patron Records 8 3.1.4 PIN Resets 8 3.2 Check-in/out 9 3.3 Renewing Items 10 3.4 Bills, Fines & Payment 11 3.5 Holds 13 3.5.1 Placing/Editing Holds 13 3.5.2 Holds Pull Lists 14 3.5.3 Holds Capture 14 3.6 Changing Status of Items 14 3.7 Changing Load Period 15 4. Documentation & Help 16 5. Conclusions 17 Works Cited 18
Koha & Evergreen Comparison
3
1. Introduction
Traditionally, libraries have purchased integrated library systems (ILS) from vendors who make
proprietary software. However, open source ILS have become much more popular in recent years, with a
number of major systems and several companies offering support (Breeding, 2009). Our task was to
compare two of these systems: Koha (Bywaters version 3.03) and Evergreen (version 1.6.1.2),
specifically the circulation module both through the staff client and the Online Public Access Catalogue
(OPAC). A number of techniques were used in the evaluation and comparison process. Our main strategy
was direct examination; we performed an operation in one system and then the other, which immediately
highlighted any differences. We also consulted the systems’ documentation materials, read users’
reviews, and, at times, turned to listservs and bug reports. Our findings are laid out in a combination of
narrative, charts, screencaptures, and bulleted lists. For each section, we have attempted to select the
medium that provides the most clarity for the user.
We considered several possible approaches to the division of work, and ultimately decided that we
would each be responsible for roughly half the circulation modules. This meant that each of us had the
opportunity to explore both systems in depth. The remainder of the project was divided up fairly
informally, but with an eye to maintaining balanced contributions.
2. Which Version of Koha?
The recent division of Koha into two development streams, ByWater Solutions and LibLime
(PTFS), is a complex and controversial piece of recent history. Tensions exist between the major support
companies in the United States and Europe (Hellman, 2010), and both lines have their supporters.
However, the ByWater release seems to have gained more acceptance within the Koha community
(Leonard, 2010). The ByWater website’s links point back to the original Koha community, whereas
LibLime’s directs the user to the Koha.org site.
In addition, a large-scale survey of libraries in 2010 showed significantly more user satisfaction
from libraries using the Bywater release, particularly in the area of customer support (Breeding, 2011).
According to recent postings to a library listserv (Krischel, T., February 17, 2011 [Web4Lib list]),
LibLime’s release of Koha is not “uptodate” [sic]. Finally, Liblime has recently released a clients-only
version of Koha. Though legal, this move raises serious questions about their commitment to the
principles of open source software. (Hadro, 2009). For these reasons, we chose to use the ByWater
version of Koha in this analysis.
Koha & Evergreen Comparison
4
3. Observations and Findings
Below is a detailed discussion of our observations and findings for each functional area.
3.1 Patron Maintenance
3.1.1 Searching for Patrons The patron search function is easy to use in both systems. Both handle partial inputs in searchable
fields. However, where Evergreen uses ‘begins with’ searching, Koha uses a ‘contains’ and retrieves
partial matches. In Evergreen, it is also easier for the user to see what fields are being searched and allows
the user to use a single field or a combination of fields (see Figure 1). In comparison, according to the
message on the search interface, Koha searches patron card number and name fields. This is consistent
with the 3.2 documentation (as of March 12, 2011, and not mentioned in the 3.0 documentation).
However, partial email matches also produce results (see Figure 2). This is not made transparent, and it is
unclear to the user what fields are being searched as in actuality includes not only email, but also other
names and user ID (Cormack, 2011).
Figure 1 – Evergreen Patrons Search Form and Results (list of all patrons with email beginning with ‘g’)
Both systems display results with the most basic patron information, and allow sorting of results.
Evergreen also allows customization of the results display and easy access to further patron details while
still in the search screen (see Figure 3). It provides a button to return to the search form with the existing
search still filled in. In comparison, Koha only has basic patron information display, a non-customizable
results list, and no option to return to the search results (although the browser’s back button works).
H
K
w
3.
d
Figur
At firs
However, as
Koha’s ‘brow
whereby Ever
.1.2 Adding Addin
directly from
re 2 – Koha P
Figure
st glance, the
Evergreen se
wse by last na
rgreen will l
Patrons ng patrons is
the main me
Patrons Searc
3 – Evergreen
e only featur
earches field
ame’ feature
list all patron
s fairly easy
enu (see Fig
ch and Results
n Search Resu
re unique to
ds using ‘beg
e, the user w
ns with a las
and straightf
gure 5) or fro
s (list of all p
ults Patron V
Koha is the
gins with’, to
would enter, f
t name starti
forward. Bot
om the main
Koha &
atrons with e
View and Cust
option to br
o produce a
for example,
ing with ‘A’
th systems h
‘Patron’ scr
& Evergreen C
email containi
tomization M
rowse for pa
result simila
, ‘A’ in the l
’.
have the func
reen. The ma
Comparison
ing ‘example
Menu
atrons by last
ar to that pro
last name fie
ction availab
ajor differen
5
’)
t name.
ovided by
eld,
ble either
nce here is
Koha & Evergreen Comparison
6
that Koha forces the user to choose the user group to which the patron will be added. This might appear
beneficial; however, the list of user groups may become unwieldy if it becomes very long, particularly
because they are not automatically grouped when necessary.
Evergreen Sections and Fields Koha Sections and Fields User Identification
Barcode Username Password Names (First, Middle, Last, Suffix, Alias) Date of Birth Juvenile? Primary Identification
OPAC Login username password
Patron Identity Salutation Names (Surname, First, Initials, Other) Date of Birth; Sex
Additional Attributes and Identifiers
Driver’s License Favourite Colour Previous Systems ID Surveys Customized by admin
Contact Info Email Address Phone (Day, Evening, Cell) Home Library
Contact Phone (home, work, cell) Email (home, work) Fax
Alternate Contact Names, Address, and Phone Addresses add as many as needed Main Address 1 address
Alternate Address 1 address Groups and Permissions
Profile Group Account Expiration Date Internet Access Level Active? Barred? Set as Family Account? Claims Returned Count Alert Message
Library Management
Card Number Library Category; Sort 1, 2
Library Set-up Registration Date Expiration Date OPAC note Circulation note
Statistical Categories
Customized by admin Patron Account Flags
Gone no Address? Debarred? Lost Card?
Finish View Summary Save User; Clone User Cancel
End Options Save Cancel
Messaging Preferences
Hold Notification (set elsewhere)
Patron Messaging Preferences
Item Checkout; DUE; Check-in Hold Filled; Advance Notice
Figure 4 - Patron Record Sections and Fields Comparison
The form itself is structured differently in the two systems. Whereas Koha has one long form,
Evergreen has broken fields into sections and requires the user to select a specific section before entering
the information (see Figure 5). The forms are organized a little differently as well. Koha separates the
patron names, contact information, and address from their library identification (e.g. barcode number).
Evergreen combines name and barcode into a single section for user identification, storing contact
information and addresses separately. Other parts of the patron record also vary with the system (see
Figure 4). While Koha allows more customization for general messaging (Evergreen only allows
cu
ad
n
re
o
p
AE• •
sa
ap
ustomization
ddresses. It i
eeds of the o
ed, but also a
One v
n first and la
atron record
Additional feEvergreen
Login and pCan clone u
Figure 5
Gener
ave without
ppears. Both
n of hold not
is difficult to
organization
automaticall
very useful fu
ast names. H
d can be adde
atures:
password auusers with au
5 - Evergreen
ral error han
filling in all
h systems’ er
tices only), E
o make a cat
n. A nice feat
ly turn white
function that
However, wh
ed without a
utomatically utomatic gro
n User Editor
dling in the
the required
rror message
Evergreen pr
tegorical stat
ture of the E
e when valid
both system
hen a possibl
a card numbe
generated ifouping and s
r (Menu option
patron form
d fields or en
es list all the
rovides mor
tement abou
Evergreen for
d text is enter
ms have is no
e duplicate r
er (bug repor
f left blank shared addre
n, Form categ
m for the two
ntering valid
e required or
Koha &
re flexibility
ut which is be
rm is that req
red into a fie
otification of
record is ide
rted).
ss
Koha • Logi
gen
gories, Dynam
systems is f
d information
r invalid field
& Evergreen C
by allowing
etter, as it gr
quired fields
eld (see Figu
f possible du
entified in Ko
in and passwnerated if lef
mic Validatio
fairly similar
n, a fairly sta
ds (see Figur
Comparison
g more than t
reatly depen
s are not onl
ure 5).
uplicate recor
oha, a bug a
word automatft blank
on and Birthd
r. If the user
andard error
re 6). They s
7
two
nds on the
y marked
rds based
allows the
tically
date)
tries to
r message
serve
th
d
u
an
fi
co
n
an
th
5
A
b
p
3.
p
K
sy
o
p
fo
in
3.
m
cl
heir purpose
definition of a
ser that a da
nd a-z.
Field
ield, which s
ontrast, only
ot restrict th
nd future bir
he birth date
). No author
As a consequ
ased on coun
articularly in
.1.3 UpdatinEverg
atron must f
Koha interfac
ystems prov
ne differenc
atron record
orm. Howev
ncreased con
.1.4 PIN RePIN re
manually cha
licking the ‘
, but could u
a valid entry
ate must be in
Figu
validation al
seems unusu
y permits lett
he range of th
rth dates. In
is invalid or
rity lists seem
uence, more a
ntry. In shor
n Koha.
ng Patron Rgreen is more
first be found
ce has an edi
ide good con
e: when view
d. This is han
ver, since the
nvenience is
esets esets are slig
ange a PIN w
Change Pass
use some imp
y (which Eve
n the format
ure 6 - Evergr
lso seems m
ual. It may no
ters in name
he date, allow
Evergreen, a
r a future da
m to exist in
advanced va
rt, error mess
Records e complicate
d through th
it option dire
nsistency by
wing patron
ndy for the u
ese small sec
debatable.
ghtly un-intu
when editing
sword’ in th
provement. O
ergreen does
t MM/DD/YY
reen (left) and
minimal. Koh
ot have any v
fields (see F
wing card ex
an error mes
ate, but the u
either system
alidation is a
sages and fie
ed than Koha
e search, the
ectly next to
y providing th
details in K
user, as this p
ctions are on
uitive and pro
a patron’s r
e patron deta
One simple
s to some ext
YYY, or a n
d Koha (right)
ha allows alp
validation be
Figure 5). Bo
xpiration dat
ssage does p
ser can still
m as any tex
also not prese
eld validatio
a when the u
eir informati
each patron
he same form
Koha, the user
prevents the
ly accessible
oblematic in
records, rand
ails view. K
Koha &
improvemen
tent, see Fig
name field m
) Example Er
phanumeric a
eyond requir
oth have for
te to be earli
op up when
re-enter a fu
xt can be ent
ent, such as
on could be i
user wants to
on retrieved
n in its search
m used when
r can choose
user from ha
e through the
n Koha. Alth
dom passwor
Koha also has
& Evergreen C
nt would be
gure 6); for e
must only use
rror Messages
and symbol
ring an entry
rmat validati
ier than regis
first entered
uture date an
tered into ‘C
no postal co
improved in
o edit a patro
d, and ‘Edit’
h results list
n adding a n
e to only edi
aving to scro
e patron deta
hough a staff
rd generation
s no function
Comparison
to provide a
example, tell
e the charact
s
entry in the
y. Evergreen
on for dates
stration/curr
d and after sa
nd save it (se
Country’ for e
ode format va
both system
on’s informa
clicked on. T
s. Neverthel
new patron. T
t one section
oll through a
ails, whether
f member ca
n is availabl
n for the patr
8
a
ing the
ters A-Z
name
n, in
, but does
rent date,
aving if
ee Figure
example.
alidation
ms, but
ation. The
The
less, both
There is
n of the
a long
r it is an
an
e only by
ron to
Koha & Evergreen Comparison
9
reset their own password, and there is no evidence that this function has been implemented even in the
latest (3.2) version. In comparison, Evergreen has a ‘Reset’ button next to the password field when
editing a patron record, and the OPAC has a “Forgot your password” link with a short pop-up form that
will then send an email to the patron.
3.2 Check-in/out
The check-in/check-out module is highly accessible and supported by ample documentation in
both Evergreen and Koha. It is an option on the default home page for both systems, although its position
at the top centre of the screen makes it somewhat more visible in Koha.
The systems follow the same basic sequence of steps for circulating items: 1) identify patron; 2)
identify item; 3) check item in/out; 4) print receipt (optional). While Koha allows you to search for
patrons by name, email or barcode only, Evergreen allows you to enter a phone number or postal code as
well. However, in Evergreen, a different keyboard shortcut is used depending on whether you are
searching by barcode or by last name. The comparative simplicity of Koha’s interface makes it more
user-friendly in this area.
Checking an item out requires entering its barcode. At this point, the user also has the option of
manually overriding the standard due date. In Evergreen, the date must be entered in YYYY/MM/DD
format. Unless it is manually reset after checking out the item, this custom due date is applied to all
subsequent items in the patron’s check-out session.
Koha’s custom due date feature appears more user-friendly at first – it includes a drop-down
calendar, for instance. A check box in the custom date area is labelled ‘Remember for session’, implying
that settings will default to standard if it is left unchecked. However, here there is a glaring error: unless
changed back manually, the custom due date remains in effect for the duration of the session, even if this
box is left unchecked. Koha 3.0 also does not require any validation for setting custom due dates (see
Figure 7, which shows a due date well in the past). This is clearly a problem, though it is fixed in Release
3.2.2. (Nighswonger, 2010).
In both systems, warnings and/or error messages pop up when the user attempts to check out an
item to a patron who has fines or has exceeded the maximum number of items on loan. The specifics of
these settings can be adjusted in the Administration area.
Since libraries accept book returns even when closed, an important feature of circulation modules
is the ability to ‘roll back’ the due date of an item as it is checked in. This function is provided by both
Evergreen and Koha, but is more straightforward in the latter system. Koha’s ‘dropbox mode’ can be
programmed to automatically roll back the date according to a pre-set pattern – it ‘knows’ when the
Koha & Evergreen Comparison
10
library was last open. In Evergreen, the user must enter the date manually.
Figure 7 – Renew Items in Koha Staff Client (Custom Due Date)
The overall functionality of the systems is very comparable for the check-in/out module, though
Evergreen offers better support for federated libraries. Koha’s ‘IndependentBranches’ function allows for
basic sharing of material and patrons to be turned on or off, but is less flexible than Evergreen and does
not have more nuanced separation features: either every branch set its own policy, or all branches share a
single group of settings. In contrast, Evergreen offers finely granulated levels of access. However, Koha’s
well-designed interface makes it a better choice here unless users are working at a large, federated library
system with multiple branches.
3.3 Renewing Items
Both Koha and Evergreen support consortia in this area, allowing renewal policies to be set on
local and on group levels. Also common to both are administrative options to allow staff override of
renewals and custom renewal dates. Setting a custom renewal date requires two steps in Evergreen: first
renewing the item, then extending the due date. It is possibly to simply extend the due date, but this will
not count towards item renewals. Another minor inconvenience is the need to refresh the screen after
renewing; the new date doesn’t appear automatically. The number of renewals allowed depends on the
item’s Circulation Modifier, which is controlled under in the ‘Local Administration > Circulation
Policies’ area. In the test case, the default circulation policy was recently adjusted to allow two renewals
for items that do not specify their Circulation Modifier in the ‘Item Details’ area as for many users, it was
previously causing problems by not allowing any.
The Koha staff client suffers from slightly more serious usability issues. The renewal function can
be found in both the Details and the Check Out sections of the ‘Patron’ screen. In the ‘Check Out’
section, the function appears in multiple places (see Figure 8). The ‘select all | none’ options underneath
the ‘Renew’ heading on the ‘Patron’ screen do not appear to do anything – also notice that this column
Koha & Evergreen Comparison
11
does not contain any check boxes. Furthermore, the dual function of the ‘Renew or Return checked items’
is not ideal from a usability standpoint. During testing, items were appearing as ‘Not Renewable’, but it
turns out the culprit was the circulation settings, which were set to allow no renewals. This option could
be overridden using the check box provided (see Figure 8). However, after renewing, the status of the
item reverts to ‘Not Renewable’. The user might therefore easily conclude that the renewal had been
unsuccessful. The system would be improved if it provided better user feedback and more informative
error messages. Error messages and alerts can be customized in the administration area, and the
frustration encountered in this instance shows the importance of doing so. Finally, it would also be useful
if Koha offered the option of renewing items from the ‘Item’ screen.
Figure 8 – Check-out Screen in Koha
Renewing from the patron account is a more user-friendly option. In Koha, renewal status and
renewal options appear beside checked out items in the patron account area (assuming that online renewal
is turned on, which is an administrative option). Renewal status is accompanied by any necessary
explanation, for example: ‘Not renewable (on-hold)’ (this particular setting, incidentally, can be adjusted
in the administration area).
In Evergreen, the patron renewal interface is very similar to that found in the staff client.
However, custom due dates are not an option, which simplifies things. The screen displays the number of
renewals remaining, which is more helpful information than the number of renewals used, which is what
Koha records. User reports do reveal one glitch: if a hold has been placed on an item, renewing that item
will then be disallowed even if the hold in question has been cancelled, unless the item has been checked
back in. This is an important point to be aware of.
3.4 Bills, Fines & Payment
Both Koha and Evergreen offer an extensive range of options for billing patrons and accepting
patrons. Please see Figure 9 (next page) for a detailed comparative summary of features.
Koha & Evergreen Comparison
12 Evergreen Koha
Pros Cons Pros Cons Overdue fines
• Overdue fines can be capped at item price
• Overdue rates adjustable according to item type, library branch, etc.
• Processing fee for lost items remains on patron account even if material is checked in within the hour
• Overdue fees can be set to vary by library, item type, and patron type
• Can check ‘Forgive item on return’ or ‘Forgive overdue charges’ before items are scanned, eliminating need to write off bills later
• Fines cannot be set to accrue by hour rather than by day (a useful feature for course reserves in academic libraries)
• Additional programming needed (cronjob) for finesMode function (handles calculation and accrual of fines)
Adding, deleting, and editing bills
• Bills’ ‘Full details’ button shows reason for charges
• Only staff at owning library can modify patron’s bill
• List of bill types is excessively long and vague; combines charges and credits
• Can create manual invoices and manual credit
• Payments reversible
• Not possible to edit bills directly, unless reversing payment
Paying bills and fines
• Partial payment allowed
• Multiple payment options (cash, credit, cheque, forgive, payment in kind, etc.)
• If bill for a lost item is voided, the item disappears completely from the patron’s account (no record of check out)
• Patron cannot pay in OPAC (payment upon self check-out available in later versions)
• Bug #705061: cannot void or pay fines from booking reservation overdue fines
• Clean, simple interface (particularly in comparison to Evergreen’s pop-up screens)
• Options to accept payment or write off fines
• Patron cannot pay fines through OPAC
• Partial payment not possible, except by using manual credit feature
• Staff client: Method and time of payment not shown
Accessing account history
• History of fines, payments, and current balance accessible through OPAC and staff client
• As mentioned, if bill for a lost item is voided, the item disappears completely from the patron’s account
• Patron can view outstanding charges and payments in OPAC
• No payment history available in staff client
Figure 9 - Summary of bills, fines, and payment features in Koha and Evergreen
3
3.
K
p
N
re
it
as
p
m
AE•
•
.5 Holds
.5.1 PlacingAddin
Koha has the
lacing a hold
Nevertheless,
ecord, title, v
t is well docu
s “Available
One f
lace of a pat
may frequent
Additional feEvergreen
Can changestart/expir
OPAC: genpatron on
g/Editing Hong a hold is e
option from
d for a patro
, Evergreen
volume, cop
umented and
e” until the s
feature both s
tron. Withou
tly take up st
atures:
e options incration date, anerally samenly allowed t
olds easy to do in
m the item se
n, whereas i
as greater fle
y, see Figure
d can be lear
taff changes
systems lack
ut this feature
taff time by
Figure 10 – E
cluding notifacceptable a
e steps and oo hold at me
n both system
arch results
in Evergreen
exibility than
e 10). Thoug
rned quickly
s the status, a
ked was listin
e, patrons m
inquiring ab
Evergreen Pl
fication, alternate formptions, but
eta or title le
ms. Evergree
page. Koha
n, the user m
n Koha whe
gh this funct
. Evergreen
and in Koha,
ng the numb
may become f
bout their hol
lace Hold Opt
mats
vel
Koha• Ca
d• OP
s
Koha &
en has an opt
has a conve
must find the
en placing a h
tion is not im
has the prob
, this happen
ber of total h
frustrated if
lds.
tion at Variou
a an change opdate, select fPAC: same ssame options
& Evergreen C
tion from th
enient list of
option from
hold at speci
mmediately o
blem in that
ns some of th
holds on an it
they have to
us Levels
ptions includfirst availablesteps, excepts
Comparison
e main menu
existing hol
m the ‘Action
ific level (i.e
obvious in E
a held item w
he time (kno
tem, or the h
o wait a long
ding start/expe or specifict use “Place
13
u, and
ds when
ns’ menu.
e. meta-
Evergreen,
will show
own bug).
hold
g time and
piration c copy
a Hold”,
Koha & Evergreen Comparison
14
• Editing: staff and patrons may change status, notification, pick-up location, activation and expiration dates, and cancel holds
• Editing: staff can edit priority and pick-up location (from item record), both staff and patron can cancel holds (from patron record)
3.5.2 Holds Pull Lists Evergreen • Selection from main menu (‘Circulation’) • Sortable and print option • Can also list holds ready for pickup • No function for creating a list of holds
waiting for copy
Koha • From circulation menu • Refine results by date, sortable (no specific print
option, but can do that from browser) • Can also view ‘Holds queue’ for specific branch or all,
‘Holds awaiting pickup’, and ‘Holds ratios’ Both systems are fairly with nice additions such as sortable fields. However, Evergreen seems to
have no function to report a list of currently unfulfilled holds (and none of the available documentation
suggests this function is in the new version).
3.5.3 Holds Capture Evergreen • Can be entered by staff when pulls from shelf • If item on hold checked in, staff notified with
basic information • Hold slip printed and notification sent out • Can check out an available item that another
patron has put on hold with no notification (even if on pull list, notification only if item has hold capture already set)
Koha • Cannot manually change status of item to on
hold • If item on hold checked in, staff notified with
basic hold/patron information • Confirm (and transfer if necessary) with option
to print out slips • If trying to check out item on hold, staff is
notified Hold capturing is definitely much better in Koha, and integrates well with its other functions. In
Evergreen, when a patron puts a book on hold, it is not automatically marked as such and an item can be
checked out by another patron if the patron takes an item off of the shelf before a staff member pulls it.
Although the details are not clear, based on the documentation (2010), Evergreen also seems to send a
notice to the patron when the item they placed on hold is checked in, and not when the item is ready for
pickup. Clearly, Evergreen can use some improvement, particularly in integrating their holds function
with the rest of the circulation module.
3.6 Changing Status of Items Evergreen
• Search for item and choose status from ‘Actions’ menu
• Can mark ‘Damaged’ or ‘Missing’ • To change back, item is checked in • Can mark ‘Lost by Patron’ or ‘Claim
Returned’ through patron record • Fines are calculated automatically, refunds
are not even if an item is found
Koha • Search for item and choose ‘Items’ • Can mark ‘Lost’ (‘Long overdue’, ‘Lost’,
‘Lost and paid’, ‘Missing’), ‘Damaged’, and/or ‘Withdraw’
• Change back on same screen • If marked lost while checked out by patron • Fines are calculated automatically including
refunds
ac
b
to
th
E
th
E
in
b
n
it
ar
3
K
m
se
• To unin andAltho
ccording to h
e changed th
o the item sc
he user diffe
Evergreen is
his case. Nev
Evergreen, w
ntuitive.
Koha
enefit of hav
eed to be no
tems that are
re returned,
.7 Changin
Chang
Koha. A table
modified acco
elect the patr
nmark these sd changes to ugh the two
how the func
hrough item
creen (and fin
rent options
more dynam
vertheless, K
with its need f
gives the us
ving a ‘Claim
oted manuall
e claimed to
which saves
ng Load Pe
ging the loan
e in the secti
ording to lib
ron category
statuses, itemreshelving systems hav
ctions are in
search or th
nes are calcu
depending t
mic. Whether
Koha’s consi
for an item t
ser more opti
m Returned’
y, which wo
be returned.
s time for use
eriod
Figur
n period, for
ion ‘Admini
brary, patron
y ‘Child’ or ‘
m is checked
ve similar fu
ntegrated wit
hrough patron
ulated autom
the view. Wh
r one is bette
stency may
to be checke
ions when m
status for th
ould not allow
However, K
er and patron
re 11 – Koha
example, of
stration > Ci
type, and ite
‘Young Adu
d •
unctions, they
th the rest of
n records. H
matically bas
hile Koha gi
er than the ot
allow the no
d in before i
marking an it
he patron. W
w for autom
Koha automa
n.
Circulation a
f DVDs for j
irculation an
em type (see
ult’ and the it
Koha &
When unse‘Available’
y handle the
f the system.
However, whe
ed on its pre
ives the user
ther comes d
ovice user to
its ‘Lost’ sta
tem as ‘Lost
Workarounds
matic reports
atically calcu
and Fine Rule
juvenile/you
nd Fine Rule
e Figure 11)
tem type ‘D
& Evergreen C
et or checked’ once more em differentl
In both syst
ereas Koha a
evious status
r a more con
down to pers
o learn the sy
atus can be re
t’, but Evergr
are possible
or statistics
ulates refund
es
ung adult pat
es’ allows lo
. In this case
VD’. Such a
Comparison
d in, item bec(no reshelvi
ly, presumab
tems, item st
always takes
s), Evergreen
nsistent intera
sonal prefere
ystem more q
emoved, is l
reen has the
e in Koha, bu
of the numb
ds when lost
trons is very
an periods to
e, the user w
a rule might
15
comes ing) bly
tatus can
s the user
n gives
action,
ence in
quickly.
less
added
ut would
ber of
t items
y easy in
o be
would
already
Koha & Evergreen Comparison
16
exist; fortunately, it is also easy to change it. According to the interface instructions, ‘To modify a rule,
create a new one with the same patron type and item type’. The new rule will replace the existing one.
Evergreen comes with a set of ‘Circulation Modifiers’. These are categories designed to “control
circulation policies on specific groups of items” (Evergreen, 2010). One of the default modifiers is DVD.
It is possible to set three different loan durations for a Circulation Modifier: ‘Short’, ‘Normal’, or ‘Long’.
This feature is typically used to control the circulation of DVDs on the item level. However, it is also
possible to link a loan duration to a particular patron group. The local administration options can be set to
allow patrons in the juvenile/YA permission group to take out DVDs for the two-week period and adults
for the one-week period for example.
If one had a section of DVDs that were marked specifically for juvenile/YA patrons, another
option would be to create a new Circulation Modifier to accommodate this. This too would be done in the
administrative section. As in Koha, this can be done on the branch level or across the system. However,
Evergreen has more advanced options for consortia; it allows clusters of branches to share settings,
whereas Koha either applies one setting to all branches or requires each branch to set a policy
independently.
4. Documentation & Help
Documentation for Koha 3.0 is not complete and seems to focus mostly on back-end settings. As
the documentation is in a single PDF file, it is not easy to skim through, a little difficult to navigate
without a linked table of contents, and has image markings in the wrong places. Novice users may be
daunted by the casual use of technical terms and concepts. The Koha 3.2 documentation is much better in
comparison. It is more complete, includes screenshots, and appears to be designed more for the end-user.
This difference may be attributed to the fact that the 3.0 documentation was a student project, whereas the
3.2 documentation is a continuing community effort. Although Koha 3.2 differs from 3.0 in a few areas,
we found its documentation material very helpful in our evaluation and frequently referred to it.
The Evergreen 1.6 documentation has fewer images and screenshots, but provides many step-by-
step instructions and explains its terms when appropriate. On the whole, the text is better organized and
easier to navigate, making good use of numbered and bulleted lists.
Informal support communities, such as listservs and wikis, are readily available for both systems.
However, the schism in the Koha community has the potential to cause some confusion among users.
LibLime refers users to a new support site, Koha.org, while the older communities are dominated by
ByWater users. There is considerable overlap in their coverage, but they are discussing different systems.
Koha & Evergreen Comparison
17
5. Conclusions
Koha’s interface is friendlier and more streamlined than that of Evergreen. Modules integrate well
with each other, as seen with automatic fine refunds and holds capture. It is generally more intuitive for
users, even considering its sub-standard documentation for the 3.0 version since the 3.2 documentation
can provide some support for users of earlier versions. As the staff client is web-based, there is also less
maintenance needed. The OPAC also has the added features of allowing patron tagging, comments, and
reviews. Müller (2011) also did an evaluation of several free and open source software ILS based on
software licensing, community, and functionalities for large libraries, and found that Koha was the leader
in all three categories and was the only to pass the full evaluation. Nevertheless, Müller advises that
Evergreen should also be seriously considered, which may be all the more true with the recent release of
Evergreen 2.0.
Evergreen provides more flexibility and functionality for consortia (see Figure 12). In addition,
our analysis above found a number of features that, though available in both systems, were designed
better in Evergreen (PIN resets, for example). Furthermore, its documentation is superior to that of Koha.
Consortial Features Evergreen 2.0 Koha 3.2 Library Groups yes yes Settings for Groups yes Multiple Branch Managements yes yes Floating Collection Management yes in development Granular User Permissions (per library) yes
Figure 12 - Consortial features in Koha and Evergreen (RSCEL & OS-OL, 2010)
Overall, the systems are very comparable. Libraries that belong to consortia may decide that
Evergreen is the better option for them; the advantages that it offers in this area will warrant its steeper
learning curve. Special libraries and stand-alone branches, on the other hand, might prefer to opt for Koha
as it generally has a more intuitive user interface. Ultimately, as is always the case when selecting
software, the better choice depends on the needs and requirements of the organization.
Koha & Evergreen Comparison
18
Works Cited
Breeding, M. (2009). Chapter 3: Major open source ILS products. Library Technology Guides, 44(8), 16-
31. Retrieved March 12, 2011 from
http://alatechsource.metapress.com/content/t75710j302n13447/
Breeding, M. (2011, January 27). Perceptions 2010: An international survey of library automation.
Library Technology Guides. Retrieved February 19, 2011
fromhttp://www.librarytechnology.org/perceptions2010.pl
Cormack, C. (2011, March 12). Question on Patron Search. Message posted to Koha electronic mailing
list, archived at http://lists.katipo.co.nz/pipermail/koha/2011-March/028119.html
Evergreen Community. (2010). Evergreen 1.6 documentation. Retrieved March 12, 2011 from
http://docs.evergreen-ils.org/1.6/draft/html/
Hadro, J. (2009, September 22). Liblime’s Enterprise Koha sets off debate. Library Journal. Retrieved
February 19, 2011
fromhttp://www.schoollibraryjournal.com/lj/technologyproductsvendors/855795-296/story.csp
Hellman, E. (2010, January 29). Who owns Koha? Retrieved February 17, 2011 from http://go-to-
hellman.blogspot.com/2010/01/who-owns-koha.html
Koha Library Software Community. (2011). Documentation. Retrieved March 12, 2011 from http://koha-
community.org/documentation/
Leonard, O. (2010). The Nelsonville Public Library chooses ByWater Solutions. Koha Newsletter, 1(2).
Retrieved February 17, 2011 from http://koha-community.org/koha-newsletter-volume-1issue-2-
february-2010/
Müller, T. (2011). How to choose an free and open source integrated library system. OCLC Systems &
Services: International digital library perspectives, 27(1), 57-78. Retrieved March 12, 2011 from
http://eprints.rclis.org/bitstream/10760/15387/1/How to choose an open source ILS.pdf
Nighswonger, C. (2010, December 2). Koha 3.2.2 is now available. Retrieved from http://koha-
community.org/koha-3-2-2/
RSCEL & OS-OL. (2010). OSLS Feature Comparison Matrix. Open Source Open Libraries. Retrieved
March 12, 2011 from http://www.os-ol.org/features