ILS Customer Bill-of-Rights

A collection of “must-have’s” for doing business in a Web 2.0 world

These icons link to social bookmarking sites where readers can share and discover new web pages.
  • blinkbits
  • blogmarks
  • co.mments
  • del.icio.us
  • De.lirio.us
  • digg
  • Furl
  • LinkaGoGo
  • Ma.gnolia
  • scuttle
  • Shadows
  • Simpy
  • TailRank
  • YahooMyWeb

Michael Stephens writes over at ALA 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.

These icons link to social bookmarking sites where readers can share and discover new web pages.
  • blinkbits
  • blogmarks
  • co.mments
  • del.icio.us
  • De.lirio.us
  • digg
  • Furl
  • LinkaGoGo
  • Ma.gnolia
  • scuttle
  • Shadows
  • Simpy
  • TailRank
  • YahooMyWeb

48 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 :)

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?

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.

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.

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:

[…] ILS Customer Bill-of-Rights […]

Great post, poses some interesting questions. Being part of an ‘evil ILS vendor’, you may be interested in my more detailed comments over on Panlibus

[…] 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. […]

[…] 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. […]

[…] 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: […]

[…] John Blybergin muotoilema ILS Customer Bill-of-Rights tiivistää varsin hyvin aikaisemmin mainitsemani OPAC manifeston ydinsanoman. […]

[…] 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. […]

[…] ILS Customer Bill of Rights […]

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?

[…] 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. […]

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.

[…] 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. […]

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

[…] I posted earlier this week about the ILS Customer Bill-of-Rights that John over at blyberg.net posted. This post has been commented on several other library related blogs over the past week … but the first (that I know of) reply from a vendor was posted yesterday by Talis (not the vendor we use). […]

2005 Non-Required Reading

I love the year-end lists. (If you love year-end lists, you surely know of the exhaustive annual Fimoculous meta-list). I have put together a little year-end non-required reading list of the library-related stuff I have read this year that has…

Great post - Libraries must begin to demand for easy access to their data. I don’t agree, however, that vendors will easily move toward open source RDBMS tools. Oracle is an enterprise, scalable system, providing various levels of security, accessibility, etc. (I’ve used it in both academia and business for 10 years). I just don’t see vendors moving in that direction…

Susan,

I’m not sure vendors will move to open-sourced RDBMSs either, but I think they should and I hope they consider it. Oracle’s cost if prohibitive to most public libraries. Databases like MySQL and Postgres can also be scalable, enterprise-level systems.

[…] blyberg.net ILS Customer Bill-of-Rights […]

[…] 去年11月20日John Blyberg 写了一篇ILS Customer Bill-of-Rights,随即Talis的Richard Wallis在公司Blog上做了相应回复。就这样,由ILS Customer Bill-of-Rights引发的一系列对话开始了,具体流程如下: […]

[…] 所以我们对2.0的需求应该是(John Blyberg ILS Customer Bill-of-Rights): […]

[…] Drawing from John Blyberg’s ILS Customer’s Bill of Rights and The Social Customer Manifesto, Jenny Levine offers this Online Library User Manifesto: […]

[…] Drawing from John Blyberg’s ILS Customer’s Bill of Rights and The Social Customer Manifesto, Jenny Levine offers this Online Library User Manifesto: […]

[…] Drawing from John Blyberg’s ILS Customer’s Bill of Rights and The Social Customer Manifesto, Jenny Levine offers this Online Library User Manifesto: […]

[…] Drawing from John Blyberg’s ILS Customer’s Bill of Rights and The Social Customer Manifesto, Jenny Levine offers this Online Library User Manifesto: […]

[…] John over at blyberg.net has a great post that I read this morning. 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?” He goes on to say that we should be asking our vendors for more control, more power over what is essentially our data … our hard work. […]

[…] ILS Customer Bill-of-Rights […]

Why is this posting so popular and yet we have such a weak open source ILS movement? Why can’t we get real momentum behind such an important tool?

[…] 當然,絕對不要錯過 Sirsi 的 Stephen Abram,在他的 blog 裡有很多寶貴的經驗及看法。John Blyberg 的 ILS Customer Bill of Rights 是一個很好的對話里程碑。 […]

The comments and the Bill of Rights confuse me. The vendor we use (for 24 years) provides a runtime version of Oracle as the basis of the software. Keeps our costs down. We could buy their Ad Hoc Reporting; but have not seen the need yet. The supplied reports are extensive. Our web interface is customizable and much more usable and powerful than many. I thought everybody had that. I guess we’ve just been lucky.

[…] ILS Customer Bill-of-Rights […]

[…] John Blyberg wrote a post yesterday (somewhat unrelated) where he says: Many of you who follow what I write here know that’s a contentious issue for me, but I’ll keep my hackles down for now and simply remind everyone that this is another reason to demand a few basic rights from our vendors. […]

[…] While in UNC-CH for JCDL I’ve had occasion to rant with/at some people about the state of the integrated library system marketplace — including, of course, how we got into the spot we’re in and how we might get out of it (and those people were kind enough to engage in the rant). Along comes a series of posts from Casey Bisson and Nicole Engard ultimately pointing back to John Blyberg’s “ILS Customer Bill-of-Rights” that is singing the same tune. There still seems to be a desire for a solution from an existing vendor, and in fact that was part of counter-points brought up by some on the receiving end of the ILS-must-go rant. (Paraphrased: ‘No one can satisfy the need of a library like a library automation vendor’ and ‘As libraries we’re not strong enough to take on the task of building the next ILS ourselves.’) Yet there does seem to be this mounting pressure to get control again over our data and how we present it to patrons. ¶ […]

[…] John Blyberg’s ILS Customer Bill-of-Rights is especially relevant here, but also, let’s think about our side of the relationship. […]

[…] Daniel Chudnov has a post over at One Big Library stating the problems with the ILS Customer Bill of Rights. While I agree with his points - he missed a big one. Since I was busy all day, someone beat me to pointing it out: I think I understand where he is coming from. But I think the disconnect for me comes a bit earlier in his post when Chudnov writes “you can choose NOT TO BUY THE FREAKIN’ PRODUCT.” […]

[…] Point A: John Blyberg’s ILS Customer Bill-of-Rights. […]

[…] Blyberg.net 2006: the year of the phoenix OPAC? ILS Customer Bill of Rights Library 2.0 websites: Where to begin? Why bother: the impact of social OPACs […]

[…] Addendum: I’m not sure there is an end to this topic. On Blyberg.net is this posting: OPACs in the frying pan, vendors in the fire. John takes an interesting chronological approach to the recent discussions particularly in light of his ILS Customer Bill -of -Rights. Recommended reading if you are concerned about the OPAC. Well, even if you are not concerned it is still recommended reading because you should be. Explore posts in the same categories: Uncategorized […]

[…] 5. When I first saw John Blyberg’s blog blyberg.net, I didn’t think it would be something I’d add to my blogroll because what I saw was a lot of code. I was like, “ok, he’s cool, but we don’t have III at Norwich and I have no idea what I’m reading anyways. But I saw an inkling of what was to come on his blog with the ILS Customer Bill of Rights and decided to stick with it. John came on most people’s radar screens as one of the major architects of the Ann Arbor District Library’s incredible Web site. He is a passionate advocate of Library 2.0 and of libraries empowering themselves to take control of their technological future. His posts show off his creative writing background as he muses on the philosophy of Library 2.0, how to bridge the tech gap, and how libraries can capitalize on mashups. His posts are the kind you reall need to print out and mull over. John to me is truly a philosopher of Library 2.0, but with the mad coding skills to back it up. I can’t wait to finally meet him in the flesh at Internet Librarian this October! […]

Having felt quite alienated on this issue for years, it is very encouraging to see this kind of discussion finally taking off in the last year.

Your comment on the traditional business model is correct, only I wish more people understood the dilemma (i.e. library directors, managers, etc.)

We all know this is a niche, “mature market” so ILS vendors have naturally accomodated their business models for this marketplace. Only now there’s more widespread understanding of this two-fold problem: 1) architecture and systems engineering for obfuscation (the “castle wall” approach to systems engineering preventing you from finding/developing your own solutions); and 2) extreme product segmentation built upon and benefiting from 1).

IMO, Libraries are really getting **killed** by this situation, further marginalized, and the vendors will not be able to keep up. We get ILS innovations 2-6 years out of date, then have to follow-up with 6-24 months for a procurement /planning cycle to implement (assuming you can afford the upgrade).

We need the ILS to be built upon a general application foundation, and open in the ways described by the Customer Bill of Rights.

[…] ILS Customer Bill of Rights & PatRest (API to make library catalog content available for power users in other contexts) […]

[…] 最近太平洋那边的网络图林很是热闹,Blyberg去年11月写了著名的”图书馆集成管理系统用户权利法案(ILS Customer Bill-of-Rights)”(包含四条”权利”,类似于偶的”图书馆2.0五原则“,但还要”技术”的多)之后,Blyberg又写了一篇有趣的文章:火烧供应商,油炸OPAC 。编目精灵也用一幅截图点了III名,做了一个简要报道。SirsiDynix和其它一些ILS厂商或许正偷着乐,但是我估计这些一丘之貉的紧张要多于幸灾乐祸。 […]

[…] relationship between libraries and vendors and libraries and patrons. This and John Blyberg’s ILS Customer Bill of Rights are two important documents that outline what we all should expect from our vendors, though […]

ba4886ac0b9c…

ba4886ac0b9c4063f8e4…



Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

(required)

(required)