Always Pushing Information

If your library were to adopt a content management system to handle its online content, how might you integrate it with your existing catalog? Most librarians would do what they've always done since the first catalog went to hypertext—they'd make the chrome around the catalog resemble their web site as best they could.

It's a trick with smoke and mirrors but without true integration: users cannot log into the web site and automatically be authenticated against the catalog, for instance. This simple act is a basic example of our inability to build a cohesive, overarching technology program within our institutions until we're allowed to conduct business outside the traditional boundaries of the ILS.

To be fair, enhancements and complex quality assurance protocols designed to protect the buyer dramatically slow vendor time-to-market for new features. Obviously, we don't want to entrust our most important data to second-rate software. Yet, even though I understand this, I still get annoyed with the ILS because it provides few mechanisms to develop our own software in response to emerging needs. This shortcoming is not unique to any particular vendor. There is no universal, high-level method for developing applications that will work seamlessly with the business logic and data inside our automation systems.

Nevertheless, in order to speed up the pace of transformation and progress, we need to pursue a path of democratic innovation. In November 2005, after completing several large development projects that involved some rather unorthodox methods of accessing the ILS, it became clear to me as a customer that we were being given far less access to our own data than we were entitled to. In response, I wrote a blog post espousing an “ILS customer bill of rights”—a simple and short list of “must haves”:

1. Open, read-only, direct access to the database
2. A full-blown, W3C standards-based API (application programming interface) to all read-write functions
3. The option to run the ILS on hardware of our choosing, on servers we administer
4. High security standards.

Of the four, the first two really embody the true spirit of the manifesto. They would enable librarians to pursue directly features that otherwise might not see the light of day for years. They say, essentially, that we should be able to make enhancements to our systems whenever and wherever we choose. This free development model is not a new concept by any means; librarians have just not had as much opportunity to be truly embedded as development partners with our vendors. Perhaps if I were to amend my original manifesto, it would include the right to participatory development.

So, a year and a half on, how has the playing field changed with respect to library development? Major events have rocked the industry since I wrote the bill of rights, including a number of private equity deals and the growth of library demand for back-end access.

Labor Day 2006 saw the launch of Georgia PINES's Evergreen system [see “Your Homegrown ILS,” LJ 12/06, p. 38–41]. The project's sheer scope and ensuing success have made this open source option a serious and growing alternative to the commercial ILS field. It adheres to the spirit of the ILS bill of rights and, as such, presents a whole new range of options to those using it.

The crown jewel of the PINES system is its elegant, easy-to-use OPAC. But what really makes it so advantageous is that in five years, if librarians decide to change its user interface radically, they would need only focus on that component while leaving the back-end alone. It has, in effect, separated form from content completely, something commercial ILS customers can't seem to do.

The flexibility that comes with Evergreen throws open the doors to library-based innovation. In the wake of Horizon's expulsion from the SirsiDynix portfolio, a number of libraries are giving serious consideration to Evergreen. Given the credibility it has earned in Georgia, the open source ILS could help usher in an era of cooperative, library-centered development.

Vendors are unprepared for what Eric Raymond, in his best-selling business book The Cathedral and Bazaar, has called the “bazaar-style” development model for several reasons. Chief is that ILS code bases are beginning to show signs of aging. Integrated library systems are very complex pieces of software that have evolved over time to suit the needs of a relatively stable set of demands and a slow but steady feature creep.

Recently, however, Web 2.0 and the ideologies surrounding it have done a lot to put that ecology on its heels. Cluetrain Manifesto coauthor David Weinberger discusses the new, piecemeal composition of Web 2.0 technologies in Small Pieces Loosely Joined, and his new book, Everything Is Miscellaneous, explains how seemingly arbitrary systems of classification can create new ideas and possibilities. Richard Gabriel's article “The Rise of 'Worse Is Better'” does a good job of explaining why the same principle, applied to programming, can be highly effective. Where the methodical approach to a “total package” was the desired norm, we see demand now for open, organic, component-based architecture. Increasingly, those components are being made available as web services and APIs by big-name companies like Amazon and Google in an effort to encourage users to mash-up their content.

Like Amazon, libraries are content providers while our vendors are not. So even though mashing-up our services on our own time and dime may benefit us, it produces some concern among ILS merchants that make their money from writing and selling software and providing maintenance support.

Finally, while there are indeed many specifications for open standards in libraries (SIP, SIP2, NCIP, Z39.50), there is no consensus on a high-level standard for vendors to adhere to. That means that even if we ask for an API, we might get an arbitrary suite of hooks that don't correspond to any other system.

But this could change: several vendors' business models are undergoing interesting transformations. In an effort to cut into one another's market, they have begun to build products that are intended to work with competitors' systems.

One example is Innovative Interfaces Inc.'s Encore product. This standalone software is III's answer to Endeca (used for North Carolina State University's much-praised catalog), with a solid nod to Web 2.0. Shrewdly, III has made Encore a platform-independent replacement for the OPAC. Likewise, Ex Libris has rolled out Primo, another cross-platform performer that flexes some Web 2.0 muscle, including tags and Ajax in the display. Products like Aquabrowser, BiblioCommons, the University of Rochester's eXtensible Catalog, and LibraryThing for Libraries are also in on the third-party OPAC market.

In addition to the increased competition in the marketplace, these vendors may face internal pressure to begin offering comprehensive web service layers and APIs in order to pave the way for these products. Could it be that vendors themselves are now realizing the benefits of a distributed development model? If they are, will they bring their customers into the loop and allow them to use the same tool kits their own developers use?

More competition in the marketplace could mean more choices, lower prices, and better quality—all good things. Vendors, in return, could see higher revenues as their potential customer base grows to other audiences. Presumably, these products have all been created in response to what library developers want. However, are these products any more than smaller black boxes that interact with vendors' bigger black box counterparts?

They don't, after all, enable the end user to write a custom circulation client, fundraising module, or even a desktop widget that does more than simply display checkouts. Library-based development has not been a priority to vendors and continues not to be. To be fair, the demand has not been great enough to garner much attention. There are simply not that many developers in libraries, and those who are there may be too busy to proselytize. The irony is that many of the features that we clamor for—and that drown out the call for APIs—could be developed in libraries themselves and shared freely among our organizations—if we had the means. As the Georgia PINES team demonstrated, it only takes a handful of people to make a significant impact.

Libraries still pay up to (and sometimes more than) $500,000 for their automation systems and devote hundreds of thousands of employee hours to make the data inside work for them. Are we truly getting an appropriate return on our investment if the data that we own is not available to us when and where we want it? If we were to liken our information architecture to our physical architecture, we would find the spaces are outdated and no longer work for us as efficiently as we'd like. Here in Darien, CT, we're building a new library that our director, Louise Berry, likes to describe as “timeless.” What she means is that the building has been designed to suit its time and place, despite any changes within the field. What we need from our vendors is timeless software.

New ways of thinking about the library's mission and operations have given rise to a new breed of buildings, yet no such transformation is taking place with our library systems. We'll get there eventually, but it may not be as elegant as we like, at least not at first.

Ultimately, development partnerships are the key component of library-centric innovation. For most libraries, the open source ILS option is not yet viable. It requires a great deal of technical expertise in-house to implement, maintain, and support. The talent pool just isn't large enough to underpin a mass exodus to systems like Evergreen and Koha.

It's our responsibility, then, to make it clear to vendors that we would like a close partnership on an equal footing with them and their development teams. Such partnerships would be more significant than simply beta testing products; development within the group would be shared with the entire customer base as it's rolled out. Such a model could grow into a truly symbiotic relationship where everyone benefits.