Let me say straight up that I don't think the ILS-DI group is wasting
their time or anything of that nature. It's a great effort, and more
efforts like this should be organized.
That said....
Kyle Banerjee wrote:
>> ... I just have a lot of doubt that
>> the vendors will actually continue to agree....
>>
>> ...And bottom line: what is their real incentive?
>
> That is the bottom line, but I think there is plenty of reason for
> optimism. The incentive for vendors to participate is that this is the
> sort of functionality it will take to be relevant in the future. When
> TV was invented, the radio people had to adjust. When people started
> getting their news from the internet, the newspapers had to figure out
> a new model. Those who provide library services need to face new
> realities, or our users will turn elsewhere and the money will follow
> them. Anyone who doesn't play ball will be left behind. This includes
> us.
There is plenty of reason for optimism IF we start looking to the
community for the solution and not the ILS vendors. The discovery tools
people are developing are excellent. I just got back from doing 2
presentations on VUFind at my ILS national users group meeting. And
while my ILS vendor took notice and is interested in interfacing, I'm
not going to depend or wait on them to put it into production.
It took our vendor long enough to give us access to those tools, and
even then there is a business model for a revenue stream for me even to
have access to that API. I brought this up at the code4lib conference:
our vendor already gives us these APIs in some way or another, and we
have to agree not to give our API apps even to other libraries who
haven't signed on for API certification. Why would I expect that
suddenly my ILS vendor is going to agree to open up an API to
non-customer libraries or (gasp!) another vendor?
> The reason Betsy is interested in business models is that if we change
> the way we use the ILS, logically it will affect purchasing behavior.
> Vendors need to stay in the black to stay in business, and it is in
> nobody's interest if what little competition there is dries up.
The problem with this is that no one is really changing the way we use
the ILS. What type of library you are defines the variation of your
budget of physical:electronic, but how we are all using the ILS is not
changing. We are still cramming in things as best as we can in the
limited ways that we can. There is yet to be a solution that can
realistically change that... yet.
We are also kidding ourselves if we think that the ILS vendors are
afraid of a mass exodus of their customer base. The vast majority of
libraries do not have the resources to:
a.) finance a migration to another ILS (OS or proprietary)
b.) finance human resources for OS
That is why when one vendor buys another, you don't see a large
migration change then because the buying vendor offers a ridiculously
low fee to move to their product "internally" that other ILS vendor
can't realistically compete with. VTLS tried to compete, but I haven't
seen evidence they got a lot of takers.
> ILS vendors currently have a product based business model. If you need
> something done, they sell you something that performs that particular
> task. Standards based services that allow us consider products from
> multiple vendors or develop our own are in conflict with that model.
Of course they are. And for many libraries out there, this is the only
way they can afford to do it. Look at the growth in libraries choosing
to go to SaaS. Libraries that are going through budget cuts aren't
looking to change ILS vendors or ILS solutions.
To be more specific, annual collection budgets often dwarf systems
maintenance budgets, so when an academic library (like mine) goes into a
new fiscal year in the red based on the inflation rate of journal and
database subscriptions compared to their journal budgets then there is
even less (financial) to push for a new systems model. My expectation
is that publics have it much worse.
> Library services are in a period of total upheaval. The whole idea of
> a library is that it is a centralized repository of information. The
> OPAC is a public view of the ILS -- a specialized inventory control
> system designed to optimize the workflows associated with acquiring,
> processing, and circulating physical materials. In recent years,
> patron demand for physical and electronic resources maintained by
> multiple vendors and institutions has skyrocketed, and this trend is
> strengthening.
I completely agree. And there are developing efforts all over the place
to combat this and meet the needs. Some very interesting ideas are
still in the works. A related trend is opening access for scholarly
publishing. It can be argued that trend is more important than solving
the ILS problem. I can make arguments for both.
> Shoehorning everything into a specialized inventory control system
> designed to circulate physical materials locally just doesn't work,
> and no vendor has the resources to do a decent job creating a product
> range that meets all our users' needs. We have to deal with a large
> number of vendors and institutional partners whether we want to or
> not. Our users demand it. That is why we are forced to hack things
> together and why there is such intense interest in standard protocols.
Based on my experience the ILS, while becoming increasingly rigid and
stale in its ability to meet new collection needs on its 20th-century
technology, is still showing its worth for what is has accomplished thus
far. Sure, we've had to crammed and stuff and hack things into and out
of it that don't quite fit, but for the most part things are stable.
The problem is that we now have an explosion of 21st-century technology
available that can't relate to this 20th-century ILS. So now we're at
quite a fascinating crossroads: Do we try to force the old ILS system
to come up to our standards of these small, new systems (and are they
actually ABLE to?) or do we organize in a different way to leave them
behind? Neither is simple, and both are costly.
> The work of the DLF ILS task force is important because there is
> little value and no future in products that do not work together. The
> fact that such an array of vendors would come to meet is by itself
> recognition that the issues are real and must be addressed.
The problem with the second sentence is that an array of vendors came
together before over a thing called ERMI, and I would argue that all of
them failed to address those issues that everyone recognized as real.
But I'll repeat what I said at the beginning in case it got lost:
I don't think the ILS-DI group is wasting their time or anything of that
nature. It's a great effort, and more efforts like this should be
organized.
Cheers,
Tim
Tim McGeary
Senior Systems Specialist
Lehigh University
610-758-4998
tim.mcgeary_at_lehigh.edu
Google Talk: timmcgeary
Yahoo IM: timmcgeary
Received on Thu Apr 17 2008 - 12:53:51 EDT