Mark says:
>I'd rather hand this task over to one of the half-dozen
>or so viable vendors left in the library automation market,
>and make the best possible use of their product within the
>limits & boundaries of that product. Those limits & boundaries
>may not be as elastic as I'd like them to be. Others find
>themselves in different situations, and they make the
>choices appropriate for them.
But the wider problem of the library automation market is the same one
that you identify. We're a niche market, with few players and little
real competition. Indeed, throw in the issue of how damn difficult it
is to switch systems (data lock-in, RFP-itis, etc.) and you could argue
that it's really not a functioning market at all. And in a
non-functioning market, it's hard to lean on our vendors enough to get
them to implement things like data APIs or direct database access (yes
Virginia, a lot of folks still *can't* get XML output or SELECT queries
out of their systems -- not for Love or Money.)
In an odd way, I do feel for the vendors. They charge a good bit, but
how could they not? Programmers, office space, help-desk personnel,
none of this stuff is cheap. And again, you're serving a relatively
small, fragmented market. How viable *is* this kind of system? Are
these guys even making enough money to survive over the long haul? (as
has been mentioned, we've seen *many* automation vendors fold over the
years). In this context, maybe a truly open ILS (not just the OPAC, but
the whole shooting match) makes more sense then not. Better to have
something that's yours for as long as you care to run the code. And
with an open system, you also have a better chance of actually getting
your data out in a usable form if you decide you want to use something
else later...
Ed Sperr
http://marginalist.blogsome.com
Received on Wed Jun 21 2006 - 14:38:03 EDT