For the purposes of this project, we examined forty projects, some of which were taken from Library Labs on RSS4Lib (www.rss4lib.com/library-labs), and some of which we found through additional research. Thirty-one were in four-year college or university libraries, one in a community college, five in public libraries, two in special libraries, and one at a government library. These are projects that are explicitly called “Library Labs” or something similar, and most of them are modeled on either Vanderbilt’s Test Pilot page or the Ohio State University’s Library Labs. The vast majority of labs identified as such are located in university libraries. Some great examples of such projects include the Harvard Library Innovation Laboratory at Harvard Law School and North Carolina State University Library’s Digital Initiatives Department. While these institutions are fortunate enough to have whole teams of research programmers, they also release their code to the public so other libraries can replicate their projects.

We suspect many more library types are involved in structured experimentation with new tools, and we hope that more libraries will make their culture of innovation more apparent. For instance, the Oak Park (Illinois) Public Library has a program called “Spark!” that invites volunteers from the community to devote two hours a week to help plan the future of the library, particularly in areas surrounding new technology. The Orange County (Florida) Library System created a blog called Orange Seed Ideas (http://blog.ocls.info/orangeseed) specifically for tracking cultural trends and their applicability to libraries. They came up with creative names for the different stages of their projects like “seedlings” and “germinate.” Some of their recent projects include using QR codes to promote library card registration and purchasing an “Egg Bot” as a cheaper alternative to 3D printers. Neither of these libraries call their projects a “lab,” but these are still experimental and community-building plans for creating innovation in the library. We count these as labs.

You may have an idea of what an institutional “culture of innovation” looks like but feel it is out of your grasp due to time and financial limitations. We want to lay out some ideas, sources, and examples to help you realize that your own attitude and your institution’s attitude creates change, not specific resources.

A wonderful source on this culture of innovation is the white paper “Think Like a Startup” by Brian Mathews.¹ He provides a lot of the theoretical background that is useful for the practical components we will discuss later. He uses a very applicable metaphor that we “have to peer upwards and outwards through telescopes, not downwards into microscopes.”² The point is not about simply modifying existing services; it is about big things like paradigm shifts, transformation, and anticipating and adapting to the future.

A recent OCLC Innovation Symposium featured content from several innovative libraries, including the Fayetteville (New York) Free Library. In 2011, they purchased a Makerbot for 3D printing. For them, establishing a culture of innovation was about challenging assumptions and breaking barriers. If you are undecided about a potential project, ask yourself, “Why not?” Do not assume you know what your community wants or needs. Before starting their Fab Lab, Fayetteville spent time identifying what the barriers to innovation were—funding, decision makers, space, staff time, etc.—to see what was getting in the way of moving ideas forward.

Also included in the Innovation Symposium was Josh Hadro from Library Journal discussing his experience on the Great Library Roadshow, a road trip especially designed for finding innovation in libraries. He noticed that none of the libraries he visited thought they were being innovative because they could always point to someone who was doing something bigger and better. Do not let this mindset keep you from trying new things.³

Libraries can learn lessons about how to run flexible and transparent organizations that are sensitive to the needs of their communities from the open-source software community. Distributed volunteers participating in self-made and -governed communities have created systems we use every day. This is not an easy idea to overlay on traditional libraries, but as the examples above suggest, it is possible. It is cheap to try, and requires little training because the idea is to figure out how to solve problems as a community. Probably most challenging for many librarians is that success requires that you forget preconceived ideas about who is “allowed” to do what. One of the greatest things we can learn from open-source software is that people who have an idea and want to do the work are the people who get the work done. What if those people lack the MLS degree? What if they are students or retirees? They should still be able to try. Governance for Apache projects (such as the Apache web server) is based on the “lazy consensus” model.⁴ In this model, if you have an idea for a feature, you present it to the group. If after a few days no one has any objections, you can go ahead and start working on it. If someone does object, you can revise your proposal to answer his or her objections, but the default answer is “yes.” A rule of improvisational comedy is that you always answer “yes” when confronted with a new idea in a scene. This openness to new ideas helps to foster innovation.

You may feel that the only thing you share with the open-source software movement is the predicament of having to get everything done with no budget. In libraries we are often asked to build the plane as we fly it or patch together things with nonoptimal solutions. This often creates moments of panic when circumstances reveal the tenuous character of such solutions. That panic and frustration can provide a moment of clarity to create something better.

Take the case of Google’s acquisition of Meebo Messenger in the summer of 2012. Many libraries relied on Meebo as a free and easy tool for providing chat reference service even as they admitted that it was not always the best solution. In the period during which libraries scrambled to find a new solution, many librarians articulated the value of chat reference and that it had become a central service. This allowed them to make a case for using a low-cost commercial service such as LibraryH3lp or provided motivation to seek out and implement a potentially more fitting free solution.

A wonderful example of the positive effects of doing more with less was the experience of Bowling Green State University and a project headed by Gwen Evans.⁵ In 2007 Bowling Green found they were unable to hire a web developer, but they also wanted to build new tools that would take advantage of the social web. They had a difficult choice: forgo innovation and attempt to work with an already-overstretched main campus IT, or try something new. They tried something new: they hired students who were studying computer science to help build applications. This was a risk, certainly, but the project ended up being successful and lasted some years.

Let’s get into the specifics of the basic requirements for a library lab (with or without a team of research programmers). To have a library lab, you do not need to be tech-savvy. You need only have curiosity about new technology and openness to new ideas. If you work at a library that is perpetually understaffed and underfunded, you may have a list of tools or techniques you read about or saw at a conference but no time to check them out and a nagging worry that you cannot afford them anyway. These are good candidates to put in lab.

A somewhat different but related scenario you might have is that you work at a large or multisite library (or perhaps at a branch of a larger university or city library system). There may be a team of research programmers working on interesting projects. You might consider how you could participate in their work even if you are not technically skilled enough to work on the coding aspects. Find out if they need help with documentation, marketing, or getting community involvement.

You will need a platform to display and invite user feedback. We saw that many of the platforms we looked at use some type of blog to talk about the projects. It could be a freestanding blog or other page, or it could be part of your already existing library blog. We would suggest the latter, since we found that many of the freestanding library lab pages eventually fell into disuse. When you find the right venue, keep it fresh. Have a place for potential projects, research in progress, graduated and implemented projects, and “graveyard” projects. That way people will know what is a new tool and what has “graduated” from the labs and is part of regular services. LibGuides is a useful platform for a lab, since it has many social components built in already.

You also need to decide what support you can offer for testing—for instance, some tools will need to be installed on a server. Do you have access to a server for the library? Do you have expertise in installing software on the server? (Many tools are easy to install even if you are technically inexperienced.) Talk to your IT department to find out your library’s current capabilities. If the software you want only runs on Linux and you only have Windows servers available, you will not be able to run it on your servers. Such situations should not stop you from testing—you can rent server space very inexpensively these days. Many universities and other entities are moving more of their server resources off-site anyway, so you might be able to take advantage of this at your library.

A word about working with your information technology department: it is all too common to hear the complaint “my IT department always says no.” This is not an attitude that will lead to success. Think about how you as a librarian feel when you are asked to buy or support something for which you do not have clear motivations or resource allocation. To implement a technical solution requires a very clear idea and plan for costs, timeline, support dependencies, installation difficulties, upgrade needs, and so on. When you can account for these, it will make your request easier to say “yes” to. Of course, some of these questions you cannot answer until you have begun testing the solution. For certain tools, your lab research may consist at first of researching how you would implement it before you actually attempt to do so.

Part of planning your library lab is understanding how you will get your community involved and (hopefully) excited. Obviously, this depends on your community, so you are the expert. At our prior institution, we were fortunate enough to have a library science graduate program with plenty of potential volunteers. You might have a dedicated student worker who is thinking about library school. Or you may have to be a little more creative. If you are a public library, is there a community college or technical school nearby with students looking for real-world experience? Maybe one of your volunteers is more tech-savvy than you think. By involving your community, you take the guesswork out of what your users want and need. Maybe you are experimenting with video games for your teens. Having a serious gamer in your lab might help you make better decisions about programming or which new game to preorder.

Regardless of where you get them, having volunteers from the other side of the reference desk is going to help your project. David Weinberger has discussed a new business model that relies on a “network of expertise.”⁶ You are not using volunteer labor as a fallback solution, you are relying on their skills and expertise. Nevertheless, since different people may not have the skills a particular project requires, we suggest you rank projects based on the amount and type of skill necessary so volunteers can suggest something they can manage. Some volunteers need a lot of structure and reminders, others will not. You may find some are unable to complete the work or fully participate, just as you would with any group of volunteers. Consider however, that this may tell you more about how appealing the tool you are testing is as about how reliable the volunteer is.

Give people autonomy and trust that they can handle the work. In general, if they were not interested in learning they would not have volunteered. You will get better work from people that way. Research shows that work done for intrinsic rewards is better than extrinsic rewards. Nevertheless, make sure you are clear about expectations for the quality of work. For instance, have an editing time built in to edit volunteer work. Be sure that you do not give volunteers access to sensitive patron information. You may ask them to do a literature review or look at some examples rather than actually accessing library systems.

Remember, you are working in a laboratory environment so you can see what works for your community and what does not. Think of your forays into emerging technology as a process of elimination. Because you are working with new tools or projects, there may not be an established record of how they perform or what is their appropriate audience.

For example, maybe you have a lab assistant set up a browser toolbar that you have been hearing about, only to look at your analytics and realize that very few people in your library use that particular browser. If you document your efforts, those few people who do use that browser can still benefit, but you have not spent too much time pushing a tool that is not going to be used. Moreover, you have provided your lab assistant, often a student, with an opportunity to build skills in that area.

Having a lab is about the process, not the final product. Quality control does not need to be your first priority. Your community will appreciate being able to use these new tools sooner rather than later, even if they are still in beta testing. It can be difficult to predict which tools will catch on and which will not, but having projects that reflect current trends will keep you relevant in the eyes of your community.

That said, here are a few things to keep in mind as you decide what should leave the lab and become part of regular library services. What resources do you have? Does this tool make your life easier or harder? Can it fit into existing workflows? Do not do things just because they are free. Plan that if something is a good solution that you will pay for it eventually, even if abstractly. Staff time will go into maintenance, for instance. Do not assume that you will always have a volunteer interested in working on a tool. Perhaps one of the most useful things your dedicated volunteers can do is to carefully document how to use the tool from both a staff and a user perspective.

An example from our own library lab is that of Pinterest. Many libraries were creating Pinterest accounts, so we wanted to determine whether we should do so. A volunteer spent some time researching uses for Pinterest in libraries, and we saw some good examples of how it could be used. Ultimately, however, we determined that it would not fit into our existing social media workflows and was unlikely to be used effectively. A great solution to this realization was not to create our own Pinterest account, but to participate in the university’s account instead.

Libraries have always been offering opportunities for innovation, partly because libraries have always had bigger ambitions than budgets. Any librarian can and should be paying attention to the tools that make their work better and their patrons’ lives easier, whether or not emerging technologies is in his or her job description. There may be uncertainty in experimentation, but we hope the library lab eases some of the challenges that can come from keeping up with technology.