Why Migrate to an Open Source ILS? Librarians with Adoption Experience Share their Reasons and Experiences

DOI 10.1515/libri-2013-0016 Libri 2013; 63(3): 206−219

Vandana Singh

Why Migrate to an Open Source ILS? Librarians with Adoption Experience Share their Reasons and Experiences

DE GRUYTER

Abstract: Interest in migrating to open source software integrated library systems (OSS ILSs) continues to grow in libraries. In this research, twenty librarians who have worked in institutions that migrated to OSS ILS, or are in the process of migrating, were interviewed about re-sources for research and reasons an OSS ILS was chosen, including cost-effectiveness, ease of use, community and vendor support options, flexibility and customization, compatibility with other software, and an “ethic of shar-ing.” Librarians can find additional information at an online information portal created from this research at http://www. opensourceils.com.

Dr. Vandana Singh: Assistant Professor, School of Information Sciences, University of Tennessee, Knoxville, Tennessee, U.S.A. Email: [email protected]

Introduction and Problem StatementLibraries are facing a host of challenges and demands to provide services and support to their patrons. They must keep pace with changing technologies, implementing new hardware and software before it is tested or understood. They must cope with ever-shrinking budgets and con-stantly justify their value to their communities. They must do all of this with demand and use by patrons increas-ing. Many libraries see open source software integrated library systems (OSS ILSs) as a solution to some of these problems. Since their source code is free and open to the public, an OSS ILS offers benefits such as flexibility, cus-tomization, and cost-effectiveness. According to Breeding in his article “The New Frontier” (2011), although OSS ILSs require more work for library staff in terms of customiza-tion and maintenance, libraries are migrating to OSS ILS options in greater numbers as the software and commu-nity support become more robust.

Based on surveys conducted to identify interviewee respondents, two of the most popular OSS ILSs in the

United States are Evergreen and Koha. Evergreen, which was developed by the Georgia Public Library Service in 2006, was built for the scalability needs of a consortium. Koha was created in 1999 by Katipo Communications and is being used in all types of libraries. Both of these OSS ILS options and many others have various paid and com-munity support networks to help libraries with migration and maintenance.

Most of the literature provides anecdotes or case stud-ies of individual libraries’ migration process, but this data is not applicable to all types of libraries and does not provide broader suggestions or best practices for consid-eration. This research seeks to fill this gap by reporting on interviews with twenty librarians from various types and sizes of institutions, and includes descriptions of the mi-gration process, comparisons of functionalities and main-tenance of an OSS ILS versus a proprietary ILS, rationales for choosing a specific OSS ILS, and general and technical resources for customization, troubleshooting, etc. The in-terviewees were chosen from a list of willing respondents from a previous survey that was sent out to various library groups and discussion lists. . It is hoped that this research will provide a broader picture of the development and functionality of OSS ILSs. It will also help libraries con-sidering migrating to an OSS ILS to better understand the migration process, to foresee the challenges and benefits, and to evaluate options for software and support.

Literature ReviewAccording to the literature and surveys conducted to iden-tify the interviewees, Evergreen and Koha are the most popular options for academic, public, and special libraries in the United States. Pace (2006) writes that the history be-hind Evergreen in particular is interesting and impressive, involving collaboration among many libraries from the very beginning. The article “Open ILS Plan for Pennsylvania PLs” (2010) describes how all public libraries in Pennsyl-vania hope to migrate to Evergreen. Dykhus (2009) writes

Brought to you by | Purdue University LibrariesAuthenticated | 128.210.126.199

Download Date | 9/11/13 12:46 AM

Vandana Singh, Why Migrate to an Open Source ILS? 207DE GRUYTER

that a large number of libraries in Michigan are migrat-ing to Evergreen as well. The article “Outsell Study Finds Koha is Open-Source ILS of Choice” (2009) describes Koha as another key player that has become widespread in all types of libraries such as corporate, government, academ-ic, school, public, and nonprofit institutions. According to Puckett (2008), many museums are also adopting and cus-tomizing OSS ILSs. Breeding (2011) writes that many major library systems, such as the Sage Library System of Eastern Oregon, the Pioneer Library System of New York, and the King County Library System in Washington have chosen to migrate and receive support from Evergreen and Koha ven-dors. According to the article “OLE Project Gains Support of Kuali Foundation” (2009), there are also other options for support such as the Kuali Foundation used by the Open Library Environment (OLE) Project.

Carlock (2008) has shown that OSS ILSs are flexible and adaptable for all types of libraries; this is true even on a global scale. According to Zou and Liu (2009), libraries in China have successfully customized Evergreen to meet their patrons’ needs. Tajoli et al. (2011) write that the same thing has happened in Italy with Koha. Many government libraries in Pakistan have also migrated to Koha success-fully, write Shafi-Ullah and Qutab (2012).

According to Hughes, the growing participation and sophistication of OSS ILS conferences is another testament to its maturity as a software package (2011). Although, in 2007, librarians had a “passive” attitude toward OSS ILSs, according to Jaffe and Careaga (2007), it is clear that they have now become popular options because awareness has spread and support communities have become stronger. According to the article “SirsiDynix Document on Open Source Draws Fire” (2009), this trend has prompted some proprietary ILS vendors to challenge the functionality and reliability of OSS, but many libraries argue that OSS ILSs are now well developed and robust enough for library use. Breeding (2009a) states that some proprietary vendors have taken the opposite stance and have tried to become more “open” or transparent to better compete with OSS alternatives.

However, most libraries agree that not all OSS ILSs are equally robust in meeting their needs. When critically examined based on forty criteria, Muller (2011) found that among OSS ILSs only Evergreen, Koha, and PhpMyBibli (PMB) perform well enough for even basic functionalities. There are also distinct differences between Koha and Ev-ergreen that make each more preferable to certain types of libraries. Koha offers better Web 2.0 features, which Yang and Hofman (2010) say are often desired in libraries, but Terlaga (2010) emphasizes that it lacks the scalability for large consortia. In the article “Equinox, NELINET Partner”

(2009), Evergreen is noted for its ability to scale. Equinox is just one of many technical support companies or “ven-dors” that support libraries’ migration to and maintenance of their OSS ILSs for a fee. According to Longwell (2010), however, some academic libraries are unhappy with the slow development of some of Evergreen’s modules, such as those for acquisitions, serials, and cataloging.

In terms of why OSS ILSs are selected, libraries usually refer to their cost-effectiveness. In fact, according to Rapp (2011), “economics” is perhaps the number one reason US libraries migrate to OSS ILSs. Although libraries still have to pay for software support, training, and staff time, they do not have to pay for the software itself, writes Florin (2011). According to Dennison and Lewis (2011), when the Paine College Collins-Callaway Library in Augusta, Geor-gia, migrated to Koha, it reaped financial savings, includ-ing using less server space. Egunjobi and Awoyemi (2012) write that the economic benefit of using an OSS ILS is seen especially in poorer countries like Nigeria, where libraries that have been unable to afford an ILS relied on the card catalog system for their records and patrons.

According to Breeding (2009b), flexibility is another reason why many libraries have migrated to OSS ILSs, which give libraries more control over their data and soft-ware (although this also requires more programming and troubleshooting that were previously handled by the ven-dor). Libraries are also better able to adapt to changing needs and circumstances with the flexibility and customiz-ability of OSS ILSs. Many academic and special libraries cite this flexibility as the main reason for migrating, includ-ing the New York Academy of Medicine (Genoese and Keith 2011), the University of Pennsylvania (Berenstein and Katz 2012), and a host of law libraries (Wale 2011). This flexibil-ity makes OSS ILSs highly interoperable with other types of software, even proprietary software. Liu and Zheng (2011) write that the University of Windsor Leddy Library customized Evergreen to work with its proprietary link re-solver for serials. According to the article “Enhanced Koha Bibliographic Content” (2009), libraries that receive Koha support from LibLime benefit from a partnership with a proprietary vendor that enhances bibliographic content.

Libraries cite the robust functionalities of OSS ILSs as a reason for migration from a proprietary ILS. Berenstein and Katz (2012) write that OSS ILSs enable users to have the full range of functionalities of a proprietary ILS, includ-ing browsing catalog records, the creation of digital library items, institutional repository holdings, bibliographic ma-terials, and other collections and resources. Chen and Al-bee (2012) write that Evergreen especially is strong on core functions like collection discovery and interlibrary loan. According to Trainor (2009), many OSS ILSs offer Web 2.0



208 Vandana Singh, Why Migrate to an Open Source ILS? DE GRUYTER

functionalities, such as user tags, reviews, and comments. Westbrook (2011) writes that a number of libraries prefer Koha’s web-based module, which requires no software to install. Koha can also send electronic availability and over-due notices to patrons, according to McDermott (2012). Of course, no software option will provide all the desired func-tionalities, and OSS ILSs and proprietary ILS are both still in development. McDermott writes that Koha still needs some development for authority records, label creation, and of-fline circulation. Nonetheless, OSS ILSs are not far behind their proprietary counterparts in terms of functionalities.

After deciding to migrate to an OSS ILS, libraries described their satisfaction with the ease of the migra-tion process. According to McDermott (2012), the Crowell Public Library in San Marino, California, had a smooth migration to Koha since LibLime staff members answered questions quickly and thoroughly. Walls (2011) writes that the New York University Health Sciences Libraries also migrated to Koha using the vendor ByWater Solu-tions and were satisfied with the software configuration to existing policies, the training, and the support. Terlaga (2010) says it sometimes takes just a single staff member to champion the migration process. According to Dennison and Lewis (2011), one of the benefits of using a vendor to migrate is that library staff can sometimes receive training to spearhead the process. Of course, Dennison and Lew-is acknowledge that most libraries will also experience problems during migration; certain types of data (such as MARC records) can be difficult to migrate depending on the particular proprietary and OSS ILS in question. In the US in particular, using MARC records in an ILS is very common, so making sure that the system can work with MARC records and migrate correct formatting is vital. The experience of formatting records may differ substantially for international libraries that follow a different standard. According to Kohn and McCloy (2010), larger libraries and consortia often migrate in waves or phases to make the process easier and extend it into multiple fiscal years.

When difficulties arise, the OSS community is a great place to turn to for help; libraries cite this as a major consid-eration in choosing an OSS ILS. Phillips (2009) writes that online community support and documentation is free, high quality, and very involved. Vendor support for OSS ILSs is also usually quite good. According to the article “Equinox to Support Koha Open Source ILS” (2010), Equinox, which actually offers support for both Evergreen and Koha, has helped various libraries in the migration process fix bugs related to record duplications, merging records, and other issues. Hamby (2012) writes that the South Carolina Ever-green Network Delivery System (SC LENDS) shared the code Equinox helped them develop with other libraries. Other

vendors include ByWater Solutions, which provides migra-tion, hosting, and support for Koha (“Nelsonville Public” 2010); the Kuali Foundation, which supports the OLE Pro-ject (“OLE Project” 2009); and PTFS and LibLime, which are working together to make Koha support even more cost-effective (“PTFS Acquires” 2010). In general, each company specializes in one or more specific OSS ILSs

Finally, some libraries choose an OSS ILS because they believe it fits with the ideals and ethics of libraries in general. Westbrook (2011) writes that there is an “ethic of sharing” information in public libraries that many want to carry over into their software in addition to their services. According to Bailey and Back (2009), the more libraries can share and create common standards for OSS ILSs, the better these products will be for libraries in the future.

Clearly, there is much literature being written about OSS ILSs as the software becomes more robust and new partnerships, support, and development opportunities emerge. Most of these articles discuss how individual li-braries or consortia evaluated and migrated to OSS ILSs and report on challenges they faced or successes they achieved. Some articles charting general trends in OSS adoption in libraries are also available, but these usually do not represent the experiences of librarians themselves. This research seeks to fill this gap by providing a general study that takes into account the migration and evalua-tion processes of libraries for a variety of OSS ILSs, mainly Evergreen and Koha. Although the Kuali Open Library Environment (OLE) is also a rapidly developing OSS ILS option, the majority of libraries that volunteered to be in-terviewed use either Evergreen or Koha. It addresses the question of why libraries choose OSS ILSs in terms of com-parisons to proprietary software, various functionalities, avenues for support, and other major areas of concern.

Procedures

Research Questions

All of the research questions developed by the research team in the survey and interviews seek to explore the question of why libraries chose OSS ILSs over proprietary options and how they experienced the benefits of OSS ILSs before, during, and after migration. In addition to clarification about the implementation timeline, the re-search questions to the participating libraries focus on the following topics:1. How do libraries evaluate and choose their OSS ILSs

based on general experiences?




2. How do libraries evaluate and choose their OSS ILSs based on functionality requirements?

3. How do libraries evaluate and choose their OSS ILSs based on maintenance requirements?

4. What resources do libraries consult for research choosing an OSS ILS and seeking support?

Data Collection Method

Interviews were chosen as the primary means of data col-lection to gather rich information that could be analyzed using qualitative methods. The goal was to look beyond the practitioner articles to see what kinds of trends are related to the migration process in multiple libraries. According to Jizba (2003), interviews provide in-depth “case-study description.” Moghaddan and Moballeghi (2008) write that the most useful aspect of interviewing is the ability to follow up on an answer that the participant gives. This en-sures that the same type of information is gathered from every interview. This is unlike surveys, where sometimes participants do not respond in a way that answers what the researcher really wants to know. Interviews also have a better response rate than surveys. Telephone interviews were used due to the geographic dispersion of the partici-pants. Interviews enabled conversations with librarians from all over the country instead of just within a single area. The interview questions are listed in the Appendix.

As a disclaimer, a sample size of twenty libraries does not provide statistical significance for numerical data. Re-searchers sought to interview professionals from a variety of library types and sizes to collect different experiences regarding the selection, implementation, and ongoing maintenance of OSS ILSs. As in the Delphi method, doing multiple rounds of interviews can reveal interesting data and developments over the long term. Survey respondents who provided their contact information for follow-up in-terviews were chosen.

Data Sources

The objective was to collect data from a variety of library types and sizes to compile a wide range of data. Email in-vitations for interviews were sent to Koha and Evergreen listservs and to other library-related listservs. The email requested volunteers to participate in telephone inter-views to share their experiences with OSS ILSs. Potential participants identified via email and were contacted by re-searchers to schedule phone interviews. The list of inter-view questions was emailed to the participants before the

interviews to allow them to prepare. The interviews were conducted with librarians working in a variety of librar-ies, including nine libraries using Evergreen and one in the process of migrating to Evergreen. Seven responding libraries were using Koha, two were using other OSS ILSs, and one was using a proprietary ILS while evaluating an OSS ILS. The majority of the respondents were from pub-lic libraries (eleven respondents), while there were also four special libraries, three academic libraries, and one school library. Researchers requested information about the size of the library collection. Seven responding librar-ies owned collections of less than 100,000 items, seven had collections of 100,001-999,999 items, and four owned collections of over 1,000,000 items. Respondents ranged from all over the US and included one library located in Afghanistan (the ILS was installed in the US). Table 1 de-tails the description of this data.

Data Analysis Methodology

The research team consisted of three graduate research assistants (GRAs) and their supervisor. Two GRAs sched-uled the interviews via email and conducted them over the phone using a digital recorder. The digital recordings were then uploaded to the project website, where the third GRA listened to them and transcribed them into Microsoft Word documents. The Word documents were also upload-ed into the project website. The GRAs who conducted the interviews then coded the documents for easier analysis. Some sample codes include “Comparison of OSS and Prop Experience-Functionalities,” “Concerns with OSS ILS,” “Decision Making,” “Problems with Previous System,” “Rationale,” and “Lessons Learned.”

Once identifying information was removed from the transcribed documents, the transcripts were uploaded into Dedoose, a Web-based analysis program (http://www.dedoose.com/) supporting qualitative and mixed methods research. Dedoose provides online excerpt selec-tion, coding, and analysis by multiple researchers for mul-tiple documents. The research team used an iterative pro-cess of qualitatively analyzing the resulting documents. This method used multiple reviews of the data to initially code large excerpts, which were then analyzed twice more to extract common themes and ideas. Researchers began by reviewing each document for quantitative information, including the library type, ILS in use, number of informa-tion technology (IT) staff, and size of the collection. This information was added as metadata descriptors to each document in Dedoose. Upon review of the transcripts and in discussions about the interview process, research-




ers began to conduct a content analysis of the qualitative data. Codes were created based on this initial analysis to aid in categorizing the data from the interviews. Two coders coded the entire dataset, specifying categories and themes to the excerpts from the interview transcrip-tion. All of the excerpts from each coder were compared with the excerpts from the other coder. The coders earned scores of .96 and .95 using Cohen’s kappa statistic, which measures the agreement of different raters of interviews, indicating very high reliability.

ResultsResults from the interviews were divided into four catego-ries: evaluating and choosing OSS ILSs based on general experiences; functionalities; maintenance; resources con-sulted to make those evaluations. This section begins with information about migration and implementation of OSS ILSs to provide context before describing each part of the evaluation process in more detail.

Implementation Timeline

The interview respondents provided a range of migration and implementation schedules. Some had not yet migrat-

ed and were still in the research stage. Others migrated according to different timetables: a weekend, two weeks, six weeks, one month, two months, three months, eight months, and several months. One library reported, “No, no we didn’t have any major problems at all. We had a fantastic experience. . . Our circulation librarian has been working in the field for decades and she said she has nev-er seen a migration go so smoothly.” According to another library, “It’s just taken a few months to actually get the migration because we have forty-one years of data to mi-grate, and just prepping for launch basically.” The time-tables differed depending on the needs of the library and available technical support.

Evaluations Based on General Experiences

OSS ILSs – Positive Evaluation

Of the libraries interviewed that provided a positive evalu-ation of OSS ILSs, almost 30 percent were public and 30 percent were special libraries, compared to 25 percent ac-ademic libraries and 20 percent school libraries. In terms of size, most of the libraries that were satisfied with their OSS ILSs were small libraries. Libraries of other sizes seem to be equally satisfied or dissatisfied (see Figure 1).

Costs paid to a vendor for programming, problem solving, updating, and training are transferred to libraries

Table 1: Description of Libraries

Library Size (number of items in collection) Library Type ILS Used

Under 100,000 Academic KohaUnder 100,000 Public EvergreenUnder 100,000 Public KohaUnder 100,000 Public KohaUnder 100,000 Public Koha-BywaterUnder 100,000 Special KohaUnder 100,000 Special Proprietary-Considering OSS100,000-1,000,000 Academic Evergreen-Equinox100,000-1,000,000 Public Evergreen100,000-1,000,000 Public Evergreen100,000-1,000,000 Public Evergreen100,000-1,000,000 Public Evergreen-Equinox100,000-1,000,000 Public Millennium-In process of migrating to Evergreen100,000-1,000,000 Special KohaOver 1,000,000 Academic Kuali OLEOver 1,000,000 Public EvergreenOver 1,000,000 Public Evergreen-EquinoxOver 1,000,000 Special Collective Access

Public EvergreenSchool Koha




during migration to an OSS ILS. Staff time and investment are required for installation, upgrades, programming, troubleshooting, training, and preparing documentation if needed. However, many libraries maintain that OSS ILSs cost less than proprietary options and choose them because of tight budgets. One responding library com-mented, “Of course the economy went down then, with the training we had budget issues. So we just could not aff ord anything that was more proprietary-based.” Public and state libraries have chosen Evergreen for this reason. Some libraries would not be able to automate without an OSS ILS, saying it “just wasn’t feasible” to pay over $30,000 for a proprietary ILS.

Many libraries prefer the ease of use that is part of OSS ILSs, which oft en provide easy-to-understand, browser-based interfaces that are both user-friendly and cost-eff ec-tive. According to one library, Evergreen’s use of the tab interface makes it very “intuitive” for users because it is something they are already familiar with from other web-sites and makes important links readily visible and avail-able. The fact that OSS ILSs are stable means that staff can spend less time on maintenance and more time on train-ing, updating, and troubleshooting.

Some libraries evaluated OSS ILSs based on vendors and support options. While certain libraries liked not hav-ing a vendor, others found the OSS vendors to be more re-sponsive as noted in this reply: “Equinox has never said ‘have you checked the manual?’ when I call for help. Nev-er. I used to get that routinely from [the proprietary ven-dor] even though we were paying them more than double what we’re paying Equinox. They are very helpful.” Many libraries also like the fact that the OSS community is avail-able for support. One library thought the support avail-able for Koha was just “really awesome.”

Proprietary ILSs – Negative Evaluation

Some libraries think proprietary ILSs are just too expen-sive, impede their work, and create barriers for their pa-trons’ access to information and resources. Consider the following response: “They have a licensing system where you can only have so many clients at a time. And what was happening is that we were running out of, we were getting people knocked out all the time. And that we could not af-ford additional licenses.” Feedback also included the fact

Figure 1: Reasons for a Positive Evaluation of OSS ILSs by Library Type and Size.




that processes and workfl ows were just too complicated with the vendor’s soft ware. Other libraries complained about vendors who would not help them or respond to their problems. One library noted, “You just report the bug and they say, okay, this is a bug, thanks for report-ing it, and they never get back to you.” Ultimately, the big concern with proprietary ILSs is that the libraries do not actually own or control their own data.

OSS ILSs – Challenges and Concerns

Among the diff erent library types, school libraries seem to be the most concerned about or have had challenges with OSS ILSs; over 30 percent of the respondents that had challenges or concerns were school libraries. In contrast, only 25 percent of the respondents that reported chal-lenges were special libraries, and a little over 20 percent of the respondents that reported challenges were academ-ic or public libraries. In terms of size, mid-sized libraries seemed to have more challenges than small libraries and large libraries. This could be because mid-sized librar-ies have the challenge of larger numbers of records than

small libraries, but do not have as many staff members or as much support as large libraries (see Figure 2). Almost 35 percent of the libraries that reported concerns were mid-sized compared to around 25 percent of small libraries and under 20 percent of large libraries.

Almost all of the respondents wrestled with the fact thatan OSS ILS is more expensive than anticipated, but most agreed that it makes up for the cost by providing additional and more fl exible features. Note the following statement: “We had to balance that off as the worst, the extra, and the upfront initial cost to make this change. I think it is, I think it’s better for the patrons, I think it’s better for the staff .”

Less surprising is the fact that OSS ILSs can take up a lot of staff time, which is usually dedicated to soft ware development and customization. According to one library, “You know that happens with any soft ware project, but these are things you don’t get to see when you’re just buy-ing a vendor.” If the library chooses an OSS ILS without a web interface, it will also be responsible for hosting the soft ware. Not having a vendor to handle problems also means that libraries have to spend more staff time and ef-fort learning about the system, troubleshooting, custom-izing, training, and producing documentation. Of course,

Figure 2: Libraries’ with Challenges and Concerns about OSS ILSs by Library Type and Size.




having detailed and customized documentation for an individual library is useful for any type of software, not only OSS ILSs. A related challenge is conveying this need to external supervisors and administrators.

There is often a steep learning curve for library staff to understand how to fix problems and use the system well. One response notes, “This does things much differently than any other system that I have ever used, and probably because it’s open source, too. So it’s taken awhile to learn how to do things. There were some customizations that I didn’t recognize that we could do, some tweaking that I hadn’t thought of before.” Some libraries cope with these challenges by hiring OSS ILS vendors. The software code remains free, but the vendors charge fees for migration, maintenance, troubleshooting, etc.

When working with OSS ILS vendors, libraries run into the difficulty of not having enough support options availa-ble. OSS ILS vendors are sometimes unresponsive. Libraries struggle to communicate with OSS ILS vendors. Sometimes the vendors do not understand the library’s perspective. One library noted, “We have found that [the proprietary ILS] was created by a company that really knew libraries and employed a lot of librarians, talked to librarians as they did it. I think some of the people developing Evergreen maybe never talked to librarians very well.” As a result, it can be hard to get the vendors to recognize problems.

OSS ILS communities provide information and sup-port for libraries, but these are far from perfect. Commu-nity support can be unpredictable. There are not enough skilled developers working on OSS ILS projects, so many of those who contribute lack the proper knowledge and can cause confusion by referring to terms incorrectly, not specifying the right updates and versions, etc. As a result of these issues, documentation is incomplete and often lags behind new features, as noted in this response: “I know lack of documentation has been a major complaint. I would say that it’s a thousand times better than when we went live, but there’s still a lag time. You know with a community of volunteers, people have really good inten-tions, including myself, to put documentation out there but it doesn’t always happen.” Sometimes the community documentation is simply inaccurate.

Evaluations Based on Functionalities Requirements

OSS ILSs – Positive Evaluation

One of the best things about OSS ILSs is that they employ a modern architecture, as noted in the following comment:

“The best thing about Evergreen is that it really is a very modern architecture. It is not carrying any baggage from previous generations of ILS in it. So kind of like, you know if modern web developers would make an ILS, it would probably look a lot like this.” Although proprietary ILSs can also have well-designed architecture, they are more likely to have baggage because they were not newly devel-oped but emerged from many updates and add-ons. OSS ILSs have unique features that libraries can use such as those for multimedia collections and different languages. One library reported that its patrons were “thrilled” with the new functionalities of the upgraded system.

Many libraries also like the fact that OSS ILSs are flex-ible, customizable, and open to change. The ability to cus-tomize can be a major source of improvements in design and navigability. Libraries can focus on the functionali-ties they need for their unique patrons, as reported by this institution: “We would focus on the functionality that we want to bring to the system as opposed to waiting for an-other company to roll out what they think is the next big thing.” Libraries can also choose the extent to which they alter or expand upon the OSS ILS source code. OSS ILSs are compatible with many other types of software but they can also meet basic requirements with minimal configura-tion for libraries lacking technical expertise.

Proprietary ILSs – Negative Evaluation

The strengths of OSS ILSs in terms of functionalities are often weaknesses of proprietary ILSs. Respondents noted that vendor software offers little to no options for flexibil-ity or control, as illustrated in this remark: “We had a con-siderable amount of dissatisfaction along with other large libraries with the lack of flexibility and lack of ability to control our own destiny with the vended software.”

Despite their high costs, proprietary ILSs often lack functionalities. Even basic requirements and standards may be unmet, as noted in this comment: “The current system is constraining our business in that we can only do what it does. And there’s things that we want to do that it can’t do, that they have no plans to make it do.” Proprie-tary ILSs are also plagued by functional errors. According to multiple interview respondents, displays of MARC re-cords and data loss in acquisitions modules are notorious problems in some of the vendor software options.

Most proprietary ILSs are not scalable to meet the needs of large library consortia. One institution reported, “The main problem was that they had reached a tipping point with [the proprietary ILS]. They just could not han-dle any more members in the consortium. It was just get-




ting too big for [the proprietary ILS] to handle.” This is a problem because many public and academic library con-sortia also face increasingly tight operating budgets. The OSS ILS Evergreen appears to be the only viable option on the market to meet this need.

OSS ILSs – Challenges and Concerns

Of course, it is important to remember that many of the problems encountered during migration are not unique to open source but rather occur in almost any kind of soft-ware change. However, libraries’ unique position of con-trol and responsibility with their OSS ILSs can exacerbate certain migration issues. Because the development com-munity for OSS ILSs mainly consists of volunteers, the re-lease of updates and bug fixes can be unpredictable. This is reflected in the following comment: “That same lack of centralized control means that it’s a lot more chaotic, that you can’t predict when the new releases are going to come out. . . . You know they’re all doing their best, and they’re just not, it’s a kind of runs-by-consensus, and consensus takes a long time.” OSS ILSs typically have more bugs be-cause they are newer software, although usability testing can help to find and resolve bugs. Of course, it is just as important to test a proprietary ILS or any type of software before adoption as it is to test an OSS ILS to ensure that it is going to meet patrons’ needs. Any time library software changes, making patrons aware of what they can expect in the change and how they will need to adapt can make the actual process of change much easier and lessen the num-ber of questions from patrons in the future. A responded noted, “The worst thing is that it’s not fully developed. It’s a young ILS, and it’s not as fully developed. [The proprie-tary ILS] is an old, old ILS, and they’ve had a lot of years to iron out the bugs.” As newer software, OSS ILSs can also lack a mature architecture and structure.

It is harder for libraries to develop functional speci-fications for OSS ILSs because they have not been devel-oped to the same extent and with the same consistency as proprietary ILSs. In some cases, OSS ILSs have fewer or weaker functional modules, as reported in this comment: “There’s still holes in functionality that people are suffer-ing with, especially the people that are buying books and stuff. “ Privacy, inventory, reporting, acquisitions, and cir-culation modules are key areas of weakness in develop-ment.

Libraries also struggle with customizing their OSS ILSs. Some libraries may be the only one with a certain need, which means they will not receive development energy or support from the community, as noted in this

response: “I sometimes feel like, well, are we the only one’s out there doing this requirement. And so I think sometimes it feels like you’re the only one who might be doing something where in a proprietary system you might be able to reach out.” On the other end of the spectrum, sometimes individualized customization is so easy that libraries “fork” their software, meaning they significant-ly change the code, making collaboration more difficult. One library commented, “The worst thing about having an open source ILS because you can tweak it so easily,” which makes collaborating on training and resource de-velopment all but impossible. Some OSS ILS options are still not very compatible with other types of software. For example, it can be difficult to make them work with pro-prietary software like link resolvers and PC reservation systems.

Evaluations Based on Maintenance Requirements

The time spent on OSS ILS maintenance seems to depend on the individual library. According to the interviews, some respondents think it requires less time than propri-etary options, others think it requires the same amount of time, and still others think it requires more time. Most en-vision spending more time on customization than mainte-nance in the future or think the cost savings make the time and effort worthwhile. This sentiment is illustrated in this remark: “I would say system maintenance I don’t spend very much time at all. What I’m spending a lot of time still doing is customization because people are still unhappy with the way things appear on the screen, that they want something in a different place or something like that.”

Some upgrades to OSS ILSs are difficult or do not actu-ally fix bugs, as reflected in this statement: “We did that upgrade probably I’d say four or five months into our evo-lution because we were told that the latest version might stop some of the bugs we were seeing. . . . I don’t really believe that the upgrade actually fixed any of those.” On the other hand, most libraries agree that maintenance for proprietary options is both expensive and requires too much work, as noted here: “We were often building custom codes or simply just having to do workflows that are cumbersome and not productive. And we wanted to move into an environment that would give us more flex-ibility and control over our workflow.” Not only are many proprietary systems impossible to update, some of them are no longer being developed. One respondent reported, “It’s been about 10-11 years since using this product. And it was highly customized. . . . So pretty much they’ve been stuck in the same system.”




Resources Consulted for Research

General Research

To get an objective, informed opinion in their decision-making, many libraries seek the recommendations of external consultants, vendors, or developers when evalu-ating and choosing an ILS. One respondent said, “We set up a test server at Alpha-G [Consulting] and tested and tweaked . . . until we were pretty sure that it was the right move.” Others choose to complete research internally through teams, testing, feasibility studies, and requests for proposals (RFPs). A respondent noted, “It was a very comprehensive RFP. And we were really pleased with the way that worked. . . . Actually they have, I don’t know, thousands of questions that you can pick and choose to add to your RFP. And so you sort of make up your own RFP with their list of questions in various modules and areas you can select the modules that you want in, you want to get quotes on. So it’s really comprehensive. And we would recommend it highly.”

Seeing the lack of scholarly articles written about OSS ILSs until recent years, it is clear that it took longer for aca-demia to catch onto the trend of OSS adoption in libraries. Now, however, many scholarly journals address questions related to the evaluation and implementation of OSS ILSs. There are also many opportunities to discuss OSS ILSs and share resources at conferences and workshops, as noted in this comment: “When I go to conferences, the open source vendors have really been stepping up their pres-ence, and so the literature that I pick up from the booths at conferences has been really helpful.”

Personal Factors

Personal reasons – such as an individual staff member’s experience or contacts with other libraries – often influ-ence why libraries choose OSS ILSs or why they choose one OSS ILS over another. Many libraries are lucky to have one or two people in IT with experience implementing an OSS ILS. One library noted, “I mean it is free software. But you’ve got to take care of it on your own and every-thing. You’ve got to develop. You’ve got to find somebody. If you’re not going to take care of it in your library, you’ve got to find a company you’re comfortable with that will, that you can contract with to provide service for it.” Oth-ers have personal contacts with other librarians they can consult for advice and recommendations.

Sometimes the very process of researching and mi-grating to an OSS ILS encourages groups of libraries to de-

velop consortia because they have common goals, are al-ready communicating, and think a partnership could help share the workload. Usually interest in migration is higher than the original members of a group realize, as reflected in this remark: “We settled on Evergreen. And we invited other public libraries to a meeting to talk about it because of the advantages an open source consortium would have just to see if anyone else would be interested. And to our surprise, actually quite a few other people showed up and said, yes, we’re very interested in the possibility. So that’s what got the ball rolling.” Scalability, which is required for collaboration among a large number of libraries, is one of the main reasons for choosing an OSS ILS (specifically Evergreen), as reported by one library: “From a technolog-ical point of view, given our size and our tendency to kill systems with volume, it looked like Evergreen was written technically to be able to scale growth. That has turned out to be true.”

Some libraries are pressured by their local representa-tives, taxpayers, and community members to migrate to an OSS ILS to save money, as reflected in this comment: “We had been pushed for a long time by the town, the town ad-ministration, and the board of selectmen to find a cheaper option. Innovative was just killing our budget in terms of the annual maintenance. And they had been unhappy with us for a long time.” Of course, this does not mean that all community members are well informed about the decision-making process of OSS versus proprietary ILSs.

Other libraries choose to migrate to OSS ILSs because they feel that its mission of sharing, collaboration, and openness is inherently in line with the mission of librar-ies. Consider the following remark: “That whole being part of a bigger thing, that whole open-source, we’re work-ing together for the good of all. That’s what we do. We’re libraries.”

Online Sources and Communities

Many of the libraries surveyed responded that they con-sult online or technical sources and communities when researching OSS ILSs. Almost 50 percent of the libraries that consulted these resources were school libraries, com-pared to almost 25 percent public libraries and around 15 percent academic or special libraries. The small to mid-sized libraries that were interviewed made frequent use of technical resources (see Figure 3).

Part of migrating to an OSS ILS is independently re-searching and troubleshooting problems. Many libraries search websites in general or specific websites for this in-formation. Years ago, OSS ILSs were so new that only a




few specifi c websites contained information about them. As they have become more developed and popular, how-ever, libraries can fi nd lots of information just searching the web for information, tutorials, documentation, etc. This comment was made on behalf of a library: “As Ever-green is maturing, you’re getting a lot more problems that you can just Google for and fi nd someone else has already had them.”

There are also many online resources and communi-ties available for specifi c OSS ILSs. These include Internet Relay Chat (IRC), listservs, wikis, forums and user groups, and documentation and training materials from the OSS ILS community. Regardless of the avenue of research, most libraries agree that it is important to check archived questions before posting a new one, as indicated in this remark: “I’m not the only person that is having some problems I think that I’ve encountered. And so I see the answers debated. And then I can better ask my question. Part of asking a good question is having the background of what you’re asking.” Overall, the community is consid-ered to be one of the best things about OSS ILSs. It is the fi rst option libraries consider for help (even before a ven-dor) and includes a growing group of knowledgeable and

enthusiastic people. One respondent noted, “The docu-mentation that’s out there, we found it was really, really good. So we actually just printed it off , and it’s sitting in a big notebook by the desk in case anybody has to refer to it or has any questions.” Most libraries believe that contrib-uting back to the OSS community is a major responsibility, as refl ected in the following statement: “The enthusiasm of the community, like you’re saying, is a big part of it.”

OSS ILS vendors may provide informative websites and groups available for implementation and ongoing support for those libraries that pay for their services. We-binars and other more academic sources are also becom-ing increasingly popular. While most of these webinars come from OSS ILS vendors or offi cial OSS ILS community groups, increasingly library consortia are creating and re-leasing webinars for research and training.

Discussion and ConclusionInterviews with twenty librarians from diff erent types of libraries provided insight into the process of evaluating and choosing OSS ILSs and were used to develop the gen-

Figure 3: Libraries’ Use of Technical Resources about OSS ILSs by Library Type and Size.




eralized results for this paper. The interviews support the results of the literature review. Libraries most frequently choose OSS ILSs because they are cost-effective; easy to use; supported with a robust community and vendors; well-designed and fully functional; flexible, customiz-able, open, and compatible with other software; and a reflection of an “ethic of sharing” at the heart of libraries.

The interviews also shed light on the many concerns and challenges that libraries have about OSS ILS devel-opment even after migration. The staff time and expertise required to implement and maintain OSS ILSs is still a major concern. Since libraries do not always have reli-able or timely support from OSS communities or vendors, those that lack technical expertise may need to overcome a learning curve in order to do some of their own trouble-shooting. OSS ILSs are still relatively new, and libraries continue to face challenges with their development and functionalities.

To make these detailed evaluations about OSS ILSs, libraries consult vendors, developers, scholarly journals and conferences, and personal contacts. They usually form internal research teams consisting of a group of staff members or administrators in consortia to research and discuss their options. Most libraries prefer online resourc-es, particularly related to a specific OSS ILS community: Internet Relay Chat (IRC), discussion lists, wikis, forums, and documentation. The most common theme of the in-terviews is the importance of community. Libraries like the fact that they can share resources with other librar-ies regarding successes and failures related to OSS ILSs. Although libraries can also share about their experiences with proprietary ILSs, it is more difficult to translate this communication into actual change. While communities and user groups are often online, OSS ILSs also encourage librarians to form regional consortia for migration, imple-mentation, and development.

This paper analyzes why a broad group of libraries chose OSS ILSs rather than presenting a general theory or a single case study. This study is limited in that it can-not generalize the experiences of all libraries and presents results and conclusions from individual institutions. In future research, the author will continue to monitor the adoption of OSS ILSs longitudinally and fill an important gap by sharing this information and resources with the library community through scholarly publications. An information portal that contains resources that will help librarians evaluate and choose their OSS ILSs was devel-oped as part of the research required for this paper. The URL for the portal is http://opensourceils.com.

ReferencesBailey, A., and G. Back. 2009. “Rating ILS Interoperability: A Pro-

posal.” Information Standards Quarterly 21 (4): 17–19.Berenstein, M., and D. Katz. 2012. “Content Integration.” Computers

in Libraries 32 (2): 18–21.Breeding, M. 2009a. “Introduction.” Library Technology Reports 45

(8): 5–14.Breeding, M. 2009b. “Opening Up Library Systems.” American

Libraries 40 (12): 33.Breeding, M. 2011. “The New Frontier.” Library Journal 136 (6): 24–34.Carlock, R. 2008. “Open Source Integrated Library Systems.” Ne-

braska Library Association Quarterly 39 (4): 5–11.Chen, H., and B. Albee. 2012. “An Open Source Library System and

Public Library Users: Finding and Using Library Collections.” Library and Information Science Research 34 (3): 220–227.

Dennison, L. H., and A. F. Lewis. 2011. “Small and Open Source: Decisions and Implementation of an Open Source Integrated Library System in a Small Private College.” Georgia Library Quarterly 48 (2): 6–8.

Dykhuis, R. 2009. “Michigan Evergreen: Implementing a Shared Open Source Integrated Library System.” Collaborative Librari-anship 1 (2): 60–65.

Egunjobi, R. A., and R. A. Awoyemi. 2012. “Library Automation with Koha.” Library Hi Tech News 29 (3): 12–15.

“Enhanced Koha Bibliographic Content.” 2009. College and Re-search Libraries News 70 (7): 368–388.

“Equinox, NELINET Partner.” 2009. Advanced Technology Libraries 38 (2): 2–3.

“Equinox to Support Koha Open Source ILS.” 2010. Library Journal 135 (5): 17.

Florin, J. 2011. “Koha: Choosing and Implementing an Open Source Integrated Library Management System.” ALISS Quarterly 6 (2): 13–15.

Genoese, L., and L. Keith. 2011. “Jumping Ship: One Health Science Library’s Voyage from a Proprietary ILS to Open Source.” Jour-nal of Electronic Resources in Medical Libraries 8 (2): 126–133.

Hamby, R. 2012. “10% Wrong for 90% Done.” Computers in Libraries 32 (4): 17–21.

Hughes, M. 2011. “Evergreen Conference Shows Open Source is Flourishing.” CILIP Update with Gazette 18–19.

Jaffe, L. D., and G. Careaga. 2007. “Standing Up for Open Source.” Library Philosophy and Practice 9 (3): 1–17.

Jizba, L. 2003. “An Essay on Our Interviews, and a Call for Participa-tion.” Journal of Internet Cataloging 6 (2): 17–20.

Kohn, K., and E. McCloy. 2010. “Phased Migration to Koha: Our Library’s Experience.” Journal of Web Librarianship 4 (4): 427–434.

Liu, G., and H. Zheng. 2011. “Access to Serials: Integrating SFX with Evergreen Open Source ILS.” Library Hi Tech 29 (1): 137–148.

Longwell, B. 2010. “Coming Soon to a Library Near You: An Open Source ILS.” OLA Quarterly 16 (3): 16–17.

McDermott, I. E. 2012. “A Small Public Library Goes Open Source.” Searcher 20 (1): 8–44.

Moghaddan, G. G., and M. Moballeghi. 2008. “How Do We Measure the Use of Scientific Journals? A Note on Research Methodolo-gies.” Scientometrics 76 (1): 125–133.

Muller, T. 2011. “How to Choose a Free and Open Source Integrated Library System.” OCLC Systems and Services 27 (1): 57–78.




“Nelsonville Public Chooses ByWater Solutions.” 2010. Advanced Technology Libraries 39 (3): 2.

“OLE Project Gains Support of Kuali Foundation.” 2009. Library Journal 134 (20): 21–22.

“Open Source ILS Plan for Pennsylvania PLs.” 2010. Library Journal 135 (16): 16.

“Outsell Study Finds Koha is Open-Source ILS of Choice.” 2009. Advanced Technology Libraries 38 (5): 9.

Pace, A. K. 2006. “Giving Homegrown Software Its Due.” American Libraries 37 (10): 50–51.

Phillips, L. 2009. “Information Sharing Innovations: Open Source CMS and ILS.” PNLA Quarterly 74 (1): 4–5.

“PTFS Acquires LibLime.” 2010. Advanced Technology Libraries 39 (4): 1–11.

Puckett, J. 2008. “Open-Source Software in Museums.” Library Student Journal 3 (1): 11.

Rapp, D. 2011. “Open Source Reality Check.” Library Journal 136 (13): 34–36.

Shafi-Ullah, F., and S. Qutab. 2012. “From LAMP to Koha: Case Study of the Pakistan Legislative Assembly Libraries.” Program 46 (1): 43–55.

“SirsiDynix Document on Open Source Draws Fire.” 2009. Library Journal 134 (20): 21.

Tajoli, Z., A. Carassiti, A. Marchitelli, and F. Valenti. 2011. “OSS Diffusion in Italian Libraries: The Case of Koha by the Consorzio Interuniversitario Lombardo per l’Elaborazione Automatica (CILEA).” OCLC Systems and Services 27 (1): 45–50.

Terlaga, A. 2010. “Fear and Trembling in Connecticut (or ‘How I Learned to Stop Worrying and Love Open Source’).” Computers in Libraries 30 (1): 13–30.

Trainor, C. 2009. “Open Source, Open Crowd: Harnessing the Power of the People behind Our Libraries.” Program: Electronic Li-brary and Information Systems 43 (3): 288–298.

Wale, C.P. 2011. “Cloudy with a Chance of Open Source: Open Source Integrated Library Systems and Cloud Computing in Academic Law Libraries.” Legal Reference Services Quarterly 30 (4): 310–331.

Walls, I. 2011. “The NYU Health Sciences Libraries’ Experiences.” OCLC Systems and Services 27 (1): 51–56.

Westbrook, J. 2011. “Opening Up to Open Source.” Alki 27 (1): 17–18.

Yang, S. Q., and M. A. Hofmann. 2010. “The Next Generation Library Catalog: A Comparative Study of the OPACs of Koha, Evergreen, and Voyager.” Information Technology and Libraries 29 (3): 141–150.

Zou, Q., and G. Liu. 2009. “Chinese Localization of Evergreen: An Open Source Integrated Library System.” Program: Electronic Library and Information Systems 43 (1): 49–61.

Editorial historyreceived 11 February 2013accepted 27 March 2013




Appendix – Interview Questions

Library Environment

1. What is your library type (school, academic, public, special, etc.)?

2. What is your library size (how many employees, pop-ulation served, and number of materials)?

Evaluation

(We would like as much info as possible about why the system was chosen over others, including any existing system).3. What open source ILS are you using and why did you

choose it?4. When choosing an open source ILS, where did you

go for information (vendor/ILS pages, community groups, personal contacts, etc)?

5. Who was involved in deciding which ILS to use?

Adoption

(We would like to document specific problems or issues that could be used by other libraries to ease their instal-lation).6. Were there any problems during migration?7. What do you know now that you wish you had known

before migration?8. How long did migration take? Were you on schedule?9. If getting paid support, how did the vendors (previous

and current) help with migration?

Implementation

(Again, specific examples of the things that worked well or didn’t work. How can other libraries learn from this ex-perience)?

10. What kind of (and how much) training did your li-brary staff receive?

11. Did you do any kind of marketing to your patrons?12. (If haven’t gotten to this part yet), what are your plans

for implementation?13. How much time did implementation take and were

you on schedule?

Maintenance

(This information will be especially important when com-pared to the library type and size as a reference for other libraries. We would like to get answers that are as specific as possible).14. How large is your systems staff? Is it sufficient to

maintain the system?15. How much time do you spend each week doing sys-

tem maintenance? How does this compare to your old system?

16. What resources (or channels) do you use to solve your technical support issues? What roles do paid vendors play in maintenance of your system?

Advice for other libraries

(These open-ended questions are an opportunity to learn more information that we might not have thought of ask-ing about. Responses could provide a valuable resource to other libraries as they plan their implementation).17. What is the best thing and worst thing about having

an open source ILS?18. Are there any lessons or advice that you would like to

share with other librarians who are thinking about or migrating to an open source ILS?



Documents

Why Migrate to an Open Source ILS? Librarians with Adoption Experience Share their Reasons and Experiences