ulo.tricho.us

“If we’re arguing over semantics, we’ve been derailed.” Thus spake John Blyberg, and he says those sorts of things in meetings all the time, and takes the wind out of some magnificently superfluous tangents. He’s absolutely right, and the kerfuffle about the term (and the ideas of) ‘Library 2.0‘ could have been easily foreseen by the sufficiently jaded.

While I think the term is undeniably here to stay, there are a few factors that are kerfuffulating the issue that could stand to be aired out a bit.

Library 2.0 implies not only enhancement, but also inclusion.

Ever since we started banging those rocks together, we’ve been learning that newer is usually better. There will always be missteps, like Asbestos Pyjamas, or Windows ME, and not everyone is going to agree, like Buggy Whip Sellers, Travel Agents, or Torah Scribes, but the march forward over time has been, well, inexorable, at least in regards to technology. In the information age, programmer’s version control schemes were rapidly seized upon as a marketing device that presented an easy way to communicate both newness and essentiality. Procter and Gamble’s marketing people probably wish they could just release ‘Crest 4.2!’ instead of having to come up with a new phrase each time like ‘now with more whitening detartarizing sparkleoid microbead blaster POWER’, that has to be legible at a small size and at a distance, amongst a field of competing holographic sparkles.

So, yes, product 2.0 (or at least product 2.1) is almost always better than product 1.0, but that doesn’t mean that product 1.0 was bad (although it may have been). Not only that, but product 2.0 had better include almost all the features of product 1.0, or offer superior alternatives. There are no vestiges of the old republic to be swept away; product 2.0 is not inherently a coup. It’s the next iteration of the idea, building on the successes of product 1.0 and learning from its weaknesses. While product 2.0 may involve a complete restructuring of the backend if 1.0 was klugey or unscalable, I haven’t heard anyone say that the Library 2.0 idea involves that sort of institutional razing. We’re just talking about what our institutions should do next; the baby, she’s still soaking in it. You know, the bathwater.

It probably ought to be Library 7.0 or something.

Part of the kerfuffulation comes from the Library 2.0’s inference that these new ideas are the shiny new one true path version, and the history of Libraries up to this point are the old hat version. While it’s true that the new services (and more importantly, the new approach to service development) that Library 2.0 entails are enough of a jump from current practice to merit the next integer in the sequence, compressing the changes libraries have been through over the centuries into a single version can be seen as belittling or dismissive if taken too seriously.

So, what version of Library are we running here, anyway?

Okay, call cuneiform Library 1.0, after the oral tradition alpha and cave wall beta. The shift to paper-based books surely merited Library 2.0, and the Greeks’ addition of Fiction Collections in 500 BCE ushered in the era of Library 3.0. The Han Dynasty’s addition of a catalog, stored in silk bags, brought us to library 4.0, while the Romans brought a key innovation to Library 5.0: open stacks, a feature that would disappear from some future releases. The threat of shrinkage drove the medieval libraries to bring an interesting concept to Library 6.0; loss prevention in the form of chaining the books to the shelves. Maybe it’s time for that idea to come around again. Gutenberg forced reinvention into Library 7.0 as the precious became commodity (and as the Torah Scribes cried ‘Feh’), and maybe we can skip a bit to the expansion of the Carnegie era and call that Library 8.0. I think you can call the integration of events and programming into the core services of the public library Library 9.0, and the access point role that’s grown during past decade could easily be Library 10.0. It didn’t take long for the entire US to go from Library 9.0 to Library 10.0.

Now, that gives a better sense of the head start libraries have on the web; we’re already in our double digits. Web’s only just now hitting 2.0, but it has a buzz that’s undeniable, and the key idea is not that Library 2.0 will assimilate all the 1.0 stalwarts, leaving only a smoking bun blowing desolately across a gleaming dystopia of pulsating middleware and pingbacks, but that the next iteration of Libraries will take our formidable history and integrate the techniques and technologies of the Web 2.0 toolset to make something new, yet familiar, and hopefully, better.

Library 2.0 is not only for rich libraries.

It’s certainly true that at larger, more comfortably-resourced libraries and consortia, staff are more likely to have time to argue about this kind of thing, and while larger libraries are more likely to integrate Web 2.0 technologies into their services, the empowering thing about the tools is that it does not have to be that way. Because Web 2.0 is the product of increasingly smarter software development tools and progressively more robust open-source code libraries, inventing and implementing a new Library 2.0-style service requires more creativity than it does cash. Furthermore, the ideas of Web 2.0 are based around sharing code, access, and services; the stuff that the bigger libraries do over the next few years are likely to become available to smaller libraries much faster than the internet achieved its current ubiquity. The toe’s already in the door; better web-based services and the instant community they can bring can spread quite quickly, as the investments are centralized and little (if any) last-mile infrastructure upgrades are required.

Also, while a big focus of Web and Library 2.0 is on the web user, don’t forget that Library staff are web users too. Even if the digital divide still takes a bite out of the impact of a library web service in a community, these tools will provide better service and stronger community for staff and patrons in the library, not just remote users. And, as noted above, when these services get integrated into products, turned into packages, and distilled into simple scripts, implementing them is not necessarily going to involve a cut to collection budgets, especially if the services are provided for all libraries by Consortia or State Libraries. We’re all in this together, and the adoption curve is always speeding up… but it gets to everyone eventually.