Will the Next Generation of Library Systems be Customer Generated?

I have been lurking in on an OhioLink task force discussing "next generation" discovery layers. One of the latest postings to the group was by Peter Murray , who highlighted a report from the Next Generation Summit Search Interface Working Group of the Orbis/Cascade Alliance.

The report supports several concepts I have been pushing for a couple years now, including the idea of consortia to support library systems development. However, the more important concept is included in the report’s recommendations:

Regardless of who provides the Alliance’s next generation OPAC product, one of the deliverables that must be available as part of any solution is API or web services access to the catalog. Access at this level is important for two reasons:

... All major ILS vendors but III provide their customers a web services or HTTP REST API access to their systems, allowing for continued development around the catalog. Lacking such access, the Summit catalog will continue to be marginalized within the consortium’s academic campuses as tools and services are developed that take advantage of web service friendly applications.

... The Alliance should strive to create a resource that encourages users, libraries, and campuses to develop services around the Summit catalog. The library community has recognized that our patrons want social tools, which we tend to identify as tagging, commenting, etc. However, Web 2.0 applications like Flickr are popular because of the API access that they provide to their users as well. This access has enabled other web services, individuals, and organizations to develop different methods for exporting and utilizing the images placed within the Flickr photo archive. The Alliance should strive to make the Summit catalog open in this way, so that users and members alike are free to enhance Summit to meet individual, campus, or consortial needs.

Aha. Without using the geek terminology what they are describing is actually Service Oriented Architecture. However, what I am really excited to read is the desire on the part of the Alliance to break library culture and control over bibliographic information and to let the customers play with it. The number of applications that make use of the Google Maps shows how creative customers can be in seeing new connections between information sources.

I could see a customer building a new system in which leverages OPAC data in a weekend which could take a library organization a year to work through. Libraries should be building and licencing systems which exposes our content and data. Let the customers can play with it. Let them mash it up. Let them create systems that fit their immediate needs.

The challenge is that libraries do build systems and services with our (librarian) needs in mind. Our need for control. Our need for perfection. Our need for process. A library information system (or service) that uses a development process that does not meet our internal cultural needs is almost immediately classified as being a failure. We then focus way too much energy doing a post mortem on what went wrong in the development process in an effort to "do it right the next time."

It's no wonder that library systems of tomorrow are really just library systems of yesterday.

It seems to me that as a profession we are stuck in a bad relationship with our systems and vendors. We just can't figure out a way to get out of it. Are we happy that III will not give us APIs? Are we so insecure with our relationship with them that we are content to take what they give us? Do we feel we are that powerless?

The approach that the Alliance has outlined in their report is a extremely positive sign that some finally have had enough and are willing to make the hard decisions required for information system independence.

Photo: "REST eye for the SOA GUY" by psd. Creative Commons. Sphere: Related Content