To pile on here, economically there is a lot of incentive to support
this (full disclosure: my employer both supports the ILS-DI
initiative and is currently backing Jangle [1], an open source
project that is intended to help facilitate making the ILS-DI spec
easier to implement, among other things): this is a marketplace that
doesn't offer much opportunity for new clients. Vendors basically are
forced to develop a 360 degree product suite (or partner with another
company to provide functionality) since the lack of interoperability
makes it problematic to sell to customers of other vendors.
This then limits the vendor (mostly) to their existing customer base.
Since this would provide diminishing returns (not every ILS customer
is going to buy your ERMS, your link resolver, your metasearch, blah
blah blah), some products would inherently become a lower priority and
lack the attention and resources needed to really shine. The other
possibility is that resources get stretched so thin in order to
provide the 360 degree solution that the entire lineup may begin to
suck.
It's certainly possible that companies may not want to participate in
this sort of economy; rather than compete head to head on the merits
of their engineering and design, instead fall back on a model that
locks customers in. The reality of the library world, however, is
that no one vendor can hope to win all the contracts of their ILS
customers (or whatever their flagship product happens to be); library
funding and the RFP/bidding process doesn't make this feasible.
Open data and an easy, consistent and comprehensive means to access it
could really fuel a new wave of innovation in the library marketplace:
both open source and commercial (and in between). I think most
vendors have got to be able to see this. I know developers do.
[1] http://jangle.org / http://groups.google.com/group/jangle-discuss
-Ross.
On Thu, Apr 17, 2008 at 8:22 PM, Mike Rylander <mrylander_at_gmail.com> wrote:
> On Thu, Apr 17, 2008 at 5:22 PM, Eric Lease Morgan <emorgan_at_nd.edu> wrote:
> > On Apr 17, 2008, at 2:05 PM, Tim McGeary wrote:
> >
> >
> > > 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.
> > >
> >
> > There is almost always two sides to every story. I would like to hear
> > what some of the library vendors think of all this.
>
> Donning my Vendor(tm)(R)(C)(SM) hat for a moment...
>
> I greatly appreciate this effort. It provides a guide to what working
> librarians perceive to be critical services that should be provided by
> their ILS within a specific context, and it spells out, in
> straightforward, unambiguous terms (*cough*NCIP*cough*), the semantics
> encoded in a Discovery Interface interoperability API. Of course, it
> doesn't hurt that I happen to be designing and developing a new
> consortial borrowing platform (<shameless-plug>
> http://esilibrary.com/blog/?cat=8 </shameless-plug>) and one of the
> core components just happens to need an API shape very similarly to
> the ILS-DI proposal.
>
> Now, mind you, I'm speaking as an Open Source vendor. By our very
> nature we strive for interoperability and openness in the software we
> create and the services we provide. I leave it as an exercise for the
> reader to research and decide whether proprietary vendors have a
> history of doing the same, and whether they will, and indeed will
> _have_ to, in the future.
>
> --
> Mike Rylander
> | VP, Research and Design
> | Equinox Software, Inc. / The Evergreen Experts
> | phone: 1-877-OPEN-ILS (673-6457)
> | email: miker_at_esilibrary.com
> | web: http://www.esilibrary.com
>
Received on Thu Apr 17 2008 - 21:18:06 EDT