Evergreen ILS Update, September 2011 ==================================== :author: Dan Scott :copyright: 2011 Laurentian University :backend: slidy :max-width: 45em :icons: :duration: 30 This talk is licensed under a http://creativecommons.org/licenses/by-sa/2.5/ca/[Creative Commons, Attribution, Share Alike license]. image::images/cc_by_sa_360.png[] Presentation source: http://bzr.coffeecode.net/2011/eIFL_evergreen_update Barriers to Evergreen adoption ------------------------------ * Hardware: ** two servers recommended ** offline mode for staff, but not for catalogue * Software skills: ** Linux system administration ** PostgreSQL ** Apache ** ejabberd * Installation & configuration is not "turn key" * Community currently concentrated in North America * IRC support may be limited in your timezone * Internationalization is hit or miss * Javascript-heavy catalogue* ifndef::backend-slidy[] For anything beyond a small installation (10,000 records), you will want two servers: one dedicated to the PostgreSQL database, and the other for the rest of the Evergreen stack. Evergreen is a client-server application architecture, and the catalogue absolutely depends on a live connection to the server. The staff client can operate when the network connection to the server is down, with limited functionality: circulating items and registering patrons. To be fair, there are not many (any?) library systems that offer catalogues that operate when the connection to the server is offline. Perhaps a development opportunity to make something like Blacklight or VuFind operate as standalone catalogue stations... Most library systems require Linux (or in some cases Windows) and Apache system administration skills.  PostgreSQL is encountered less frequently but is in my opinion the superior relational database option -- and it comes with excellent documentation, an active community, and plenty of materials online to support learning. ejabberd is the black sheep of the Evergreen stack; it is a critical component that, when it is set up and running, operates flawlessly. However, documentation is scanty and it seems to behave somewhat erratically when, say, the hostname of the system changes. Evergreen installation has seen some progress over the past year. Ben Webb, a Google Summer of Code student, worked on creating packages for the Debian and Fedora Linux distributions over the summer. Until Evergreen's updates some of the components on which it relies, however, these packages won't be able to be officially accepted by the distributions. Configuration of Evergreen can be challenging. We try to ensure that the out-of-the-box defaults are sane, but the phrase "YAOUS" (Yet Another Org Unit Setting) gives an idea of how many different configuration variables can come into play for any customization of your system. In addition, tuning the major components of Evergreen such as PostgreSQL requires a great deal of skill. With the IRC channel #evergreen mostly limited to America/Eastern time zone hours, we occasionally see questions from people in time zones in EMEA in the IRC logs when most of us are asleep. Hopefully, with more adoption of Evergreen, this problem will take care of itself. Similarly, the focus on internationalization in Evergreen is on a "best effort" basis. The process for synchronizing translations between the source code and Launchpad is manual, labour-intensive, and consequently does not happen nearly as often as it should. Internationalization really needs a champion to work towards automating the process and ensuring that quality continues to improve. The current catalogue is built heavily on JavaScript, which means many network requests to build a single page and a lot of data to transfer. Recognizing that this experience is not optimal for mobile browsers, low-bandwidth connections, or cross-browser compatibility, the developer community has invested a significant amount of effort in building a replacement catalogue - TPAC - to address these concerns. This catalogue will be available in the 2.2 release of Evergreen. endif::backend-slidy[] Evergreen growth: community --------------------------- * Volunteer "do-ocracy" http://evergreen-ils.org/dokuwiki/doku.php?id=faqs:evergreen_committees[teams]  including: ** Documentation ** Reports ** Web site ** Developers ** Bug wranglers ** Release * http://evergreen-ils.org/listserv.php[Mailing lists] (General and Developers) * Internet Relay Channel (http://evergreen-ils.org/irc.php[IRC]) channel ifndef::backend-slidy[] * IRC averages: ** 2009 total = 13459 ** 2009 monthly average = 1121 ** 2010 total = 52298 ** 2010 monthly average = 4358 ** 2011 total = 61577 ** 2011 monthly average = 5131 * General list messages **2009 total: 1261 **2009 monthly average: 105 **2010 total: 1620 **2010 monthly average: 135 **2011 total: 1560 **2011 monthly average: 173 * Dev list messages **2009 total: 1610 **2009 monthly average: 134 **2010 total: 1045 **2010 monthly average: 87 **2011 total: 882 **2011 monthly average: 98 endif::backend-slidy[] Evergreen mailing list ---------------------- image::images/mail_stats.png[] Evergreen IRC messages ---------------------- image::images/irc_stats.png[] Evergreen growth: quality ------------------------- * Increased use of http://bugs.launchpad.net/evergreen[community bug database] ** For merge requests as well as bugs ** Any non-trivial code changes are supposed to go through a merge request / review process * Weekly developer meetings via IRC ** One meeting to discuss issues and processes ** One meeting to review merge requests  * http://testing.evergreen-ils.org[Automated testing] for build / compile / unit testing errors after every commit ** More unit tests needed! Evergreen growth: governance ---------------------------- * Joined the http://sfconservancy.org[Software Freedom Conservancy] (SFC)  American non-profit organization ** SFC, as a legal entity, can hold project assets such as trademarks, copyright, domain names, and funds ** Transparent, neutral third party * http://evergreen-ils.org/dokuwiki/doku.php?id=governance:structure[Evergreen Oversight Board] represents the project ** Board membership was "bootstrapped" in 2011 but will hold elections in 2012 Evergreen features: 2.1 release ------------------------------- * 2.1.0 release should be available any day now * Improved since 2.0: ** Serials with predictions and check-in ** Acquisitions with EDI support * New since 2.0: ** Bibliographic parts ** Conjoined items ** Authority control sets ** SRU/Z39.50 server access to authority records ** Hold-driven recalls ** Automated staff client updates ** ... and much more * Serials and acquisitions were introduced in 2.0; as sites went through the process of using these features, they found a number of issues that have been resolved in 2.1 ifndef::backend-slidy[] Bibliographic parts: distinguish between separate parts of the same item for holds - such as a book and a CD in a book + CD set, or an individual volume of an encyclopedia Conjoined items: a single barcode can represent multiple bibliographic records - for example, an ebook reader could have 1,000 ebooks loaded onto it with one barcode - so if the ebook reader is checked out, all 1,000 records in the library system will show that the copy is checked out Authority control sets: mappings between authority records and bibliographic records used to be strictly MARC21-based; they are now customizable for local practices Hold-driven recalls: you can allow items to have a long loan period, such as one-year - but if someone places a hold on an item, it will automatically change the duration of the loan and send an email notification to the holder of the item to alert them to the truncated length of the loan endif::backend-slidy[] Evergreen features: 2.2 release ------------------------------- * 2.2 beta targeted for late November 2011 * TPAC: low-bandwidth, full-featured catalogue ** Easy customization ** On-the-fly lists * http://openlibrary.org[OpenLibrary] integration for cover art, added content, e-books (includes lending) * Revamped configuration interface, courtesy of Google Summer of Code student Joseph Lewis: ** Categorized configuration settings ** Settings history; import; export ** Searchable interface * Staff client: saved searches Evergreen 2.2: TPAC ------------------- image::images/tpac_results.png[] ifndef::backend-slidy[] * Resources required to display search results with one result: ** JSPAC: 147 HTTP requests, 317 KB ** TPAC: 11 HTTP requests, 31 KB * Resources required to display record details: ** JSPAC: 157 HTTP requests, 344 KB ** TPAC: 21 HTTP requests, 49 KB endif::backend-slidy[] Evergreen 2.2: OpenLibrary borrowing ------------------------------------ image::images/openlibrary_results.png[] Evergreen 2.2: OpenLibrary -------------------------- image::images/openlibrary.png[] Evergreen adoption recommendations ---------------------------------- * Have a test server - and use it ** Learn how to administer the Evergreen stack - safely ** Test your migration strategy ** Test and document new features on new releases before learning "the hard way" ** Train staff on new features on new releases * Speak up! ** Share your troubles and triumphs on the mailing lists, IRC, and bug reporting database * Stay current! ** Point releases contain bug fixes that can save time ** Major releases can change how internal processes work significantly, making it hard for the community to help users on previous releases Evergreen: join us ------------------ * Contribute to the documentation, test releases, contribute fixes, help others! Evergreen wants you: http://evergreen-ils.org