Tuesday, February 8, 2011

Toys and Tools vs. the Enterprise at Code4Lib

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.
Enhanced by Zemanta


  1. That sounds analogous to the release early, release often motto of the free software movement...
    Great article! :)

  2. A quick fact clarification: ramp-up committee work for Kuali OLE has been on-going since July 2010, not a whole year before coding.

    The long version is that work has included a conceptual data model team to document the vast landscape of data standards & best practices OLE should use and support, modeling licensing and rights administration models that have yet to be automated efficiently, detailing internal and external library-arena workflows, and most importantly gathering, analyzing, de-duplicating, and organizing over 3500 user stories for managing library data, collections, and services.

    While absolutely true that Kuali OLE itself is not a "toy" project, we are wholeheartedly encouraging and expecting "toy" projects to surround, tap into, and leverage Kuali OLE just as these same projects (or ones yet to be invented) tap into our outdated ILS's. In fact, we want it to be much, much easier. I put "toy" in quotes because I really think these projects have greater value to the community than the context of that word gives credit.

    Beyond that, Kuali really isn't putting a lot of eggs into one basket of OLE. OLE is rather just another basket of information ready to be exposed and used enterprise wide. (Other baskets are Kuali Finance, Kuali Student, Kuali Coeus [Research], Kuali Rice [middleware]). Missing in today's ILS systems is the ability to leverage the rest of that campus-wide data, or systems for that matter: student information, vendor relationships, legal requirements, identity management, research/grant administration, etc. The ROI of leveraging those existing systems within academic library services is an order of magnitude greater than the current investment in Kuali OLE.

    It was great to chat with you in person tonight. Let's keep the conversation going. Cheers!

  3. I'm pretty sure that Brad Wheeler said "move beyond" and not "stop building."

  4. Timothy- thanks for the elaboration. Rabbit- I think you're right, but "toy" was definitely a pejorative.

  5. So true, so important.

    I like Clay Shirky's terse expression of this principle: "You cannot simultaneously have mass adoption and rigour". The WWW took off in large part because it was a toy -- easy and fun to play with. It's easier to retrofit rigour to something popular than it is to retrofit popularity to something rigorous!