CiL/LiC, January 2007: Introducing Libraries in Computers

[Note: the publisher [1] I write for has a liberal 90-day repub embargo, so I thought it might be interesting to post these earlier columns up here. I'll catch up a bit with the backlog of 2007 columns at first, and will then try to post them more regularly soon after the moving wall moves enough.

This column was originally published in the January 2007 issue of Computers in Libraries [2] magazine.]

Welcome to my first Libraries in Computers column for Computers in Libraries magazine. I hope you'll find it to be thought-provoking and fun to read. In this first column, I'll introduce myself, explain the funny name, and start things off by asking a few questions to get you thinking about what it might mean to build libraries from scratch from our users outward.

Our Shared Experience

In this column I hope to provide you with a chance to step back from your day-to-day concerns and to think about how everything you've learned from your time in libraries might apply to a world that looks very different from the world we and most of our libraries grew up in. Before I do that, though, I'll tell you a little bit about where I'm coming from. Even though my own professional experiences might seem nontraditional, I'd bet that we have much in common.

From what I understand, you CIL readers work in every kind of library; you're new to the profession but you've been around the block a few times; you've learned a lot about what it takes to run a library successfully but you worry that there's always so much more to learn; you love keeping an eye on new gadgets and Web tools but sometimes you wish it would all just slow down so you could catch up; you're insistent that the core purpose and goals of your library don't need to change much to stay relevant and vital for a long time, but you're sure that your library will look very different in the years to come.

I couldn't agree with you more.

My own career path has been strange and exciting, but maybe that just reflects that it's been a strange and exciting time to work in libraries. I enrolled in a “library” school at the University of Michigan in 1995, but graduated with a “master of information” degree in 1997. My first professional job as a librarian was at the Cushing/Whitney Medical Library at Yale University, which serves as both an academic library to the Yale School of Medicine and as a hospital library for Yale-New Haven Hospital. While there I learned a lot about running a busy library—from collection development to document delivery, and from the reference desk to our early Web interfaces. My memory of the reference desk at the medical library is that we had three very common questions: “Where do I get this journal article?”, “Why can't I read this from home?”, and “Where's the bathroom?”

To answer the first question my colleagues and I developed a journal metadata system called "jake." You could type a reference into jake and it would tell you which online database had a copy, and if possible, it would link you right to the article. To answer the second question I helped to design and install an off-campus proxy system and a Web-based document delivery tool that was one of the first of its kind. (I'll admit that we never wrote useful software to help with the bathroom problem, though.)

While working on these projects, we noticed something that they all had in common. Each depended upon free or open source software: Whether it was the database back end, the Web server, the proxy server, or the programming language, using free components saved us time and money. It was clear that we had benefited from free software, so we decided that the best way to participate in the open source movement was to publish our own work as free/open source software. Realizing this, we released our code for both the jake and Web ILL projects, along with all the data we had prepared for jake. Immediately, people wrote back to us about how useful it was to have these working examples of new services to study, or to use, or to modify and adopt for their own institutions. Many people wrote in with ideas of how to make it better, or with additional software to add new features or to fix bugs. Seeing firsthand how well this model worked, we even started a site, oss4lib.org, which is still active today, to promote the idea of using free software in libraries and to help other librarians get started.

The lesson we learned from free/open source software was that by participating in the community—whether as users, producers, or just noisy enthusiasts—we turned the whole world into our systems department and vendor all at once, and we helped to make it easier for our peers to do the same. This made it easier to add or improve library services, and I was smitten.

In 2001 and 2002 I worked on the DSpace project at the MIT Libraries. That was exciting to me because building a repository toolkit was an interesting technical and organizational challenge, and because it was going to be released as free software, and because the plan at MIT was to use DSpace to share the responsibility for collection development with the labs, schools, departments, and research centers the MIT Libraries served. Since 2002 I've worked as a programmer on grants at the Yale Center for Medical Informatics and elsewhere to support projects such as building a value-added index for animal and human health researchers called the Canary Database, developing an early social bookmarking system called unalog, and building a next-generation metasearch package.

These projects have two things in common. First is that each depended upon or became free/open source projects. After years of working with and contributing to free software, I can't even imagine working in libraries without the freedoms the free/open source software movement established. While this is not the thrust of my column, it's such an important thread through my own experiences, and so potentially beneficial to your libraries, that I'll touch on it from time to time. More to the point of this column, each of these projects is in part an attempt to offer new services to existing library user communities in ways that, over time, will improve the breadth and quality of the services themselves as more people use and contribute to them.

‘The Architecture of Participation’ Is the Key

Tim O'Reilly of O'Reilly Media talks about this model as “the architecture of participation.” He first applied it to the open source movement as a way of describing patterns he observed in the way successful free software projects build project support communities. Now the phrase also describes what differentiates the best new Web applications. What does it mean?

The first and primary tenant of “the architecture of participation” is a low barrier to participation, with a responsive community mindset that highly values contributions from all users. This empowers everybody involved, welcoming new users and sustaining long-time contributors alike. Another linchpin is a careful balance, perhaps adjusted over time, between an anarchistic free-for-all and a centrally controlled, authoritarian decision-making process. The particular balance necessary for any one project might look different from others’, but the key seems to be empowering individuals without losing sight of long-term project vision and objectives.

Finally, and perhaps most importantly for this column, is this: The best projects find ways to reward participants by adding new kinds of value based on the collected actions of individuals interacting with the software or application or community in normal ways. In other words, there are many projects and applications that you use directly for some purpose, and they succeed in fulfilling that purpose, but that's all they do. You'll know you've stumbled into a successful implementation of a participatory architecture when the more you use it, the better it gets for everyone else using it, and the more everybody else uses it, the better it gets for you.

Examples of Great Participatory Architectures

Amazon.com rewards users by using information about what others shop for (and eventually purchase) to help you make your own purchase decision. Because it has succeeded so well at this, shoppers at this site are empowered by knowing that what they do on the site matters, especially because they don't have to do anything extra beyond what they normally do. You just buy stuff, or look at stuff, like you would in any store. And where you might've had a favorite salesperson in a clothing store, or a librarian who knows what you like to read, Amazon.com accomplishes a very similar function but at a much bigger scale.

The most popular social bookmarking services like del.icio.us and Digg create a similar reward for individual action. Individuals add data by saving links they like and tagging them with keywords and maybe voting them up or down depending on whether they like the links or not. These applications then feature the aggregated information about what their communities think about particular links and tags, which provides a new and useful view into the links that otherwise wouldn't exist. And they provide this extra value just by manipulating the combined actions of many individuals performing these same tasks.

Google rewards individuals (and enormous corporations alike) who create valuable Web pages. It never would have become such a good search interface if this hadn't been a critical element from the very beginning. Although it is easy now to question the relative value of some things you might find through Google, think back to the time before Google when it was very difficult to have your own pages be found through anything other than good luck. Now there's a whole industry devoted to techniques for creating the appearance of what Google's indexing algorithms value by simulating lots of links to one site from others through spam-creating scripts and the like.

So what does that mean for us?

Rethinking the Normal Library Architecture

It would be foolish to claim that libraries don't empower library users, or that libraries don't reflect the interests and needs of their communities. And don't get me wrong—I don't mean the following (or anything written this column, for that matter) to be a critique of libraries. Instead, I find “the architecture of participation” to be such a compelling description that it should be a fun experiment to rethink everything we know about libraries through this lens (for a few short pages every month).

That said, measuring library collections and services against these prime examples of the architecture of participation paradigm shows a few holes. For one thing, we could hope that materials selected closely reflect and change along with patron needs. But there's no disputing that collection development is usually a heavily centralized process controlled by librarians and the services they hire. So we lose a point on this new scale for being tilted too far toward central control. How do we measure up in terms of the ordinary actions of individuals adding up to something more than lots of individual actions? Beyond learning how popular books are by studying patterns of due date stamps, or noticing the occasional handwritten notes on a page or index card, or finding items requested by others, there isn't an obvious example I can think of that compares favorably to the examples noted above.

So what could it mean to “empower users” in a library? For this column, I'll start with an unexpected but simple answer. Imagine we're starting a library from scratch—no building, no staff, no budget, and no shelves, books, databases, or servers. All we start with is a community—a group of people connected to each other like any library user community might be connected to each other, whether for geographical, educational, corporate, or other reasons. Members of this community would probably have lots of computers and music players of their own, and lots of their own books, magazines, and videos, and lots of other random things collected over the years. What if we could instantly turn all of this into a library?

Setting aside the questions of copyright, technological barriers, and privacy, how could we make the individual actions of community members and the content they collect add up to a library? And not just a “library,” which is really just a database and a simplistic search engine, but a Real Library with all that means to those of us who miss card catalogs? Useful browsable indexes and shelves, reference structures that relate diverse items by topic or author, some means to meet and discuss or ask questions of each other about what's there or what's not there, and some way to connect outside of the local “collection” to pull in needed items when necessary?

To me, a new library radically devoted to the architecture of participation would have to have the collections themselves created dynamically from what community members bring to it through their own individual actions. On a basic level, this is no different from how lending libraries got their start. Those fortunate enough to have materials shared them, and others could borrow and share alike.

But back to the technology-enabled view—what if this could be made to happen automatically, easily, and usefully whenever any group of people got together? The group could be a school study group, or a bunch of friends at a dinner party, or strangers in an airport lounge, or neighbors on a block. What they would have when they got together would be a library—a living, breathing, “local” library. This would go far past the DSpace implementation at MIT Libraries, which distributed some collection development responsibilities outside of the library to well-established collections of community member organizations. This would take distributed responsibility to the far extreme, where all collection development occurred at an individual level.

Remembering that another key tenet of the architecture of participation is finding an appropriate balance between free-form chaos and tight central control, I think this model could work well, but only if what librarians know about building usable collections and services played a strong role. What we know about bibliographic control, equity of access, usability, and user-centered services could be used to provide the balancing control factor necessary to mitigate the otherwise-certain chaos.

All of this might sound crazy, but I hope it sets you to thinking. In future columns, I'll dive deeper into what this new way of building a library could look like. I'll consider how different aspects of what librarians know could inform a way to build participatory-architecture libraries from scratch. I hope you'll agree that “Libraries in Computers” makes for a better column name than “participatory architecture libraries from scratch.” I hope that these ideas start to resonate with you and what you know about your libraries. And I hope you'll tune in again next month to think about Libraries in Computers some more.