(via
http://www.livejournal.com/community/libraries/337810.html and
http://www.livejournal.com/community/library_grrls/208381.html)
Far too many OPAC vendors don't pay attention to what the library wants. Then again, many librarians don't know what's technically possible. *sigh* They just want to pay someone: get a standard, have it work, have someone to fix it if it doesn't work.
http://catalogablog.blogspot.com/2004/09/opac.html
http://www.oss4lib.org/
http://www.reinvented.net/article/2305
Hey, librarians, it's your own damn fault!
Part of the problem with dipping your toe lightly in as many waters as I do (which is another way of saying "part of the problem with being so scatterbrained" or, as Steven would say it, "part of the problem with not really being for anything") is that it's hard to participate with any authority in the post-game analysis.
I'm not a librarian. I am the spawn of a librarian, some of my best friends are librarians, I admire librarians, sometimes librarians even invite me to come and speak to them; but as an aversion to calculus kept me out of the space program, an aversion to ontology kept me out of library school.
As such, I really shouldn't wade into the how come our OPAC vendors are such dorks debate. But I will. Partly because it was this that apparently started it all. Partly because I'm a software vendor myself. And partly because I've watched the duelling between librarians and OPAC vendors, from the distant sidelines, ever since my mother became a technical services librarian back in the 1980s.
To summarize my thoughts: hey, librarians, it's your own damn fault.
When you outsource the administration of your data to someone else (whether it's an OPAC vendor or a university computing department or some guy down the street), you're also outsourcing any chance you have at retaining ultimate control over that data.
When you buy a "one size fits all" technology solution -- an OPAC that's designed for, say, "any public library" -- you're buying a commodity, not a solution.
And you should expect to be treated as an insignificant cog by your vendor: that's what you are. By absolving yourself of personal responsibility over your data management in the first place, you've already said "we don't care enough about this to do it ourselves, so you take care of it for us." Is it any wonder they treat you like they do?
Add to all of this that the prevailing wisdom in the old-line software world is that moves towards openness are to be best avoided lest users gain too much control, and is it any wonder that your vendors don't let you export data as RSS: if they did that, then you might start doing interesting things with the data, and start to realize that you don't need them as much as you thought you did.
You might say "but librarians shouldn't have to become programmers!" And you might be wrong. In the olden days, being a computer programmer meant a much different thing than it does now, and you truly couldn't be both a programmer and a [good] librarian because computers back then were more like coal-fired boilers that needed specialized practitioners to maintain.
These days we have the Internet, open source, scripting languages, UNIX everywhere: combined together these tools allow an informed person with an organized mind to create wonderful, powerful applications, customized to their own needs. Get those informed people with organized minds working together, and you've got a technology force to be reckoned with.
As librarians, you already have all the basic intellectual building blocks to take over the technology blast furnaces yourselves: you understand how information is organized, you understand the value of interoperability, you understand (intimately) the value of thrift and economy, and, what's more, you're already organized into associations that could become the sort home base that collaborative technology efforts can profit from.
Jenny says that "It's crazy to see users writing code to compensate for a lack of services from library OPACs." and "It's true libraries have limited resources, but they already have a vendor for their catalog, and that vendor should be the one leading the way." I would suggest a different tack: take the little scripts that I created not as a call to berate your vendors, but as a demonstration that it's really really easy to take control yourself using free, open, public resources that already exist. Don't berate your vendors, replace them.
If a scatterbrained non-librarian like me can string together 117 lines of Perl code to make an RSS feed of the books I have checked out of the library, just think of what a organized technology strikeforce of frustrated librarians could do! Vendors wouldn't stand a chance.