One Big Library.

[This column was originally published, after additional editing by somebody who actually knows what they're doing, in the September 2007 issue of Computers in Libraries magazine. Which means I wrote it in July 2007, at which point I thought I was going out on a limb suggesting that folks would start to look at Facebook differently. Seems passe to say so now, but I thought I'd still add my $.02 sooner rather than later.]

The hottest social network of 2007 seems to be Facebook. I entered university in 1989, and we had a paper facebook. We used it for all the reasons college freshmen at a Big 10 school used a facebook. And somehow there was always that one guy who had to pose with his guitar in the frame - and a few short minutes perusing facebook.com indicates that that same guy is still out there with his guitar.

Facebook has done interesting work with its platform API, and its integration with “meatspace” human networks just might make it the first online social network that offers some sort of sustaining value beyond being “where the online hipoise hang out this year.” Last year that place was MySpace; the year before that it was del.icio.us, before that Orkut, and Friendster before that. Somewhere in there LinkedIn popped up for a “more serious” crowd, too, among other services such as Flickr for the photo-takers, and YouTube for the vid-makers. (No word yet on which web 2.0 startup will secure the vital demographic of butchers, bakers, and candlestick makers.) And there’s always Twitter for the status-obsessed, along with myriad competitors and copycats of all of the above.

I’m resisting Facebook, seeing as I’ve tried most of these other networks and found little substance beyond the initial excitement of finding out yet again that yes, I am indeed within six degrees of separation from kbacon22. What’s the point of hopping onto the newest network? The answer just wasn’t clear to me, especially since we librarian types aren’t exactly early adopters. Face it, facebookers, most of us weren’t on Facebook a few years ago when it was really a students-only application, and by now a lot of those early users have graduated or moved on to whatever new apps you’ll be reading about in CiL in 2008 and 2009. This is not your daughter’s social network application - or, at least, not any more, it isn’t.

You’re the Star

Meanwhile at my new job, we’ve been debating which metadata fields to capture and index on the project I’m working on. Which fields are which isn’t really worth mentioning here, but I’d like to reflect on something I’ve learned about metadata after having done this about ten times in five different environments. There are a lot of things to keep in mind, and distinct needs to balance, when deciding how to describe resources:

• descriptive metadata must provide access points to support discovery, relating of like items, and distinguishing between very similar items
• metadata values must be indexed so that common user search patterns will lead to relevant items, because an easy, useful search box at the top of every page is how most of your users will use your applications
• choices for metadata value forms (such as authorized headings or standardized date values) must support necessary user interface functions, like result sorting, browsing by topic, or viewing results on a map

The last two of these items seem pretty obvious - after all, if you want to sort views of your resources by date, you’ll have to let somebody line your dates up consistently somewhere, and if you want people to find your stuff, you have to make sure the terms they use to search actually find them what they want. But it’s that first point - the clear definition of access points - that always seems to clinch metadata schema decisions. Maybe we’ve come a long way since the Author-Title-Subject card catalog, but concepts like “main entry” are still deeply important. Systems and software give us more flexibility than ever before to tweak indexing algorithms or relate data in innovative ways, but if you’re a developer like me and you don’t have a clear sense of what your most important access points are, you might deliver a system that works well, but only for people who don’t really want to find what they’re looking for.

And this is why I think I get pulled back in to the each of the next, best, hippest (or even “hippest” in the sense that “now it’s mainstream and there are a ton of people in there even if it’s not really cool and new anymore”) social networks. I log in, create a profile, and identify a few friends because I am an access point.

And so are you.

In the decade since web use went mainstream, there’s been a lot of talk about what’s now known commonly as “the long tail”, or the ability of large-scale systems to help people with like interests find small-scale products none of us might otherwise learn about. We’ve talked about it before in this column, like when I wrote about the ability of Amazon.com’s servers to point you toward a musician or kitchen appliance you hadn’t heard of before but that a lot of people with otherwise similar tastes to you might have chosen happily over some better-known artist or brand-name product. In web 2.0 parlance, this is known as the “network effect” of the “architecture of participation”, which I’ve also written about here before.

In the case of you and I as access points, we’re talking about the difference between an online shop telling you that “people who liked Bonnie Raitt also liked Shelby Lynne” and a social network telling you that “your friend kbacon22 likes Dansko shoes.” In the former, you can find Shelby Lynne’s music if you search for Bonnie Raitt, and vice versa. But in a social network, you can find Dansko if you befriend kbacon22, and vice versa. Everything in the metadata requirements bullet point above for an access point applies here, too:

• it supports discovery - “ooh, new Dansko clogs, thanks kbacon22!”
• it supports relating like items - “oh, I see that kbacon22 likes The Hold Steady, and so does sjparker212.”
• it supports distinguishing between similar items - “oh, kbacon23 can’t be the guy I was in a movie with, because kbacon23 is actually a 27-year-old librarian in Modesto.”

This might be a painfully contrived example, but it’s not that far off from the truth. Recently in facebook (yes, I’ve now logged in a few times), an old college mate I hadn’t spoken with in over a decade befriended me. How did he find me? Our university was the first access point, I’d guess. And then how did he know I was the same guy he’d studied with? Well, that’s easy - my last name is unusual. But if it weren’t, he could, in theory, look at some of my “added entries” to see if I still like the same kind of music we both liked while in college, for one thing, or if we’re still reading the same authors (I think he still has one of my books, actually).

Maybe Facebook will be the social network that finally breaks all the way through to be as mainstream and widely used as major news sites and search engines, or maybe it won’t. But if it does, we’ll all need to get in there, because we’re all main entries for something, and added entries for something else, and if we’re talking about a Facebook For The World then we’ll need all the access points we can get.

Commoditizing the Reverse Supply Chain

There’s a down side to all of this talk of things “social”. As soon as you become an access point, you also become a data point. Make no mistake - Facebook and MySpace wouldn’t still be around if they couldn’t make a lot of money off of each of us, so remember that while your use of these services makes it all seem better for everybody else, the sites’ owners are skimming profit right off the top of that network effect.

One ugly phrase that gets to this truth effectively (which might be what makes so many people react to its ugliness) is “user-generated content.” I know, I don’t like it, either. But what does it really mean?

Do you know about supply chains? If you don’t, look up the term, or if you’re impatient, just think about your car, or your computer. They’re complex products, made of lots of tiny little parts (keys and power window switches) and big parts (screens and bucket seats) alike. Your computer maker and car manufacturers don’t make all those parts - they assemble final products from parts supplied by hundreds-to-thousands of other companies. (Actually, computer assembly is typically outsourced, too.) These other companies - suppliers - could be anywhere in the world, and they might specialize in those parts to the degree that they don’t care where the parts end up, so long as the contracts are lucrative enough. It’s the carmakers’ and computer companies’ jobs to design products in concert with negotiating contracts with suppliers to ensure they can break even on sales after you add up all the costs of individual parts, their transportation, storage, assembly, and final delivery to customers.

The information business mostly works the same way. There are authors, editors, and other creative producers who source, revise, assemble, and deliver products that ship to different markets like readers or libraries or publishers of magazines like this one. In most cases, the money flows back into the information supply chain through advertising dollars, subscription fees, and consumers paying for each item they purchase. Knowledge about who buys what provides feedback to the suppliers, the publishers, and the authors alike so that they can consider how best to reach the buying public with their next product.

What I don’t like about social networks is that they’re also a marketplace for a reverse supply chain. Instead of some pre-packaged information collected, arranged, and assembly for delivery to your doorstep or web browser each day, you (yes, you, in the shiny mirror on the 2006 Time Magazine Man of the Year issue) become both the consumer and the supplier. If you are an access point, then you are a connecting point of critical feedback about products, fashions, and social patterns that the people who make products, fashion, and political movements alike can use to mold their next product lines. You provide the raw materials - your main entry and added entries, lists of who you work with and where you went to school and which musical groups you like and books you read. In turn, the social networking sites become the collectors and assemblers, and they produce packages of information for their old line suppliers - the people who buy ad space, and want you to listen to their new band, or buy their new shoes, or see the new movie starring kbacon22.

What frightens me the most about choosing to become yet another access point in yet another social network is that most people don’t realize just how much money their presence on these networks is worth to the other participants in the supply chain. And there isn’t always an option to withdraw, either - to withdraw money, or your access points. Some systems give you a “delete my account” option, and some, like Facebook, make it clear that even if you “deactivate” your account, they’ll still retain your data.

While some in our industry are fretting over selling out our assets to mass digitization efforts, others are lining up to make themselves yet another commodity in yet another social network-cum-information commodity supply chain. Just like we might not like what happens to our collected resources once well-funded profit-seeking ventures commoditize our cultural heritage, we might not like what happens to the descriptive elements of our own lives in the hands of profit-seeking ventures commoditizing our social heritage. I’m not against anybody making an honest buck out there from a hard day’s work in a harsh world. But how many more times am I going to give so much of myself away?

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

Last month we began to consider what it might mean to build dynamic, instantaneous libraries based solely on the materials held on the computers of people in the same space. That's the goal of this column—to think about what libraries in computers need to look like for them to serve as well as libraries we already know. This month we'll get started thinking about design needs for libraries in computers.

If we were building a physical library, we'd follow some steps you might know well. We'd assess our needs, call for proposals, review bids by architectural firms, pick one, then work with a selected firm to design a space that meets our needs. Maybe you've done this, but I haven't. I have done something similar for software, though, but maybe you haven't. When software design is done well, you end up with something roughly like what you get from an architecture firm—diagrams of boxes and arrows, mocked up screenshots, cost estimates, and a timetable. Fortunately we don't have to worry about time or money here, and we can think of those diagrams and screenshots as pretty much the same thing for software as blueprints are for real buildings. And fortunately for both of us, blueprints are pretty easy to read.

So let's start there, with blueprints. When libraries were being built 100 years ago with Carnegie Foundation funding, one of the things the foundation offered as part of the process was a set of standard blueprints as a suggested starting point. (Jones, T., Carnegie Libraries Across America: A Public Legacy. Preservation Press/Wiley: New York, 1997.) You didn't have to follow them to accept funding, but if you needed a plan, you could start with these blueprints, and many communities did. We could fill a whole conference schedule with debates on what these particular blueprints have meant over time and their relevance today, but there's no debating that these baseline plans affected generations of libraries, library users, and librarians.

Today some of us might have an inkling of what a common design for libraries in computers could look like, but most of us don't. We probably do share a common mental model of the architecture of today's libraries. If you're like me, you probably think it's hard to imagine a library without service desks for reference and circulation, rows and rows of shelving for books, journals, and multimedia, a reading room or area, a reference section with its hefty volumes, separate browsing shelves for popular or newly acquired materials, oddly shaped files for maps, a children's section for a public library or locked stacks in a research library, and so on. There are also offices, public meeting spaces, copy machines, and restrooms—we cannot forget restrooms—a bulletin board, a big stand with a heavy dictionary on it, a daily newspaper section, and some items for sale near the front door.

With all that in place, the only things missing are the catalog, the computers, and the coffee shop.

Connecting the Dots

If that sounds about right to you, then we're definitely starting from the same place. You probably also have a particular library in mind as you think about this—maybe your local public library, or the one you work in, or one you remember from childhood or school. I can't help but think of several different libraries at once, including all of the 10 or so libraries I've known well from childhood on to where I work now. A funny thing starts to happen when I think back through time like that, though. I can almost feel my fingers flipping through catalog cards or spinning the dial on a film reader, and then my eyes can see the green screen of the dial-up terminal, and the color-coded keyboard of a CD-ROM station. Then I remember a lot of meetings about trying to solve problems on the general use public workstations, and then a lot of frustration trying to get wireless to work on laptops. At some point a few years ago that gets easier, and now when I arrive in the library I simply wake my machine up and get to work.

But to focus solely on changing technology is to miss the bigger picture. These lists of what you find in a library and how that's changed over time don't speak to how people move through libraries. Any good set of blueprints should give you a feel for how people will move in, out, between, and around the physical space of a library to get from one section to another.

But even that doesn't necessarily speak to the cognitive wayfinding that library users perform. The best libraries are designed to support the process of finding, studying, questioning, and recombining information. Some of this process requires close examination of individual items, one at a time, from beginning to end. A lot of the process requires making connections, too: You find a book by an author you don't know on the new acquisitions shelf, and before you leave you check to see what else the library has from the same author. Or you're studying politics or economics and you read about a city or region you don't know so you look it up in a map or encyclopedia. Or you get stuck on an obscure reference and ask a librarian for help, and are then led through an online database only to learn that the reference was to a book sitting on a shelf not far from where you first found it mentioned.

The Ultimate Mashup: A Library and Your Brain

These days we can accomplish many of the same tasks with a click through Wikipedia here, a quick look-up at Amazon.com there, and a link to a map server in between. Maybe doing so is qualitatively different from running around back and forth in the physical library to find the same answers to the same questions. Maybe the physical movement and its cognitive affiliation with what you learn and where you learn it builds a stronger mental connection, one that's more likely to "stick" over time. Maybe all these quick clicks lead us to remember where to click quickly, but not to assimilate what we find at the end of the clicks as thoroughly into our brains. Maybe so, but maybe not.

Whether one kind of knowledge acquisition tool chain (bricks and book stacks) is inherently better than the other (clicks and server racks) is also the stuff of academic conferences, and I'm not qualified to judge. Either way, what matters is the ability to make connections. You could spend weeks poring over census records and voting records and old maps, or you could spend days mashing up the same data with the Yahoo! map API, but either way, in the end, you might or might not find an answer to your question, and what you've produced might or might not be helpful to other people.

In a way, then, the function of Amazon.com's book catalog or Yahoo!'s map data in these scenarios is exactly the same as the function of the library book catalog or the library's map file. To me, longevity counts, and although Amazon.com and Yahoo! have been successful, they've only been successful for a few years. If you follow business news at all—or, come to think of it, library vendor news—you know that companies come and go. They swallow and get swallowed by each other on a regular basis. It's easy to imagine this happening with Amazon.com or Yahoo! because it happens all the time. And when it happens, there's no guarantee that services you might have depended upon yesterday will work the same way tomorrow, if at all.

Fleshing Out the Blueprints

What matters, then, in our mental blueprints for libraries in computers, is not just the availability of diverse resources, nor even the ability to connect and combine those resources. What we have to account for is that sometimes things can be expected to stay stable, sometimes they might seem stable but could disappear overnight, and sometimes they might come and go in the blink of an eye but be incredibly useful during that blink.

If we want our computers to act more like libraries, we can't take these dynamics lightly. When 25 people are in a room together and their computers are connected, working together like components of a single library, we know that each of those 25 people might cut his or her own unique path through what is to be found, just like they might in any of our familiar “traditional” libraries. We also know that at any moment, one or 10 or 24 of those people might up and leave, just like our favorite Web site today could become a dot-com memory tomorrow.

I don't mean for this to sound depressing or disheartening. When you design software, or a building, I suppose, one of the first things to account for is which elements will tend to change over time, and how often they will change. In this case we're assessing needs for libraries in computers—dynamic, instantaneous libraries that exist only in our computers and the computers nearby. A central element of our blueprints will just have to be “lots of other computers and the resources they contain coming and going all the time.”

My first exposure to Computers in Libraries was the 2001 conference, when I was on a panel with Roy Tennant and a friendly lawyer. Our topic was peer-to-peer filesharing. I gave a talk on how systems like Napster were really just a natural evolution of interlibrary loan (albeit wherein too many mutations had occurred at once), Roy talked insightfully about how these systems represented “pulsing content” as users and their computers join and leave constantly, and the lawyer graciously advised us all on where Roy and I had misspoken (not often, it turned out!).

Six years later I'm coming to understand just how prescient Roy's phrase was, and remains. Inherent in the Carnegie library program was a requirement that municipalities that received library buildings had to fill their libraries' shelves themselves. The process and outcomes of funding, selecting, purchasing, shelving, circulating, reshelving, and replacing library materials would look different from town to town, and in any single library over time, even back then. I've long thought of libraries as storehouses of great works, rare materials, and a lot of common stuff that comes and goes often. Maybe we've always had some pulsing content, but to build libraries from scratch today, it might help to recognize that all we have is pulsing content.

[Note: the publisher 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 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.

I am now a columnist.

What's *really* cool about this is that I get to be published in the same magazine as Library Web Chic and The Liminal Librarian.

Thanks to InfoToday's liberal licensing policy I've retained numerous rights after a 90-day post-publication window, so I'm collecting it all and plan to republish them down the road a piece. I don't think they'd mind a little tease though, just to introduce the premise. The column is called "Libraries in Computers." (Get it?)

"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?"

With each subsequent column I'm taking this premise apart bit by bit to identify today's technical challenges and recontextualizing them with what we librarians already know. It's a fun way to find angles between hot topics and the little bit of old knowledge I've managed to pick up along the way, and I hope at least a few readers will feel the same way.

Want to read the rest? CiL is available through EBSCOhost, but this new issue doesn't seem to have shown up online quite yet. Reports from home indicate that the paper copy has arrived, though, so if you have a paper subscription you can read it for yourself. Or, stop by your neighborhood library and pick up the print copy, which should be on the shelf already. Or, better yet: buy yourself a copy. :)