I love that every now and then posts like this one from Sarah Houghton crop up. And while most ILS vendors do a pretty good job of ignoring the dissatisfaction outright (I know ours does), I like to think these posts must still get under their skin--even if just a little bit.
This latest maneuver against our vendors' flanks consists of several posts in addition to Sarah's. She links to a post from Steve Oberg who, in turn, links to a very interesting post at It's all good.
Sarah has every right to express the frustration she does with vendors. They are still, in many ways, serving to stifle some great innovation at a time when innovation is both vital and time-sensitive. I think that's the impetus for this frustration, now. Working with existing systems is outright infuriating and the promises we get from our vendors are like those you might get from an addict who owes you money: "I'll have it for you next week, I promise!"
I found Steve Oberg's observations to be particularly keen, though I do take issue with one point: "By and large, lack of deep pockets and resources to research and quickly implement new products or features". I believe the problem is not money even though vendors may see it that way--they are looking at the marketplace which is generating a perpetual demand for widget X, Y, and Z. Ultimately, I see this as a problem that is internal to our libraries and not with our vendors. Oberg almost touches on this with another point, "More attention [is] given to librarians’ needs than library users’ needs". Except, I would phrase it, "More attention is given to librarians' needs than the needs of those who work intensively with the ILS." In other words, the tech staff. Libraries have been incredibly reticent when it comes to letting technical people make the technical decisions. The result? Vendors who are given laundry lists of nonsense by folks who really don't know what they're asking for.
Alane at It's all good has a marvelous paraphrase of Pat Sommers, CEO of SirsiDynix:
Pat was responding, if I recall correctly, to a question from the floor about why ILS vendors don't innovate more quickly. Pat remarked that his company spends $10 million a year tweaking their systems to respond to requests from customers, and that left scant time and resources to make big changes. Robin rephrased this to describe all that activity as "building twiddly bits."
I'm glad Pat Sommers called us out on this. We are ultimately responsible for giving flight to an albatross that draws both vendors and libraries away from the marriage between our vision of tomorrow's library and 21st century technology. In reality, all we really need is the simplest of solutions: the ability to innovate on our own. But what will that take?
First, librarians need to stop asking for silly little twiddly bits. Libraries should be listening to their IT departments and vetting requests through them. If you don't have an IT staff, then a part of the solution is reevaluating your staffing needs so that you have some technical people on-board--this can be as simple as canvasing your existing staff, looking for someone who wants to make the move into geekdom. I believe that a coder-on-board sign is simply a characteristic of most 21st century libraries--it's not enough to employ the best librarians you can find, you need to get passionate, interested techies as well. Ideally, library schools ought to be considering the merits of a CS track. Courses need to be developed that synthesize coding skills with library science. The more technical know-how that is mixed in to their customer-base, the better chance vendors have at getting sensible feature-requests.
But it's not just us. ILS vendors need to wake up! An entire new business strategy needs to be extolled. What should that strategy look like? Vendors need to enable library staff with tool-sets in the form of standards and APIs. Of course I've been over this time and time again, but the fact is, most vendors are not hearing this. Maybe I'm feeling the fatigue that sets in after months of subverting the intended use of our system, but quite frankly, I hold little hope that our vendor will decide to pursue a strategy that champions community dev. In fact, during a recent visit to AADL, we were told by a top III executive that we have all the APIs we need. Apparently, he seemed unfamiliar with the entire notion. What we've accomplished is in spite of our ILS, not because of it. He was visiting under the pretense that they were very impressed with what we'd done with their system--I thought, "great, this is encouraging--a chance to open a dialogue". As it turned out, he was just using AADL as a sales venue for another customer. The irony makes me grit my teeth. It's a good thing I was on vacation that week--I might have told him that we've done things to their system that would make Paris Hilton blush. (I would have thought it, at least.)
There is real frustration among the people who are working with these systems, but it should also be said that some vendors are making an effort and seem to be truly "getting it"--or at least trying to get it. It's not entirely fair to castigate them all. They are not just some dark uber-force, brooding "out there" among the turbines of a ravenous capital market. It's important to take a good look at your own ILS and vendor to determine whether they really have your best interests in mind. You may just find that they do. If that's the case, use every ounce of that good fortune to your advantage because many of us are not so lucky.
[tags]ILS, Integrated Library System, Library, API, OPAC, Programming, Library Vendors[/tags]
Ryan Eby has done what III seems to not be able to do: Create a resource for XMLOPAC users. He's thrown up some wiki pages with the express purpose of documenting III's XMLOPAC. All I can say is, "Thank-you Ryan!" Be sure to participate and help with the documentation--we can all benefit from it.
