Library 2.0: An Academic's Perspective

« What They Should Teach in Library School | Main | The Ideal 2.0 Scholarly Portal »

Go Solo or Collaborate?

At the ALA Annual Conference in New Orleans last spring, I was talking with a friend who works in an academic library in California, and she was enumerating the things her library needed to enhance its Web presence. Her list sounded awfully familiar: custom-programmed databases for searching her library's digital collections, a blog and wiki installation, RSS feeds, improved metasearching, and so on. Everything she was hoping for were things that I would want in my own library. I've also heard other colleagues say they want these things - or were already implementing them - in their own libraries.

I thought a lot about the redundancy issue in the run-up to my creation of The URL Clearinghouse a couple of years ago. The Clearinghouse is a set of instructions for the creation of URLs to library licensed databases and e-journals. It's organized by vendors, currently fifty-seven of them. Figuring out these URLs can be a major chore. Each vendor has its own URL structure for its titles, instructions aren't always that easy to find (or accurate), and many vendors require that you manually create URLs based on a formula.

A half dozen years ago, I taught a summer graduate course at the University at Albany's library school called Internet Librarianship. I conducted a class exercise in which the students were asked to follow the instructions on the FirstSearch site and construct a URL to WorldCat that included certain functionalities. Few students succeeded, and everyone found the exercise to be a surprising challenge. (I'm uncertain if current students would find this exercise to be as daunting.) This type of work has been integral to my professional life for years because I maintain EZproxy for my library. So it troubled me that students were thrown by the task. As I took notes over the years on each vendor's URL rules, I gradually developed a vision of the same thing happening all over the world. Librarians everywhere were doing exactly what I was doing: figuring out the starting point URL for each title associated with each vendor in order to create an EZproxy record and to establish the appropriate links to be used in their library. The inefficiency revealed by this vision was breathtaking.

The URL Clearinghouse gathers together these instructions in one place and is freely available to anyone who needs them. Until I came along and created the site, no one had thought of sharing this specialized but widely-used knowledge. Everyone just went about their business, reinventing the wheel one URL and one library at a time.

The point I'm trying to make is that we need to work together to share knowledge and generate implementations. Those of us wishing to move ahead want so much, and we want it in a reasonable amount of time and at a reasonable cost. The problem is, we work in libraries that can't afford what we want, lack the infrastructure, or haven't the staff to implement our plans soon enough to suit us. Of course we all know this, and many of us work in libraries that have reaped the benefits of consortial-level projects. So I'm wondering how we can leverage a group strategy with Library 2.0 initiatives.

I've been taking a look at Participatory Networks: The Library as Conversation, by R. David Lankes and Joanne Silverstein of the Information Institute of Syracuse at Syracuse University. This was written for ALA's Office of Information Technology Policy. Without going into the gist of this paper, I'd like to concentrate on its major recommendation: the creation of a shared field-wide test bed. This test bed would implement a participatory network of libraries, and provide a common technology platform to host blogs, Wikis, discussion boards, RSS aggregators and the like. Development of a modernized ILS is also recommended as part of this test bed.

In addition: One model that might work is establishing a pooled fund from interested libraries. This pooled fund would support an open source technology infrastructure and small team of researchers and developers. The activities of the team would be overseen by an advisory panel drawn from contributing members. Such a model spreads out investment into experimentation across a broad collaboration, and should, ultimately, save libraries time and money. As a result, the time and money that individual libraries might spend on isolated or disconnected experiments can be invested in a common effort with greater return.

Exactly. Another advantage of this model is the momentem to be gained by a critical mass of libraries engaged in similar innovation.

The question is, could such an envisioned infrastructure result in what the authors hope is a "nimble organization"? How long would it take to create such an infrastructure, from its beginnings to actual implementations? Knowing libraries as I do, I would measure the time in years, not months. Years - even a few - are a long time in the life of the Web. I can think of all sorts of stumbling blocks and conflicts that could limit this collaborative approach. On the other hand, the economies of scale argue against each of us going it alone on similar initiatives. And I fully believe that projects maintained within the library world are important, especially because we are practitioners of preservation. For example, if our community hosts most of its blogs on the WordPress or TypePad sites, eventually we may lose this history. The folks behind the UThink project emphasize this, and they are so wise.

I have no answer for what might work well solo and what is a better fit for a consortial-type collaboration. The answer will be different for different libraries. All I know is that both approaches are necessary to move us forward.