There is a side of library 2.0 that wants people not only to write and push “publish” but also to be enthusiastic about it, and eventually to learn more. Yes, even going so far as understanding more complicated things like XML, PHP, & server maintenance.

Of course different folks will take different trajectories on their learning curve. . . some may get into really effective journalizing, or pro-level photography and/or film editing. But my impression has always been that library 2.0 is about continuous learning. The blog is merely one avenue toward that end.

So must you be techie to get your library to thrive in the social web? Not at all. In fact, my experience shows me that the more a techie gets wrapped up in the tools, the more he loses sight of the social environment.

Before this, the prominent bloggers and users of L2.0 were techie sorts and had to be. They understood the tools and understood that these tools would bring new attitudes – but they had to get the rest of the library world understanding the new tools before the new attitudes would flow.

The tech tools are what enables things like “crafting and modifying library provided services” and someone on the library staff needs to know the tech tools out there to be able to say no to proprietary software.

In the production phase, you do not need to be techie to:
*understand the need for Library 2.0
*ensure there are staffing and resources to serve our customers in this way
*to be a front line worker delivering service using Library 2.0 tools (eg. writing blog posts).

A year ago, Library 2.0 was similar to the time way, way back, when I was in a library demonstrating the internet to the executives in my parent organisation. I did need to be techie – I had to bring in my modem from home, know how to use trumpet winsock and how to create a sample html page etc. I would rather have just “used the stuff” than know how to set it up – but to get the resources to use the stuff, I had to know how to run it – there was no-one else in the organisation able to.

This has been similar with many Library 2.0 services – to get tools that enable conversations with our users, get them appreciated by other library staff, get a “proof of concept” happening, there is a lot of techiness involved in both setup and education. We’d rather just use it, but for many of us, knowing how it works underneath and how to stop it falling over is essential if we are going to get our colleagues using it with confidence.

In your blogging example I think you have left out a layer, which is where many of us work and it is about technology. For an internal library blog, for example, you install the blog software, set up a template, use hex code to determine the colour scheme, add items to a sidebar, get a feedburner feed, maybe a sitemeter, set up the .htaccess file so that it can only be read by a certain IP range.

Yes, we’d all rather Jane from IT did this bit, but in many organisations, there is no Jane and for us it is about knowing more techie stuff than we want to just so we can get the services up and running so that someone eventually employs a Jane.

I’d say it’s a miracle if the library does it; as in a library is not a “them.”

So, where exactly is the difference between someone with tech skills at a library doing it versus someone with tech skills at a vendor doing it?

I have no doubt you can find one. When you do, that might be where a difference lies. Perhaps.

If the 2.0 goal is connecting and empowering users then why exactly does it matter whether it is done by library personnel or simply bought by library personnel?

If we assume that formula for a full-featured OPAC is reasonable (and I will for the sake of argument), then it is irrelevant as to its “techiness” whether it is created in the library or bought. I would argue that it matters in other ways (local support, having tech qualified staff, …), but who creates it is irrelevant to whether or not it is a tech skill to create it. It simply is.

But again, if a library can do it (or anything at all) I’m calling it a miracle.