It’s easy to get mad at the OPAC vendor when the upgrade to their product brings your whole system down for months, but there are many stories in that one news article. The director of that library was a candidate for ALA President last year and no stranger to automation. The library used to be a Dynix library, before it became a Sirsi-Dynix library. It is now a Polaris library.
I’m sure this story is an extreme example of OPAC upgrades going wrong, but comments in the thread and elsewhere seem to imply that it’s not that unusual and it’s a telling downside to the relationships we have with our vendors. Whose responsibility is it when upgrades go wrong? Is that responsibility codified in print? What is the library’s responsibility as far as technical staffing and maintenance of the ILS system? Who determines the upgrade schedule, and what the upgrades will consist of?
I’m not a systems librarian, I just run a lot of blogs on a lot of different servers and so I sympathize with the troubleshooting nightmare that OPAC upgrades must bring. On the other hand, this library has been using Dynix since 1985, that’s pre-Web. So — and I oversimplify here — online catalogs went “online” before they had to think about the way we’d be pointing and clicking through web-based information 10 and 20 years hence and they did some pretty cool things. For a lot of people my age, interacting with a library catalog may have been one of their first used of public access computing. Then the Web took off and the dumb terminal interface to the library catalog seemed not just quaint and outdated but an active wall between library content and library users. And what did library vendors do? And what did librarians do?
I love reading what Steven Abrams has to say about librarian 2.0 and what Liz Lawley has to say about edge cases and early adopters. I like to think that some amount of money that we’re paying for our OPAC upgrades and our buggy operating systems keeps them talking. And yet, we have few (and possibly fewer lately) philosophizing practitioners, people who can solve the problem now, not just talk about how the problem should be solved.
Moving to more open web-like customizeable user-centered content and services is a tricky tightrope walk for any company with shareholders, or one eye on the bottom line. Library patrons aren’t like book buyers — if your OPAC is lame, they’re likely not going to go to another library [though they might just leave libraries altogther, although we haven’t seen that happening]. I’d really like to know what happened to the Rochester Hills Public Library’s circulation stats when they had a lousy OPAC for a few months.
For more on people solving this problem now, check out the new OPAC at NCSU Libraries, built on an Endeca platform. http://www.lib.ncsu.edu/catalog/ It has all kinds of cool search and browse capabilities. For an intro, see http://www.lib.ncsu.edu/catalog/index_arrows.html
[quote]
And yet, we have few (and possibly fewer lately) philosophizing practitioners, people who can solve the problem now, not just talk about how the problem should be solved.
[/quote]
As a former CS-degreed computer programmer about to graduate from library school, who’s taken an interest in both cataloging and systems, and in these sorts of problems in particular—I would LIKE to be one of those people, I think I have the background to become one of those people—but the career path to become one of those people is entirely unclear to me.
[Incidentally, I think ‘the problem’ includes parts of system design, but also parts of cataloging practice. I like that they’re trying to do interesting and innovative things with that ncsu catalog Monica points us to. Another document that’s been on my mind of late is this report:
http://libraries.universityofcalifornia.edu/sopag/BSTF/Final.pdf
“Rethinking how we provide bibliographic services for the university of
california”
]