Presentation at the Lyrasis "Open Source in Your Library" conference

On Friday, October, 9th, I had the pleasure of (along with Joe Lucia and Karen Coombs) speaking at the Lyrasis "Open Source in Your Library" conference at the Olin College of Engineering in Needham, MA. First, a note about Olin College - it is a very modern campus that makes an excellent venue for a single-track conference (New England #code4libber's take note!). Second, this had originally been a NELINET conference, but as of last week NELINET had merged with Lyrasis to create a regional library non-profit organization that spans most of the East Coast of the United States.

My presentation slides (with copious speaker notes) are available in OpenOffice.org Impress, PDF, and PowerPoint format

I had been asked to talk about Conifer's experiences implementing Evergreen, as there is certainly some interest on the part of Lyrasis member organizations in open source library systems. I chose to tell the unvarnished story of Conifer: how we decided to build a consortial academic library system on Evergreen, what steps we have taken in the past two years, and probably more importantly what missteps we have taken over the past two years. I told some cautionary tales that were hopefully useful to others considering the same path, and then discussed the state of the Evergreen community.

As a quick recap, the biggest challenges we hit on the road to adopting Evergreen were:

• Finding skilled developer resources that could commit time to help us develop solutions for some of our requirements was challenging, even when we did have financial resources.
• Our largest founding partner withdrew from the project months before we were set to go live.
• Due to the effects of the recession on provincial and therefore university finances, and the increased burden on the remaining Conifer partners for the shared costs that weren't reduced after the partner's withdrawal, our collective budget was slashed and we ended up having to pay opportunity costs by focusing on migrating our own data rather than outsourcing that role and focusing several months of effort on development.

I noted that our efforts to build a reserves system (Syrup) have thus far resulted in a loosely coupled reserves system that none of us have been able to use - but that for the time being Evergreen's bookbags have served as a reasonable replacement for lists of monographic reserve items, and that the discussion about how to more tightly couple Syrup with Evergreen has resumed (and is currently waiting on me for a response)... so there's hope that we might be able to deploy the all-singing, all-dancing reserves system next term.

I confessed that we're using spreadsheets to track acquisitions while Evergreen's native acquisitions system solidifies (although, given the current state of our budget, spreadsheets are all that we need for the time being - sigh). Joe Lucia had remarked during his own presentation that an acquisitions system that can handle the rather complex requirements of academic institutions was a showstopper for his library. In the Evergreen 1.6 release, you can see that the acquisitions system is almost ready; we loaded six years of historical acquisitions data into a test server and were able to do most of what we need, subject to some refinements. I think it has been an extremely challenging balancing act for Bill Erickson to juggle the requirements of academic libraries with those of large consortial public library systems to come up with something that can make everyone happy (as happy as you can possibly be with acquisitions), but the progress over the summer has been encouraging.

On a more positive note, one of the great advantages of adopting a consortial library system is that I was able to take two months of parental leave and not worry about the state of the system at all. We have shared responsibilities across the consortial partners, such that I can actually turn off my cell phone when it's not my turn to respond to problem reports. And during my absence, my colleagues (Art Rhyno, Robin Isard, Kevin Beswick) all gained a lot of confidence in their own understanding of the system. This shared responsibility should also pay dividends when we put together processes for reporting records to our various consortial catalogues (such as AMICUS): rather than each of us having to rediscover the process on our own, we can collaborate and improve upon each other's work. It's a lot less lonelier being a systems librarian in a consortial library system, let me tell you!

I also shared our positive experiences with Evergreen's uptime and with Equinox as a support provider. The few times that we have had outages, they have been relatively brief and when we have opened a problem ticket with Equinox, they have responded quickly. Robin measured our uptime over the last two months at 99.5% - which isn't five nines, but is still far better than the 75% (maximum) that we had with our previous system due to the six hours it was down every night for backups. We also chalk up some of the downtime so far to learning experiences; we're refining the configuration of the system and improving our own knowledge of how to maintain the system without incurring an outage. So, I expect that we'll eke our way back up over the next few months to an even better uptime percentage.

On the topic of the Evergreen community, I compared several commonly-used objective measures of the health of a given open source community, such as mailing list volume, number of contributors and contributing organizations, and release frequency with Evergreen's track record. We're doing reasonably well on the mailing list front, and we've seen a small increase in the number of patch contributors, but I think we need to make the on-ramp to Evergreen development slightly easier to ascend. This is why I'm trying to create a set of tutorials for new developers, starting with basic OpenSRF, extending through database access methods such as open-ils.cstore and open-ils.pcrud, rounding off with the IDL-aware custom Dojo widgets that Bill Erickson has put together, and perhaps giving people enough XUL to know how to add a new menu entry to the staff client. (I really can't tackle XUL, too, in just one half-day workshop!) If our community has a broader set of developers capable of contributing to the project, then we can expect to see more customization and extensions available - and possibly more committers.

On the release front, I got a rueful laugh from the audience when I said that the Evergreen 1.6 release was expected within a few days - "just like we [the developers] said at the Evergreen International Conference". I acknowledged that we've had trouble getting high quality releases out the door - that it took months, and five point releases, before the 1.4 release was really usable out of the box, and that it had taken even longer to get 1.6 out for a release. But I also promised that we (the core committers) had been discussing ways that we can improve the release process; for example, Mike Rylander had committed resources from Equinox to help build a suite of regression tests so that we could have automated nightly builds with known pass/fail rates, and on the mailing list we had been discussing different approaches to bug-tracking and development (including the possibility of using distributed version control systems to do feature development in branches instead of trunk).

On the state of the community, I applauded the Evergreen Documentation Interest Group (DIG) for leading the charge in taking a team-based approach to tackling a problem. I pointed to this as a sign the community was maturing beyond its origins of a core set of contributors who did everything from maintaining servers to creating Web site content to development, to a set of more focused teams that would be able to achieve more through close collaboration on their objectives. We're seeing that in discussions about a Quality Assurance (QA) team, as well, that would be responsible for tracking and verifying bugs in a public repository and (probably) enhancing the tests that let us measure the quality of the project code at any given time. I can imagine other possible teams charged with Web site design and content maintenance, perhaps as a more focused spin-off of the DIG; an internationalization team, focused on enabling translations and managing contributed translations; and an infrastructure team responsible for maintaining the health of the project servers.

Speaking of the community, this is probably a good time to suggest The Art of Community by Jono Bacon (Ubuntu Community Manager) as an excellent read - at least based on the first half of the book that I've managed to get through during my travels.

So, with that, I head back home (thanks Boston Public Library for the free wifi). We have challenges to tackle in both Project Conifer and in the growth of the Evergreen community, but knowing the people involved in both of these efforts, I'm confident that we're going to make a huge amount of progress over the next few months.