Coffee|Code : Dan Scott

After much iteration and minor bug-squashing in my configuration, I am pleased to announce the Evergreen on Gentoo VMWare image is available for download. The download itself is approximately 500MB as a zipped image; when you unzip the image, it will require approximately 6GB of disk space. (1)

Basic instructions for starting up Evergreen will be found in the Evergreen_Gentoo/README file inside the unzipped image. To use this image, you must have installed a VMWare product (2) on a machine somewhere. I've allocated 512 MB of RAM to the VMWare image, so the machine you run it on should have a total of at least 768 MB of RAM -- or you can try decreasing the amount of RAM dedicated to the VMWare image.

The image is based on the 1.1.x development branch of Evergreen from CVS as of April 23, 2007. There are a couple of bugs I have observed with the image so far:

• Checking out an item doesn't work. Fixed as of this morning - Bill Erickson noted on the open-ils-dev mailing list that the default circ rule wasn't being created by the install scripts and checked a fix into CVS. I spun a new image.
• The first time you start up the Evergreen processes with osrf_ctl, the OpenSRF-C process often dies with a segmentation fault. Restarting the processes then results in a stable running system. It's a race condition that we'll have to hunt down and eliminate.

Notes

1. I apologize for overestimating how much space the VMWare image would require way back at the beginning of this exercise. Apparently while VMWare Server offers an "expand disk" option, it does not offer a "shrink disk" option. One tip that helped me shrink the image from 1GB to half that size was to run "cat /dev/zero > zero.txt ; sync ; rm zero.txt" to zero out all of the bytes on the empty portion of the virtual disk before compressing the image.
2. VMWare Server and VMWare Player are both zero-dollar downloads from http://vmware.com/ - I use VMWare Server and don't know if VMWare Player offers any advantages over that.

Due to a sad event, Art Rhyno asked me to be his co-presenter at the OLITA Digital Odyssey 2007. Our broad subject was Evergreen, more specifically introducing the Evergreen ILS to an audience that was aware of Evergreen's existence but wanted to know more about it from both a technical and a business perspective. I had two days' notice to prepare for the presentation, so I split my time between polishing the VMWare image of Evergreen and creating the slides for my presentation (PDF).

Art gave a general introduction to open source development, told the story of how Evergreen came about, and described its architecture and the capabilities currently demonstrated on the in-production system at PINES. Perhaps of most interest to the audience, Art talked a bit about the direction that he's taking Woodchip, the serials and acquisitions module based on Apache OFBiz that the University of Windsor has agreed to develop for Evergreen. No pressure, Art

Then the presentation was handed off to me. I started by asking for demographic information from the audience; to no surprise, about half of the audience of approximately 60 ran Horizon systems. Many of the attendees in the audience paid more than $20,000 annually for support and licensing costs. Most of the sites had the equivalent of one full-time position devoted to the care and feeding of their current library system.

The goals of my presentation were to:

1. Demonstrate that the library community has a strong culture of self-support with respect to library systems (based on the volume of email on our closed library systems mailing lists)
2. Suggest that the quality of official support we receive from our closed library systems does not warrant the annual support fees we pay
3. Point out that we already devote personnel to the care and feeding of our closed library systems, so the refrain of "open source is like getting a free kitten" is fine given that we're currently paying for a dog of a closed system
4. Urge the audience to consider what a waste of money and time it is to train staff to learn the proprietary API, templating language, etc for a closed system when that knowledge can become useless if the system is pulled from the market -- while investing money and time in learning the API and templating language for Evergreen results in reusable skills for your personnel because those are based on open standards.
5. Let the community know the preliminary results of my evaluation of the internationalization support offered by Evergreen
6. List some of the challenges that we face in achieving a wide adoption of Evergreen
7. Notify the community that my VMWare image is really, truly, close to being released and suggest that it would be a great way to get started with Evergreen
8. Run a quick live demo with the VMWare image to prove that a full install of Evergreen can scale down to running in a virtual machine with 512M of RAM

My self-assessment? I did not want to come across as an open source zealot; rather, I wanted to point out where our current relationships with our vendors are failing us and how open source can fill in some of those gaps. Unfortunately, I feel that I probably veered a little too much towards the rant side of the continuum a couple of times -- my passion for this subject came through, no doubt, but it was perhaps a little too strong.

I knew my presentation was text-heavy, but I didn't beat myself up too much because a good visual presentation needs more than just a couple of days to come together and I didn't have a variation of this already in the can somewhere... this was brand new content. I was pleased that I came up with and shared the visual image of migration ninjas. As the closed vendors' licensing terms might prevent us from openly sharing migration kits or migration how-tos, the migration ninjas would be the community's system gurus who would slip into a library and perform the secret, inhuman feats necessary to migrate from a closed system to an open system.

I wasn't at all happy with my live demo. First, I failed to arrange with the conference hosts to obtain an Internet connection, so the cover art in the catalog and the Z39.50 copy cataloging in the staff client facets of the demo were a bust. Second, while I knew it would be an exploratory live demo, given that I had just achieved a full working install a few days prior to the session, it's not very impressive for an audience to watch a presenter fumbling around the command line in response to a question about the API. Third, I failed to show off some really cool features of Evergreen such as the shelf-browser (although without cover art it wouldn't have been nearly as impressive). I tried firing up the reports Web interface and failed. So, now that I have a working install, I'll be able to prepare a much better live demo in the future - I just hope that our audience didn't take away a bad impression from our session on Friday.

Questions from the audience

We had some good questions from the audience; here's what I can remember. Please add more to the comments on this post, if you have them!

Why is there so much interest in Evergreen and why aren't we hearing much about Koha?

Dan said something about how his first investigation of Koha revealed evidence of classic MySQL dependencies and assumptions in the codebase that, as a former product planner for IBM DB2 relational database, made him cringe. Evergreen, in comparison, is built on PostgreSQL which was reassuring. I failed to note at the time that Evergreen has been developed so that it can support other databases, although some work would be required to convert to the SQL dialect and full-text search required by the target database.

Art mentioned that while Koha had been quite popular internationally for the past number of years, it had not been as popular in North America. Part of that reason may have been a severe scalability problem that kicked in somewhere around 450,000 records. Dan suggested that problem could be traced directly to MySQL 3 / 4, but that it might have been alleviated in MySQL 5 (which Koha does not yet support). Art noted that Koha ZOOM, using indexdata.dk's Zebra indexing engine, overcame that performance problem but some extra care was required to commit updates to the index.

What about the dangers of someone forking the code?

In my opinion, we didn't really answer this question well. Art didn't think that a fork was likely as Evergreen had been built with the best-of-breed components and plenty of input from the PINES library staff and community. What I should have added was that the ability to create a fork of a project is actually a wonderful feature of open source - it enables communities to route around projects that become overly bureaucratic, or closed to new developers, or not interested in input or exploring new directions.

You (Dan) talked a lot about the benefits of a system built on standards. Can you show us what the Web templating language looks like?

I fumbled this one badly. I quickly brought up footer.xml, but that doesn't contain any dynamic content so it was a bad example. I then suffered from presentation brain and couldn't remember the word introspect to demonstrate srfsh's ability to introspect its objects. Finally I (lamely) showed an example of a srfsh API request.

Summary

I believe that a solid business case needs to be developed on a library-by-library basis or on a consortial basis for migrations to Evergreen. I think that my presentation provided some useful input to those business cases, but in and of itself is not enough. Certainly, as our own library considers its options in the coming years, we're going to have to have a much more solid set of criteria before we can make any decision. I encourage you to take what you can from the presentation and improve, polish, and contribute your own analysis back to the Evergreen community so that you can help other libraries make an informed decision.

Many of you know that I have been working on step-by-step instructions for installing Evergreen on Gentoo on the official Evergreen documentation wiki. At the same time, I have been working on using that documentation to create a VMWare image of Evergreen -- this avocation dates all the way back to the ILS Symposium hosted by the University of Windsor in November, 2006. I owe endless thanks to miker, berick, bradl, and phasefx from the Evergreen development team for all of their assistance with my annoying questions over the past months.

Obligatory defining of terms: What is a VMWare image, and why should I care? VMWare is a virtualization product (the "VM" stands for "virtual machine"). Virtualization is a technology that allows you to run one or more "guest" operating systems on top of a "host" operating systems. So, let's say you're really interested in trying out Evergreen, but don't have a spare computer to install Linux on, or don't have the time or interest in learning how to compile packages from source on Linux, or don't have much Linux experience -- you can install the free (zero dollar, but not open source) VMWare Server on any Windows computer, download an Evergreen VMWare image to your computer, and start up the Evergreen image. In less than an hour (assuming you have good banwidth to download VMWare Server and the Evergreen image), you can have Evergreen-running-on-Linux, running in a virtual machine on top of Windows. That's the basic testing / evaluation test case for virtualization, anyways. For some small libraries, this may in fact be all that they need for a production library system -- but that's a discussion for another blog post.

One more note on virtualization technology: there are other virtualization options, like Xen or Bochs. But VMWare is the 900-pound gorilla on the scene, and it's what I happen to have the most experience and success using, so that's why I'm working with it. But it's an open community, so if you've got the skills to create images for other virtualization software, go for it!

The good news is that Evergreen appears to be running cleanly on my system. The OPAC works, albeit without any bibliographic entries at the moment as I'm still pestering miker with questions about the MARC record and holdings import process. But getting a working install seemed like the more important first task. Importing holdings and patron information is going to require different steps depending on which ILS you are currently using, so this should be a reasonable starting point for an image.

In my documentation, I haven't attached the exact set of configuration files that I have used in the VMWare image, but I can do that if people indicate that they are desired. If you have questions about anything that seems missing from my documentation or why I made certain choices, I would be glad to share that information with you and correct the docs. But rather than supplying just the docs and config files, I suspect the whole VMWare image would be more generally useful in the short term. I'm guessing that most libraries interested in kicking the tires of Evergreen don't want to spend a large chunk of their evaluation period working out the installation kinks, but just want to get right to the hands-on portion of the evaluation.

So, Sunday night I uploaded my first version of the image and shared the URL with a few close contacts, asking them to flush out any bugs. Kudos to dmcmorris for indirectly leading me to discover that I had missed a minor dependency. Another upload last night, and I'm anxiously awaiting the feedback from my comrades in arms. If all goes well, a VMWare image of Evergreen should be available for download by the end of the week. Crossing fingers...