Toys and Tools vs. the Enterprise at Code4Lib

© CERN

In 1991, the world's top researchers into hypertext met in a hotel in San Antonio, Texas. One poster presented there was entitled "An Architecture for Wide Area Hypertext", by a guy from CERN. Nine years later, I attended the same meeting in the same hotel. Attendees who had also been at the earlier meeting told me that the uniform reaction to the poster had been what what I'd describe now as "meh". It was too simple, not enough expressive power. There was nothing new, nothing interesting. Who could possibly care about about the physicist's stupid little toy hypertext system.

That physicist is now a Knight Commander of the Order of the British Empire, and Sir Tim's little toy system is the today's World Wide Web. Here's a few of the enterprise-ready systems that the conference organizers of HT 1991 thought were more important than "the web":   

• Industrial Strength Hypermedia: Requirements for a Large Engineering Enterprise
• Implementing Hypertext Database Relationships through Aggregations and Exceptions
• Applications Navigator: Using Hypertext to Support Effective Scientific Information Exchange

You get the idea. If you make a list of the most important technologies for libraries and publishing today, your list will include a lot of things in addition to the web that started out as toys, and were derided as such for years after they became important building blocks. Linux, unix, mySQL, perl, ruby, apache web server, and so on. Even Google started out with Lego blocks as key components. The list of software technologies that began as enterprise-class applications is smaller and less loved.

This morning at the Code4Lib Conference in Bloomington, Indiana, Brad Wheeler gave a welcoming talk. He's a Vice President for Information Technology and Chief Information Officer at Indiana University and Chairman and Co-Founder of the Kuali Foundation. He emphasized how important it is for libraries to submit to "volitional interdependence for macro solutions". I think he was trying to say that libraries need to pool their software development efforts and stop focusing on their local needs and peculiarities. But there was one thing he said that I strongly disagreed with. He said that libraries should stop move beyond building toys.

Wheeler's remark was in the context of a story about his impression of a Digital Library Federation (DLF) meeting two years ago. He thought the projects being reported there were too small and too focused on individual libraries. DLF has fresh new leadership in the person of Rachel Frick, and a new structure as part of CLIR, but I'm not sure that Wheeler's criticism of "the old DLF" is justified.

Libraries need to build more toys, especially in this time of tectonic changes in the ways that users interact with the information of the world. By toys, I mean simple experiments that do interesting things, or tools that focus on solving specific problems. The first day of Code4Lib was replete with examples of toy projects. Karen Coombs from OCLC showed 10 different toys, the most interesting a mashup of geocoded library subject headings with google maps. Josh Bishoff from the University of Illinois showed how the mess of links on his library's homepage could be distilled down to a nifty mobile webapp, complete with local bus schedules. Demian Katz showed how VuFind, a tool that has already made a transition from toy to essential tool is being pushed to be even more flexible. Jay Luker, from ADS, did the same with Blacklight and Solr.

For me the highlight was Scott Hanrath's report on Anthologize, a WordPress plugin designed to turn blogs into ebooks. The initial work on Anthologize was done using a "one week one tool" process, and his account of how 12 strangers banded together to produce a working product in one week was truly inspiring. They even included 4 user interviews in developing their user experience, and achievement which proved to be very difficult to pull off, because of the tight, parallelized development schedule.

The non-toy approach to software development was also on display. Tim McGeary of Lehigh University reported on the Kuali OLE project, which has attracted $5 million in funding from Mellon Foundation and others. OLE has an impressive, state-of-the-art, three tiered modular, buzzword-compliant software architecture and specification set. But after a year of work involving multiple committees, coding has only started last week. (Update 2/9/2011: Kuali's funding for writing code has only been in place for 6 months) It all looks very good, but I'm yet to be convinced that the end result will turn out to be what the market needs.

Development of things like OLE is expensive. Georgia PINES spent about a million dollars in its successful developing Evergreen, perhaps the most recent analog to OLE. The advantage to developing toys is that failure is not expensive. By spending so much on OLE, Kuali is putting a lot of eggs in one basket, and if their extensive committee work has failed to correctly predict what the market requirements in 5 years will be, they won't get another shot at it. In contrast, developing toys lets you try a lot of things out. Most will die, but the few of them that manage to solve sticky problems will get picked up and will grow into essential infrastructure.