When Integrated Library Systems (ILSs) originated, they were developed on site for individual libraries (Pace, 2004) that the ILS developed by Northwestern University (Weber, 2006). Soon, corporations saw that they could leverage the market and provide the systems that libraries needed taking on the burden of software development. Self-developed ILS technology was beyond the reach of many libraries, and commercial products gained a reputation for being easier (Weber).
Today, there are many commercial ILSs from which to choose, but these systems do take some control out of librarians’ hands. In an effort to regain control over the software, open source ILSs have been developed (Casey & Savastinuk, 2008). Open source upgrades are available freely and not tied to annual fees and upgrade costs (Wrosch, 2007). These products are attractive (Weber, 2006) and frequently developed with a Web 2.0 interface making them easier to use on the front and back ends (Goodman, 2010). The web-based computing aspects of open source ILSs are equally practical to those of proprietary systems (Breeding, 2009). Open source software can be downloaded and tried in their entirety rather than depending on short vendor provided demos with which the library staff may be left wondering if the product will provide all that it advertised (Wrosch). Developers have also integrated more practical components with the growing number of libraries utilizing a system (Breeding). One of the attributes of open-source is the encouragement of extended software development through licensing that is usually GNU General Public Licensing (Wrosch).
Several excellent open source ILSs are available that are easy to implement and use. In addition, programming like Evergreen and Koha have been around for years and installed by hundreds of libraries. Their extensive use minimalizes the risks associated with open-source systems in the past (Breeding, 2009).
Evergreen History
Georgia’s library consortium, Public Information Network for Electronic Services (PINES), is made up of primarily small to medium libraries sharing resources (Molyneux, 2009). This manifestation of Georgia’s consortium came about in the late 1990s to address software problems foreseen with Y2K. By the mid-2000s, the ILS they had chosen had problems keeping up with the day-in and day-out functions of multiple libraries (Weber, 2006). After examining a variety of commercial replacement systems, they proposed that the Georgia Public Library System (GPLS) develop their own ILS using in-house staff and open source technologies (Weber, 2006). Forums and focus groups were held to get librarian (PINES and non-PINES members) input into the project (Hyman & Walker, 2008). Participants were asked to dream about ideal ILSs without limitations.
Work began in 2004 and took into account the user requests from the forums and focus groups (Hyman & Walker, 2008). Evergreen’s design was based on the open source web browser Firefox and included tabs, spell checking and suggested alternatives (Weber, 2006). Evergreen allowed for local control and large scale sharing of items and information (Molyneux, 2009). In addition, it was modular and easy to update. Its modular nature meant that components could be built for or added on without touching or completely rewriting the base programming.
With an IT staff in place (Weber, 2006) and the expert opinions of librarians and committees (Hyman & Walker, 2008), the team sought to develop a program utilizing Functional Requirements for Bibliographic Records (FBRB) with enriched content such as book covers, table of contents and book reviews (Weber). Some member librarians expressed skepticism early in the process until they saw how quickly problems were fixed. This was an accommodation that had been missing with commercial products and continues to be an advantage of open source (Weber). Developers continue to work with user librarians to make the system better and fix problems as they arise.
Evergreen went live over Labor Day weekend in 2006 (Molyneux, 2009). The original release included the same functions as the previous system: circulation, cataloging and Online Access Catalog (OPAC) (Weber, 2006). While the Evergreen system has grown in public library settings, it has not gained popularity in school media centers or research libraries (Breeding, 2009). It has also been embraced by small to medium libraries rather than very large ones. Evergreen was designed for a consortium, but works well for a single library also (Evergreen, 2008).
As late as 2009, Evergreen did not have components for “acquisitions, serials control, multilingual support and course reserves” (Breeding, 2009, p. 23). Most of these have since been addressed and the latest edition showing its ability to address ongoing needs. Today, Evergreen is used in British Columbia, Michigan, Georgia, Indiana, South Carolina and numerous independent libraries (Evergreen, 2008).
Evergreen has been implemented by only two schools (J. Hill, personal communication, November 30, 2010). Both schools are part of established consortiums. However, schools have shown an interest and at least six organizations have joined forces to develop an Evergreen OPAC for children. When asked about K-12 potential, B. Molyneux stated, “I can see it as a means of stretching a professional collection for the teachers” (personal communication, November 29, 2010).
Installing Evergreen
Two components are loaded onto a server or local computers or work stations and are found on the Evergreen download site. The Evergreen Staff Client is installed onto the individual stations. This is a small execution file which allows access to the Evergreen catalog and (OPAC). Indiana State Library has a demonstration version available with instructions on how to log into their demo sites (Indiana, n.d.). This demo allows librarians to install the software and work directly with the databases. Most of the information provided below was acquired from hands-on work with this demo.
Costs and Support
One of the problems with open source products is that the costs involved are not obvious or clear at the onset. While Breeding makes a case that open source has become so easy to implement that any library can do it (Breeding, 2009), someone must have technical expertise to install and maintain the programming. If this person is not on staff, then the library might need to hire a small technical staff or contract with a company (Casey & Savastinuk, 2008). A bonus of hiring IT staff is that they may be able to work collaborative with library staff on Web 2.0 innovations that library staff does not have time to address and of which technical staff may lack library expertise (Casey & Savastinuk). While mentioning a few examples of libraries that implemented open source ILS systems completely on their own, Breeding also states that most choose to use commercial support. These support companies can also host, upkeep and run the software and hardware. Fees are less for open-source products (Worsch).
Computers are needed that run at least Windows XP (Indiana, n.d.). Servers or hosting sites are also needed. While the downloads are easy to find on the Evergreen Download page, server information is not. Libraries may need to get professional help such as that provided by Equinox in determining server needs so they do not end up with inadequate or misconfigured servers (B. Molyneux, personal communication, November 29, 2010). Even then, finding the correct server is not a precise science. Considerations include: expected growth, total circulations, number of bibliographic entries, number of branches and the number of registered borrowers. Libraries should think larger rather than smaller because “people really like consortial borrowing when implemented,” so volume should naturally increase (B. Molyneux, personal communication, November 29, 2010).
There is also the possibility of additional costs due to a sponsored development (Breeding, 2009). If a library decides it wants a specific but unavailable feature for Evergreen, that library can contract with developers to write the component. The advantage to the Evergreen community is that information is freely shared in the next upgrade benefiting all users. The Evergreen community has developed a system of networks for deep support (Wrosch, 2007). This community support is actually stronger than traditional vendor support because the user has direct access to developers. A support system is clearly seen on the Evergreen site which has a listServ, blog, wiki and forum (Evergreen, 2010). Still some technical knowledge is needed to understand the technically-based lingo on the on these pages. Evergreen Indiana has a weekly cataloging tip page with suggestions dating back to August of 2009 (Indiana, n.d.). A variety of commercial companies offer Evergreen support. Equinox is one of several companies that support Evergreen and other open-source ILSs. Equinox employed the team that developed Evergreen (Breeding, 2009).
There can be considerable cost savings for individual libraries in a consortium system. Indiana examined the expenses of PINES and developed a cost chart indicating free items, those paid for by individual libraries and ones covered by Evergreen Indiana (Indiana, n.d.). In Indiana, member libraries provide work stations, bar codes and scanners among other items. Indiana State Library pays for internet access, servers and technical support. They contracted with Equinox and also have their own help desk (Indiana), IT staff and IT committee (Hill, personal correspondence, November 30, 2010).
Cataloging in Evergreen
Training has been an integral feature of Evergreen. There are two levels of training: Certified Original Cataloger (Cat 1) and Certified Copy Cataloger (Cat2) (Hill, 2009; Upham, 2008). Copy catalogers perform basic cataloging tasks. Original catalogers can overlay records, create original records, merge and delete records. Georgia and Indiana mandate training and will revoke cataloging privileges for any library that consistently performs substandard work.
Cataloging begins with logging in to the Staff Client where a user name, password, server identification and work station are entered (Llewellyn, 2010). A portal opens up from which all the cataloging functions are performed. The staff client can be downloaded onto any individual computer and linked to the server.
Main pull down menus on this page include File, Edit, Search, Circulation, Cataloging and Acquisitions. Because this program is based off the Firefox model, multiple tabs or windows can be open at a time and do not interfere with efficiency. All the menu items are used to some extent in cataloging. The File menu has choices for opening and closing windows and tabs as well as exiting the program. A complete exit, however, must be done from the Staff Client which cuts the link to the server. The Edit menu has functions addressing copy and record buckets. Buckets are used in Evergreen like batch files (Llewellyn, 2010) and allow for changes to be made in multiple records at one time (Indiana, n.d.). The Search, Catalog and Acquisition menus do exactly what they say. There are multiple ways to get to almost any page.
To catalog an item, the cataloger begins by searching the catalog to see if the item has already cataloged in one of the contributing libraries. Recommendations are to search the Native Catalog first (Llewellyn, 2010; Hill; 2009). Warnings are issued in the PINES manual about taking care not to duplicate records already in the system, although duplicate records can be merged when discovered (Upham, 2008). Multiple search filters are available and include the ISBN number, MARC tags, subfields and values. Searches can also be performed for keywords, titles, authors or series. Searches can be sorted by relevance, author, title or publication date and then grouped in ascending or descending order. In addition, searches can be made within the host branch collection, another branch or the entire consortium. There are also eight built-in search filters to help narrow a search. These filters are based on item form, item type, literary form, language, audience, bib level, publication year and shelving location. The return search shows how many of the items are in the host branch or the consortium. A list of relevant authors is also returned. The user can change the font size from regular to large and a print button appears on most pages. Go Back and Go Forward buttons also are available within the program and keep the user’s settings.
Clicking on the title takes the user to the Record Summary page for the item. This page can be copied or stored in a bucket. Another interesting feature on this page is the ability to see all records from all libraries. Various columns are available like Call Number and Copy Location. This makes it easy to compare and contrast the way that member libraries have cataloged the same item. Bar codes can be retrieved for all items on this page and used for more cataloging actions.
Multiple views are available. The MARC record can be seen in either a popup or the same window. MARC can also be viewed below the OPAC view. The record can be edited, copied or deleted/undeleted from the Record Summary page. It can also be marked for overlay or added to a record bucket. “Overlay means what it says. If you have a bad record which needs a load of editing, it would be quicker and easier to find a good record, bring it into the system while replacing the bad record (Hill, personal correspondence, November 30, 2010). A record bucket stores MARC items as they are being processed. Spine labels and barcodes can be printed from this page.
Evergreen currently imports records via z39.50. Services available for import are the Evergreen Native Catalog, OCLC, Library of Congress and biblios.net. A new feature will be found in the next release, however, that allows for direct import on a record-by-record basis from OCLC Connexion (Molyneux, personal correspondence, December 1, 2010). The top search pane can be hidden once the results arrive giving the cataloger more room to work.
Several options exist for each record. There are a variety of ways to copy or save in comma separated values (CSV). There is a MARC editor for importing, and MARC records can also originate from a MARC template. This shows the MARC record including the 008 fixed fields (many of which are prefilled). There is a list of prefilled standard tag numbers including 010, 020, 082, 092, 100, 245, 260, 300, 500 and 650. A help button opens a screen that explains how to add or delete fields. Each library system decides which tags they want to consistently use. Some systems’ cataloging procedures required very specific fields and detailed instructions (Hill, 2009; Upham, 2008). Others had less stringent requirements (Llewellyn, 2010). Regardless of the procedures in place, a template can be set up for MARC records to help expedite cataloging. A validation button appears at the top of the record, and when clicked, it highlights certain fields to help with the cross referencing of records (Evergreen, 2008). The MARC record allows Dewey Decimal or Library of Congress classification, and OCLC numbers are used for TCN numbers (Upham, 2008). “Bulk uploads such as batch files of MARC records happen via the Batch Import/Export function in Evergreen’s cataloging module” (Molyneux, personal correspondence, December 1, 2010). There do not appear to be any tags particular for schools except those that can be added to a MARC template.
One interesting feature of Evergreen is the ability to create a temporary or brief record for an item not normally checked out (Upham, 2008). These can also be used for interlibrary loan items. They are automatically deleted upon check-in.
Each library or system can decide on how often and when to upload records. Georgia uploads records quarterly, but the time table can be established by the library or consortium (Indiana, n.d.). Cataloging in Process (CIP) records may be uploaded from the Library of Congress. They are identified by an 8 in the Fixed Field Encoding Level (ELvl) and a field 263 (Hill, 2009; Upham, 2008). Indiana and Georgia procedures require that the first cataloger to upload a CIP record fill it out for the system before importing occurs. They also ask that the 263 field be removed in addition to checking 245 for the correct title.
The Item Status screen is found in the Circulation and Cataloging menus. A bar code number is used to retrieve an item on this page, but once the item is retrieved, there are several cataloging options available. All CSV functions are presented on this screen, and the item can be copied or edited, transferred or deleted, and marked as damaged or missing. Barcodes can be replaced and spine labels printed.
Information on authority control was difficult to find, but some requests for authority record consistency were made as early as 2006 (Evergreen, 2008). Plans are in place to strengthen the authority records by creating fixed fields and improve the authority interface. In addition, there are plans for automatic updates of authority control. Authority record management and integration are planned in the January 2011 update (Evergreen). PINES has a Cataloging Coordinator responsible for maintaining authority records (Upham, 2008). This is done through MARCive, a library database service. Updated records are received monthly and PINES files are updated from those. Indiana relies on the Library of Congress Authority Records (Hill, 2009).
Conclusion
Evergreen provides a viable open source alternative to purchasing a propriety ILS. Small to medium sized public or academic libraries will find the system adequate and in some cases superior to some commercial systems (Web 2.0 interfaces). Consortiums will find the system especially beneficial since it was specifically designed to meet their needs. Allowances are made for member libraries to be as interrelated or as unrelated as they see fit. Libraries will most likely need some IT support which can be staffed in-house or out-sourced to a company like Equinox. This seems to be Evergreen’s greatest drawback. Staffs without support or technical backgrounds will have a difficult time understanding the technological language in addition to analyzing and configuring the needed equipment. However, staffs with adequate technical support and a desire to control ILS components should find Evergreen a worthwhile investment of time and effort.
References:
Breeding, M. (2009). The viability of open source ILS. Bulletin of the American Society for Information Science and Technology, 36(2), 20-25.
Casey, M. E. & Savastinuk, L. C. (2008). Library 2.0: Service for the next-generation library. Library Journal. Retrieved from http://libraryjournal.com
Evergreen open source library system. (2008). Retrieved from http://evergreen-ils.org
Hill, J. S. (2009) Cataloging procedures guide. Evergreen Indiana. Retrieved from http://www.in.gov/library/evergreen.htm
Evergreen cataloging working group (CatWoG). (2009, January 21). Meeting of the Evergreen cataloging working group.
Hyman, B. & Walker, J. (2008). Case study: The Evergreen Open Source Integrated Library System; its origins and significant implementations in the USA and Canada. Paper presented at the World Library and Information Congress: 74th IFLA General Conference and Council. Quebe, CA. Retrieved from http://archive.ifla.org/
Indiana state library: Evergreen Indiana. (n.d.) Retrieved from http://www.in.gov/library/evergreen.htm
Llewellyn, M. (2010). Evergreen cataloging module guide. Bibliomation, Inc. Retrieved from http://biblio.org/
Molyneux, R. E. (2009). Evergreen in context. Bulletin of the American Society for Information Science and Technology, 36(2), 26-30.
Pace, A. K. (2004). Dismantling integrated library systems. Library Journal, 129(2), 34-36.
Weber, J. (2006). Evergreen: Your homegrown ILS. Library Journal. 131 (20), 38.
Wrosch, J. (2007). Open source software options for any library. MLA Forum, V(3). Retrieved from http://www.mlaforum.org/volumeV/issue3/article3.html
Upham, L. N. (2008). PINES cataloging manual: Policies and procedures. PINES. Retrieved from http://pines.georgialibraries.org
Like this:
Like Loading...
Jack Of All Trades 