Coffee|Code : Dan Scott

Karen G. Schneider has a great post on Enterprise Open Source on the ALA TechSource blog:

But the truly significant activity in LibraryLand technology hasn't been vendor-driven. It has been the maturation of what I call "enterprise open source": products such as Evergreen and Koha that are robust, well-implemented library automation packages with strong development communities and equally strong funded-support models.

Hear hear! Karen examines the value of open source, and finds that it's not so much in that it's a lower-cost alternative (although that can be a persuasive argument), and not so much that you have the ability to modify the code (although that can also be a persuasive argument), but that it depends on the strength of the community to continue to exist and improve. And that makes it a very good match for libraries, because we seem to do "community" better than most other industries.

So let me take a different tack than Karen, and assume that if you've read this far that you're interested in supporting open source for your library, but maybe you don't have a programmer on staff. How can you help?

Well, there are many ways other than programming to contribute to an open source community. Evergreen, for example, just posted a call on its development mailing list for help in defining and prioritizing the requirements for its acquisitions and serials modules. If you have experience with these areas, and have blue-sky ideas for how you could build a better system, this is a great opportunity to step into the conversation. There's a bit of a parallel here to proprietary systems, although with a proprietary system it's called a "request for enhancement" and most of those tend to get filed in the distant future. With Evergreen's invitation for discussion, you _know_ the developers are happy to listen to the ideas for making the best possible product. They don't have prior baggage holding them back, so they really can start from square one - and they have a huge incentive to do better than the existing options, because they want to convince you to pick Evergreen the next time you're thinking about your next ILS.

Or you can contribute your hard-won experience and knowledge to the documentation wiki. Evergreen and Koha both have wikis to which you can contribute. Interestingly, there is a parallel here to at least one proprietary vendor, which set up a wiki (behind a password-protected site) after many requests from their user group. It boggles _my_ mind, but some of these same customers have also argued that they (the customers) should pool their efforts and write a new set of manuals for the product for which they are paying support and licensing fees. I'm sure the Evergreen and Koha projects would really appreciate your assistance in writing a good set of manuals, and they won't charge you for the privilege, either.

You can also participate simply by joining in the conversations on the mailing lists or chat rooms (#OpenILS-Evergreen on Freenode for Evergreen, #koha on Freenode for Koha). You'll take some time to get familiar with the products, no doubt, but once you've climbed over the brick walls (with the help of the others on the mailing list), you will have the opportunity to pay it back a dozen times over as others face the same walls that you faced. I see this same principle on our proprietary vendor's mailing lists. The customers do a far better job of supporting each other than the vendor to whom they're paying support and licensing fees.

And it feels good, working together to build something that belongs to an entire community. For the little bits that I've been able to do, I get a huge sense of satisfaction. It's a nice little addiction.

I returned from a week of vacation to land solidly in the middle of a discovery layer selection process -- not for our library, yet, but from a consortial perspective clearly having some impact on possible decisions for us further on down the road. As the systems librarian, I was nominated as the person with the required technical skills for cutting through the skin of the vendor sales pitches and assessing the meat of the proposals. So far, so good. I'm incredibly busy trying to wrap up a number of projects before the return of the students in a few weeks, but this is important stuff.

As today's pitch went deeply into hour 4, I started mentally tallying up the resources that were being invested in simply listening to the presentations:

20-odd library folk from various libraries
8 vendor presentations
~4 hours per presentation
= 640 person-hours

At an average of thirty person-hours per week (a rough project management estimate allowing for vacations, sick leave, lunch, etc), that's going to result in at least 32 person-weeks of effort that could have been invested in taking an open source application like Blacklight, VUFind, or Fac-Back-OPAC, polishing it up to meet the requirement specification, and contributing back the code for the common good of all libraries. The secret sauce to all of these applications is Solr, a faceting full-text search engine (excuse me, "information access platform" in Endeca marketing speak). A few more person-weeks of effort invested in Solr might finish off some of the features that are almost ready for prime-time, like dynamic update of individual fields within a single record.

I know that the buy or build decision is complex. I know that it's very comforting to have someone to blame on the other end of the email, or telephone. But folks? When you're looking at investing in annual support and licensing fees, and possibly roping in 20 fellow libraries, that's a heck of a lot of resources to be committing to technology that's only slightly more advanced (in the best case; significantly behind, in other cases) than existing open-source solutions. And let's face it: with most of these solutions, you're going to be investing the equivalent of a person-year or more in customization costs before you even get out of the starting gate. This particular process may already be too advanced to change direction, so perhaps all I can do is plead with other libraries and consortiums facing a similar decision in the future to please consider the build option (and really -- it's a "build on top of existing components" option, not a ground-up deathmarch I'm talking about) seriously.

As a laundry-list systems librarian, my responsibilities run the gamut from crawling under desks connecting cables, administering our ILS, getting an institutional repository up and running, and contributing to open source projects. Maintaining staff workstations is part of the gig. Now, I'm pretty lenient when it comes to personal workstations... everybody pretty much has Power User status, so they can install and uninstall programs at will (sigh, yes, including WeatherBug and Dolphin Screensavers and other quasi-spyware). But for shared workstations, like our reference desk workstations, I recently enforced a stricter policy of plain old User access.

This caused some legitimate grumbling, as our public workstations are also locked-down and our Computer Services department hasn't figured out how to enable students to use their U3 USB keys, so in the past our reference people have taken on the role of saviour by accessing the U3 USB key on behalf of the panic-stricken student who needs to print their assignment that is typically due in ten minutes (or less). Locking down the reference desk workstations this summer removed this capability from our reference people, leading to potential stressful situations in the Fall when the students return en masse. (From a quick read of the U3 support forums, by the way, it sounds like our workstations need to enable write access to the %AppData% directory. I'll have to check on that.)

I mentioned quite a while ago that I thought virtualization technology had plenty of potential for software evaluation and testing purposes. Here's an example of another kind of problem it can solve. Today, I installed Windows XP under VMWare Server (running on top of my Gentoo laptop) and confirmed that its USB support will work. So tomorrow I can install VMWare Server on the reference desk workstations, drop a clean Windows XP image into VMWare, and give the reference people the best of both worlds -- all of the flexibility they need to meet the utmost of edge cases, and a stable workstation that everyone can depend on every time they boot up.

I had been getting anxious about the lack of news on the Access 2007 conference front, but just saw in my trusty RSS feed that the draft program schedule is now available. I'm already looking forward to Jessamyn West's opening keynote and Roy Tennant's closing keynote. They always bring interesting perspectives to the table.

I'm keenly anticipating (for obvious reasons) in the Open ILS, Web 2.0 and multitype provincial library initiatives in BC session -- the second implementation of a given application is always an interesting exercise, and it will be good to finally see the BiblioCommons social interface on a live system and find out how hard it was to write a BiblioCommons driver for Evergreen. I've had a chance to talk with Brandon Uhlman about some of the choices they've made for the hardware infrastructure and it should provide an interesting contrast to the Georgia PINES mega-cluster

The ILS Options for Academic Libraries session will also be interesting, although I'm a little worried about how well Evergreen will be represented. I know that Don Hamilton, from Wilfred Laurier University (WLU), has been working with Evergreen to a certain extent -- they have their e-book holdings loaded at Tamarak, although at the moment it doesn't seem to be responding. WLU is closely associated with the University of Waterloo and they collaborate on information technology, so I guess Allan Bell from WLU will be representing Evergreen on the panel. My worries are probably not warranted. And I find it both interesting and disappointing that Koha isn't mentioned at all as an option for an academic library. I suppose there are no Canadian academic institutions that have given Koha much serious consideration at this point; perhaps that will change once a Koha 3.0 release candidate becomes available and Koha will be better able to handle the volumes of items that academic libraries hold.

<rant>I don't understand why The Talis Platform gets a session. From the session description, it's purely a product presentation. Great, so the Talis Platform offers Web service APIs, and some people are building applications on that apparently. Yes, yes, you can share your data. What does it cost to store your data into the Talis Platform, and what other free or pay or income-generating features are Talis going to build on the back of all of that data they're hoping to attract, and why can't I simply get this information from the Web site, a product brochure, or a chat with a friendly Talis salesperson at a booth rather than taking up another valuable conference session?</rant>

Ah well. For one of the best library conferences, being held on Vancouver Island, I can deal with one off-key note. I already have my hotel room booked and I'll be keeping an eye on updates to the program schedule -- oh yeah, and registration is supposed to open up at the end of the week. Hope to see you there!