Visit our Facebook PageVisit our Youtube channel

Text Resize

-A +A

ILS Evaluation

Evaluation is one of the main steps of migrating to an OSS ILS. Libraries must decide if an OSS ILS meets needs that will vary depending on the type and size of the library system. Libraries should also consider the technical skills needed by staff members to implement an OSS ILS; if technical skills are lacking, you may need the help of an outside vendor or a partner library. In addition, libraries must evaluate the amount of time needed to perform migration as well as regular maintenance. It is important to consider time commitments because they are almost always connected to budget commitments. Although OSS is generally a more cost-effective option, library staff must be prepared to spend additional time running their system. Finally, although online resources are generally useful, contacting libraries that are migrating to or have already implemented an OSS ILS can be of great help in the evaluation process.

According to an article from the Public Library Association, the following criteria in particular should be considered when evaluating an OSS ILS:

  • There is current development activity with at least two substantial releases a year.
  • At least the cataloging, circulation, and patron access catalog modules are currently available; acquisitions and serials control are in development. If a library requires broader functionality, there are similar libraries that may share development priorities.
  • MARC is supported.
  • Current source code and technical documentation are available for downloading under the GNU General Public License.
  • The product is currently in use in a significant number of libraries.
  • Scalability is not an issue—there is no risk of database size or activity levels exceeding the capacity of the software. 

Of course, the main OSS ILS in the U.S., Evergreen and Koha, meet all of these criteria. Libraries that have already decided to choose one of these systems will need to consider other factors. The Massachusetts Library Network Cooperative has released a useful list of points comparing these systems:

consortium choice

Evergreen Pros:

  • Originally developed with consortia needs in mind.
  • Majority of current customers are consortia-based, so these needs continue to push the development.
  • System architecture designed with scalability in mind.
  • Nelinet planning to offer training and support on this platform.
  • Evergreen FullfiLLment project (a potential alternative to URSA) recently funded by State Library of Ohio.
  • King County Library System funding considerable development for software requirements "suitable for many large, urban, multiple-branch, centralized library systems."

Koha Pros:

  • Client functions run entirely within a browser (and, therefore, the system doesn't require any client updates).
  • System's browser-based architecture more in line with overall software industry development (and, therefore, an easier platform for outside developers to understand and work on).
  • Growing community of developers and support vendors.
  • Software and, perhaps, community slightly more mature (project started earlier than Evergreen).
  • Community very international resulting in quick translations of the software.
  • Evidence of a growing base of consortia "customers."
  • Heavy adoption in India, a country with extensive IT resources.
software

Evergreen Cons:

Koha Cons:

  • Consortia needs have not been a focus during early and recent development.
  • Many current features cannot be implemented well (if at all) in a consortium environment.
  • Upcoming development (such as new acquisitions module) still lacks certain consortia-friendly features.
  • Majority of current "library customers" are small and/or independent rather than large and/or consortia-based.
  • History of platform forking so that development is not always getting plowed back into the core.
  • Strong potential for Indian development to fork since they have had little contact with original developers and do not need IT support.
  • International aspects of Koha community can potentially divert development from U.S. library needs and/or make new releases less relevant for U.S. libraries than they otherwise would be.

Cost

Cost is an additional factor in evaluating an OSS ILS. For any ILS, costs accrue through software development ($100,000-$250,000), hardware ($300-$2,500 per patron), file migration (15 cents per record at most), configuration and installation ($25,000 at minimum), documentation ($6,500 on average), training ($1,500-$2,800 per day for on-site versus $125-$150 per day online), and ongoing support ($9,000-$15,000 per year versus $150 per hour of bug fixing). All OSS ILS will save money by lacking the software license fees of proprietary equivalents, which range from $30,000 to $500,000.


Best Practices for Evaluation

Who makes the decision?

  • If in a single library, one or two people, usually the library director and whoever is serving as the tech person.
  • If in a consortium, a committee, often either the library directors or technical people.
  • However, regardless of the size of the library system, even though these are the people making the decisions, you should always try to include as many groups as possible in the decision to move to open source.

Which ILS?

  • Make a list of requirements and don't migrate until they are all there.  This checklist is so you don't lose any key functionality because of migration.  This is a step where you can involve more than just the systems staff.  Asking the different departments what they're needs are ensure that the final decision includes everyone and hopefully will help build internal support for the migration.
  • Know your staff's abilities before committing.  Migrations are difficult in general.  Knowing what your staff's abilities are will show what kind of external help you will need for the migration.  This step is also about developing skills internally.  If you have time you can always start your staff on developing the skills needed before migration begins.  Lastly, knowing the staff will determine who is going to be on your migration team.
  • Talk to other libraries. They are a great resource for seeing how the system actually works, asking questions about the migration process, and providing information about possible problems.  If possible talk to a library that migrated from your current ILS.  Some systems are easier to migrate fom than others so this would be an opportunity to find out about any specific problems.  This connections can also come in handy later in the process.
  • Running any open source software requires technical skills, so develop skills internally even if you use a vendor for migration.  The goal should be to try to lessen the library’s dependence on vendors.
  • Have a development system: pre-migration can be used to test and train, post-migration can be used to help find solutions to problems.  This will also help develop skills internally.Make sure everyone understands the open source culture – there is no vendor to complain to, so if there is something you want changed, you have to do it yourselves (which is often considered both the best and worst thing about having an open source ILS).
  • Communication is key:
    • If working with a vendor, have a designated liaison with the vendor so all questions go through one person.  If in a consortium, this is even more important because you do not want every library asking the vendor the same questions.
    • If in multiple branches or a consortium, develop some kind of system so that everyone stays informed throughout the process.  One way to do this is to have one person at each library be a liaison between their library and the committee working on the migration.  That way there is a designated channel for any questions or problems to go through.
  • Be prepared to commit a significant amount of staff time for testing, development, and so forth.  This process can take a long time depending on how long you spend in each step. This process can take anywhere from six months to several years.  If your library is doing it all internally without a vendor, then staff time is going to increase.