blyberg.net ILS Customer Bill-of-Rights

blyberg.net
Home   Files   About Me   Disclaimer   Contact
ILS Customer Bill-of-Rights
Filed Under:Library,Programming,Web Services,SOAP,Library 2.0
A collection of “must-have’s” for doing business in a Web 2.0 world
Michael Stephenswrites over atALA Techsource:
We need to open up discussions with the professionals at our ILS vendors, database providers, and subscription services and ask them: “Are you making the best product you can that will work for all of my users no matter where they are?” Inquire about built-in RSS feeds, tagging, and user commenting while you’re at it. The vendors that get it are, hopefully, already communicating future innovations as these.
That’s sage advice, these are the companies that literally determine what we can and cannot do with our systems. ILS vendors, however are a bit of a special case.
There is a lot of talk about what Library 2.0 is, what Web 2.0 means to us, and what technologies can benefit us (RSS, tagging, etc). Fine. ILS vendors are going to see this as a potential gold rush and try to capitalize on it at, what I fear, is our expense. And we may quite possibly be enabling them.
Why do I say this? Well, first, let’s look at what’s at stake here. Essentially it’s our data: our catalogs, our patrons, our website content, our library programming, etc. This is our precious gold. This is the raw material that we will use to shape the future of library services. The traditional business model that ILS vendors have pursued (and forced on us) does not give us the freedom to use our own data in the way that we’re ultimately going to want to use it.
That’s where the problem arises. If we put pressure on ILS vendors to begin providing new Web 2.0 type services, they most certainly will. They’ll charge for it, you’ll pay it and finally have RSS feeds, blogging functionality, whatever. Excuse me, but that’s crap.
Let me use RSS as an example. RSS 1.0 was born December 2000. RSS 2.0 in September 2002. It’s almost 2006 and ILS vendors are just now starting to unveil some RSS feeds. We shouldn’t be treating those announcements like watershed moments. They’re tidbits of “too-little-too-late” packaged in shiny wrappers, served with a helping of “Who’s your Daddy?”
No, that’s not ok. It’s certainly not innovative. We need another model that will allow us to handle progress ourselves because we can not, must not, rely on our vendors. So what should we be asking them for? In the face of Web 2.0 advancements, what is something concrete to demand of vendors that will enable us to implement our own individual visions of Library 2.0 and prepare us for what comes after?
I envision a library Bill-of-Rights with four simple, but fundamental must-have’s from your ILS.
1) Open, read-only, direct access to the database.
When I say “open” I mean, we should be able to run any query at all against our own data, however absurd it may be. “read-only” because I understand the need to protect data integrity, but no harm can come, whatsoever, from getting your own data out. Many vendors offer this already. Good for them. It should be standard. It should also not be prohibitively expensive. III, for example, provides the option of using an Oracle database in place of their own proprietary one. Going with Oracle would give you the ability to do SELECT statements, but who can really afford it? Especially after shelling out your next two branches for III itself. For most libraries, an open-source RDBM like MySQL or Postgres would not only suffice, but would be ideal.
2) A full-blown, W3C standards-based API to all read-write functions
This is the big one, because all else stems from here. We ought to be able to access every level of functionality inside our automation system using an open standards API. Everything from modifying a patron’s home address to cataloguing new items should be included. I envision a vast set of functions that can be described via a standard WSDL stream for interfacing via web-services. In addition, shared libraries need to be made available along with proper documentation. Ideally, these would be the same libraries and APIs that vendors themselves use. It’s clean, simple, and it makes so much sense. (It’s also why I’ve said before that vendors need to rewrite their software from the ground up)
Given these tools, libraries would be empowered to roll out new services and features in their time-frame, not that of the vendor. Vendors could still (and should still) provide templates for the more popular features such as RSS, but we wouldn’t be reliant on them. It would also let vendors focus on what they really should be focused on: the quality of the automation system itself. This isn’t a take-us-through-the-next-3-years feature. This, alone, is a major evolutionary necessity for the survival of the online library. If we don’t get this, we will fall irrepairably behind the curve.
3) The option to run the ILS on hardware of our choosing, on servers that we administer
We should have access to the machines that run our ILS. This does two things.
First, it ensures that we’re not being taken advantage of. If vendors know that we can log in and install better alternatives to the software and hardware they are reselling us (I’m thinking backup software in particular), they might be less apt to screw us with our pants on.
Second, it gives us the flexibility to run software locally doing tasks that we might not otherwise be able to do, such as cron jobs that parse logs, data files, etc.
As it stands now, if I know security is a problem on the machines running our automation system, there is very little I can do about it. We need to have the option of administering our own servers and being as anal about security as we like. This is about flexibility and accountability.
4) high security standards
I’ve made no secret of the fact that I think library infosec is unacceptable. Vendors need to step up now, review their best practices, and implement some very radical changes to the way they’re handling everything from roll-outs to patches to access protocols. We have the right to peace-of-mind (and so do our patrons, for that matter).
Looking at this list of four fundamentals, I’m thinking, “this is as basic as it gets.” This is not shoot-for-the-moon stuff. Yet, if conceded these features, we’d be given all the tools we need to permanently change the way we adapt to emerging trends.
posted by john on11.20.05 @ 11:29 pm
18 Comments so far
Leave a comment
You are soooo right!
I’m so happy to see that I’m not alone in my thinking. Everytime we purchase a new service from our vendor it’s more trouble than it’s worth … it looks great on paper, but then we get it and I find that I am powerless to resolve issues like simple layout and data arrangement. I want power! I deserver power! We are paying big bucks for these packages and the least they can do is open up the database so I can generate stats in a format that’s easy for us to use … or let me write my own RSS feed or email updates … etc.
Great post … I’m off to link to it from my blog
ByNicole Engard on 11.21.05 7:59 am |Permalink
Amen John!
I’m sooo linking to this post as well!
There is no excuse why the ILS vendors can’t have open APIs. So many places offer these for FREE, for software that is FREE, so why is it that the ILS vendors can’t do the same?
ByChris on 11.21.05 9:05 am |Permalink
I think there are some market dynamics at play. If you’re not focused on selling your product to libraries with real software development resources, or, more to the point, since few libraries have real software development resources, the cost of building an API for your already glommed-together, katamariesque nightmare ILS codebase would be prohibitive and not really result in more sales. It’s not that they can’t do it, it’s that they feel it has little (or even negative) value.
Also, people who are not programmers prefer turnkey systems, even if it means that you turn the key and the engine falls out.
Great post, John.
Byeli on 11.21.05 4:57 pm |Permalink
When you think about it, what you’re asking for is really no different than what a corporate enterprise would demand in dealing with their vendor. The data IS ours, and easy access to it is not even on the table – it’s a fundamental requirement.
Only when libraries, as a group, begin demanding from vendors the same level of operating efficiency and functionality expected by and afforded to the corporate world will our ILS systems not be delivered broken and already out-of-date.
ByMichael Casey on 11.22.05 8:28 am |Permalink
Why commercial ILS vendors won’t use an OSS RDBMS
John Blyberg outlines an excellent ILS Customer Bill of Rights. Read the whole thing, as he outlines some fundamental needs of libraries of all kinds. He also makes a plug for the use of open-source RDBMSs in libraries:
ByJonathan‘s WebSpace 4.0 on 11.22.05 11:07 am |Permalink
[…] ILS Customer Bill-of-Rights […]
ByCreative Librarian » ILS Customer Bill-of-Rights on 11.22.05 1:03 pm |Permalink
Great post, poses some interesting questions. Being part of an ‘evil ILS vendor’, you may be interested in my more detailed comments over onPanlibus
ByRichard Wallis on 11.22.05 8:58 pm |Permalink
[…] John Blyberg is the Network Administrator and Lead Developer at the Ann Arbor District Library. Yes, that library. The library with the most exciting Web site I’ve ever seen. The library that is implementing RSS feeds for keyword searches in the catalog. His blog blyberg.net offers many behind-the-scenes peeks at AADL and their Web site. If smoke comes out of your ears every time you think about the usability of your ILS, you should check out John’s ILS Customer Bill-of-Rights. […]
ByInformation Wants To Be Free » Blog Archive » Coders wanted. on 11.23.05 8:10 pm |Permalink
[…] Richard Wallis has posted a very thoughtful and reasoned response to my ILS customer Bill-of-Rights. I was really excited to see that people at Talis are taking this discourse seriously, and I’m thrilled to be having this conversation with them. In lieu of their recent whitepaper and their willingness to engage in this discussion at all, they seem to be the most progressive of the lot and I’m guessing we’ll see some very promising things from them. […]
Byblyberg.net » Talis responds to “Bill-of-Rights” on 11.24.05 10:45 pm |Permalink
[…] If you haven’t already read Blyberg’s ILS Bill of Rights I suggest you do so. Also check out the Talis reply and Blyberg’s response. Here’s a brief overview of the points though the commentary on the posts is worth reading: […]
Bylibdev » ILS Architecture: Open vs Turnkey on 11.25.05 7:31 pm |Permalink
[…] John Blybergin muotoilema ILS Customer Bill-of-Rights tiivistää varsin hyvin aikaisemmin mainitsemani OPAC manifeston ydinsanoman. […]
ByKaukomieli » …Ja olkoon kaikilla oikeus haluamiinsa kyselyihin on 11.26.05 2:38 pm |Permalink
[…] Our vendors will inevitably bend to our demands and add small features here and there, but even after that, we’ll still be stuck paying enormous amounts of money for systems that remain fundamentally flawed. Technology marches on, and inevitably we’ll find some new way to use our catalog data. John Blyberg is talking about this in his ILS customer bill of rights post, and that’s what I was getting at when I say the catalog should be like WordPress. […]
ByMaisonBisson.com » Blog Archive » Raging Arguments About The Future Of The ILS on 11.27.05 10:36 am |Permalink
[…] ILS Customer Bill of Rights […]
ByLibrary Views 圖書館觀點 :: Library 2.0 網摘 (2005/11/28) :: November :: 2005 on 11.27.05 11:37 pm |Permalink
And why exactly can’t this be done? Especially things as basic as W3C compliance? I was looking through hundreds of library web catalogs today and found many libraries that had rocking websites (standards compliant, good design, great usability), their ILS was junk. Total, complete junk. Why do we put up with this?
BySarah Houghton (Librarian in Black) on 11.29.05 9:40 pm |Permalink
[…] Fired up? Read more with my library catalogs should be like WordPress post, John Blyberg’s ILS customer bill of rights, and Ryan Eby’s open vs. turnkey discussion. […]
ByOPAC Web Services Should Be Like Amazon Web Services « MaisonBisson.com on 11.30.05 2:40 pm |Permalink
Sarah says, “Why do we put up with this?”
Sarah, I really think we put up with this because we (libraries) do not hold vendors up to the same standards that private enterprise does — we let them get away with stuff that a manager in a publicly traded company would get fired for allowing to happen. We need to begin writing better contracts and holding vendors to those contracts, and we need to do this as a community. Vendors that fail to live up to agreements need to suffer legal and financial penalties. This may sound harsh, but it’s reality in the corporate world.
ByMichael Casey on 11.30.05 11:15 pm |Permalink
[…] Unspeakable things were done to the OPAC! I’ve seen things, horrible things. I’ve been forced to do things I thought I’d never do! I really don’t want to beat this issue to death, but it had a major impact on the services we were able to offer at launch. We need a complete overhaul of our ILSs. I’m not asking for much, though, just four very basic, very simple requirements. […]
Byblyberg.net » Lessons learned: aadl.org 3.0 on 12.04.05 12:59 am |Permalink
I was a professional programmer for a decade, and was absolutely horrified at the state of library vendor software when I moved over to librarianship. As someone who has done similar types of programming professionally, I know what goes into making these types of products. There is absolutely NO EXCUSE for the current state of these things.
- Jesse
By Jesse on 12.08.05 2:32 pm |Permalink
RSS feed for comments on this post.TrackBack URI
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed:


Name (required)
E-mail (required)
URI
Your Comment
Subscribe to comments (Email must be filled in)
Manage Subscriptions

YOU PICKED KARL MALDEN‘S NOSE!!
_xyz