Library Software Manifesto
By Roy Tennant - Posted on November 12th, 2007
Tagged: Integrated Library Systems
This is offered in an attempt to rationalize the relationship between libraries and library systems vendors, which is presently unhealthy. I encourage comments directly on this post (see below) or emailed to me directly.
Consumer Rights
- I have a right to know what exists now and what is potential future functionality. — Marketing materials may tout a new product or a new version of a product, but I have a right to know what I will receive if I buy the product today.
- I have a right to use what I buy. — For example, it should not cost extra to create another index of my data.
- I have a right to the API if I've bought the product. — An application program interface (API) is simply a structured way for one application to communicate with another. In other words, the ability of a software program to send a structured query to another application and receive a structured response. Using the API for a product I've bought should not incur an additional charge.
- I have a right to complete and accurate documentation.
- I have a right to my data. — This includes the ability to bring forward not just my records, but also usage data (for example, how many times a book was checked out), since such information will be increasingly important for relevance ranking and other purposes.
- I have a right to have read-only access to the database. — There are many good reasons why customers should be blocked from writing directly to an underlying database, but there are none for being able to only read from the database.
- I have a right to not have simple things needlessly complicated.
- I have a right to know the development path and timeline for a product I have purchased.
- I have a right to take technical questions to staff capable of understanding and answering them.
- I have a right to not be an involuntary beta tester.
- I have a right to have my work on local customizations and settings preserved across upgrades.
Consumer Responsiblities
- I have a responsibility to know the needs of my users.
- I have a responsibility to put the needs of my users before my own.
- I have a responsibility to communicate my needs clearly and specifically.
- I have a responsibility to verify that the enhancement requests I make are really what I want.
- I have a responsibility to assign enhancement priorities fairly. — Not every enhancement request can be top priority.
- I have a responsibility to realize I'm not special. — Therefore we should try to come to agreement on how to do the same things so we can minimize the investment in writing software to help us do it.
- I have a responsibility to select software using a fair and reasonable process. — Specifically, can we all agree to stop the pain of the RFP process? Please?
- I have a responsibility to report reproducible bugs in a way as to facilitate reproducing them.
- I have a responsibility to report irreproducible bugs with as much detail as I can provide.
- I have a responsibility to view any adjustments to default settings critically.
Shared Responsibilities
- We share a responsibility to begin from a position of mutual respect. — Only after a party makes an ass of themselves should we be free to make disparaging comments about them.
- We share a responsibility to communicate well.
- We share a responsibility to establish and maintain a rational enhancement process.
- We share a responsibility to keep the needs of the end-user paramount.
- We share a responsibility to lighten up and have fun! — I mean, no one dies in libraries. Let's get some perspective.
Note: Substantial contributions to this manifesto were made by Thomas Dowling and Carl Grant. This was first made public at the 2007 CODI Conference in Pittsburgh, PA, 8 November 2007.
I have a right to have my experience and that of my patrons as software users heeded, respected, and used as a spur to elegance and usability in development.
(This is as often violated by open-source developers as vendors, in my experience.)
Gosh, I sort of made the same comment to Science Library Pad, but I think we really need to get a discussion going in libraries on metrics of impedance, throughput and fidelity with software. I suspect all of the vendors, ILS or otherwise, would claim they hit these bases, and the important variance would be in the implementation. For example, I believe III has responded in several forums that they do give “read-only” access to library databases via Z39.50, and SirsiDynix has long offered an API option. How well do these options contribute to malleable catalogue content in a web context for libraries? And, speaking as someone who owns a business, how does cost factor into base functionality and software rights? Most manifestos are created in environments where economic disparities are rampant. OCLC's fees, for example, are a huge deterrent to the benefits of the Open Worldcat program. And if an API costs extra, does this violate the rights listed here? After all, a “right” is generally not something you pay for. On the other hand, if the underlying system is 10 times more expensive than another, does it make sense to apply the same criteria to the results if the economic model makes it more possible to throw more developers at a function? Just to put on a spin on the “lighten up” point, but imagine if library technology really was like medicine, and the kind of protocols used to measure medical treatments were in the mix. I suspect this level of detail is, in fact, exactly what we need. I guess I tend to think of manifestos as a great stepping point to overthrowing the existing order, but I have this sense of standing with our torches at the village gates and saying “well, what do we do now?”. There have been some fairly recent rating models defined for OSS, such as OpenBRR, and maybe it is this kind of model that would could be a goal for a manifesto. Make no mistake, I think it totally rocks that you have given voice to what is a huge amount of unhappiness on the library software landscape, I just wonder if the revolutionary fervor can be applied to building something that can be measured.
What a manifesto!
Rock on Roy!
~Kathy @ CIL