About 3 or 4 years ago, I stood before a panel of library automation CEOs at the annual RMG session hosted by Rob McGee. The discussion had taken a typical turn–why do we pay so much for these systems? I’ve never really accepted that premise. I always thought that libraries were paying what was required of them for vendors to do what was being asked–incremental changes to legacy systems are expensive and time-consuming. I have put this in another more pejorative and accusatory way: vendors squandered our money doing exactly what libraries asked them to do. But in that RMG session, I stood up to counter the “we pay too much argument.” I suggested that I had a blank check, and that the CEOs need only tell me what new and exciting things they were working on and I would gladly subsidize the effort. Crickets chirped.
Of course, this was before all the next-gen online catalog arms race (it was those crickets chirping that really convinced me back then that it might take looking outside the typical library automation market to raise the bar). We are improving the lot for patrons with great rapidity, faithful investment, and thoughtfulness. But what are we doing for library staff?
I’ve said it before and I will say it again. Choosing a library system is a lot like choosing a rental car off the lot. We can quibble over features, keystrokes, and usability heuristics, but library inventory management is largely state of the art across the board. So what should we do next for back office operations? Surely open sourcing state-of-the-art software can’t be all we can do! Surely API access to data is only a first step in a longer journey to improving back-office systems.
This is in no way meant as a slight to my brethren in the open source arena. First, the newest of ventures have re-built old things with new technology. Like the legacy OPAC and the ERM system that just won’t fit in the ILS, new technologies were required to improve our plight. One must be wary, however, because just as ‘open’ does not equal ‘free’, nor does it mean ‘new’ or ‘better’. Secondly, the philosophy of open source has now permeated the library space–it’s champions have done a nice job of aligning the OSS (aka FLOSS
) philosophy with the ethos of librarianship. For the most part, I think library administrations and technologists are doing a good job of answering the question: am I doing this for technological reasons, or philosophical ones, or both?
“Just because yours is better than everyone else’s does not mean it is any good.”
But whether it’s an open code base, an API, or a change in corporate ownership, we must continually ask, “so what?” Am I reducing my total cost of ownership of the systems I run? Am I making my staff more efficient? Am I innovating the state of library automation? Am I getting what I paid for?
As we enter what I think could be a real renaissance for library systems and services, I would argue for a new set of criteria that determines whether libraries stay with the system they have or make a change to something truly new, not just something different. It may be years before we can kill off the traditional tender and RFP, but we can certainly write a new appendix to one. If someone were to ask me, “what have you done for me lately?” Rather than scramble for an answer while crickets chirp, I would quickly ask back, “what are you expecting?”