History of the Project

Evergreen, a project that took over three and a half years from concept to implementation, is an ongoing effort to create the best open-source integrated library system (ILS) available. Tired of being a small voice in a large crowd and having virtually no input into how its ILS was configured and improved, the Georgia Public Library Service decided to create its own ILS for its member libraries. GPLS wanted flexibility and an OPAC that responded to how users access information. It wanted to build something with which it could give better service. By making the Evergreen project an open-source endeavor from the beginning, GPLS capitalized on existing open-source communities and interested library technology people to create a supportive community that helped the work at all stages of the process and made the code available for other libraries to use.

Interview

with the Evergreen Project Team led by Elizabeth McKinney de Garcia, PINES Program Director

What was the estimated amount of time the project took to go from the planning process to launch?

It took about 18 months to decide to pursue creating an open-source integrated library system; once we arrived at the decision to develop our own integrated library system, planning and development took a little over two years. We began by holding a series of forums around the state, talking with PINES libraries (and others in the library community) about the open-source development process. We followed the forums with 10 focus groups; these were held around the state, and were designed to collect data from our customers (+/– 2500 public library staff and members of the library community) about how the software should work. Focus groups took place during the summer of 2004. The go-live date for our libraries using the Evergreen software was September 5, 2006.

Initially folks had trouble thinking outside of what existing/known software was capable of doing. In order to get past this, one of our developers came up with a phrase that was useful: “Pretend it is magic.” This meant to forget about what you know about what software can or cannot do, and tell us how you really want it to work. That phrase helped folks to really use their imagination in thinking about the possibilities for an entirely new product. As a result, we have wonderful ideas to enhance the software for several years to come.

About how many people were involved in the project? Were these people geographically in different places? Where were they?

The PINES staff led development of the software. Our staff includes 9 FTE [full-time-equivalent staff members], including a development group of four programmers. Although the developers were located in the Atlanta area, they attended every focus group and listened to feedback from throughout the state. An open-source community quickly developed around Evergreen that included hundreds of interested participants from around the world. In addition, library staff from around the state of Georgia participated in reviewing and testing the software throughout the development process.

What, if any, technology or tools did you use to communicate, plan, and execute your project? Please explain briefly why each tool was chosen.

The PINES staff, the open-source community, and the Georgia library community are scattered across the state and around the world. The main mechanism for communication was through e-mail and discussion groups. The Open-ILS discussion groups included all three of these groups. Holding discussions by this mechanism was an excellent way of working and sharing ideas across a very large population of participants. Developer blogs posted on the Web site, www.open-ils.org, were very helpful in keeping everyone (PINES libraries and other interested libraries from all over the world) informed during the development process. The project itself uses a wiki for documentation. The developers were featured as keynote speakers for the 2006 Code4Lib Conference via webcast.

Did any of the people participating require any training on the technology you used during your work process? If there was no training offered, was there a learning curve that you observed? If there was no learning curve, would you say that the people involved in the project were fairly proficient with technology?

We did not find that anyone needed training to use e-mail or the discussion groups. There was practically no learning curve needed for downloading, installing, and logging into our demo and development servers. Some explanation was needed in order to test and review features of the software simply because it was a new way of working. Once folks understood how to navigate and use toolbars initially, the rest came naturally. It was similar for editing the wiki.

Do you feel the technology changed your planning, work, or interaction on the project? How?

There would be no way possible to convene meetings of all interested parties without great trouble or expense, so the use of technology was essential in facilitating the planning, work, and testing of the software.

Would you chose to do anything different with the experience behind you? For instance, would you have chosen different tools, utilized the tools you did choose differently, or used more or less technology?

I don't think we would choose any different tool or another technology. We approached the problem with an iterative approach, trying different tools and methods until we found a solution that fit well. If something didn't work, it was quickly discarded. On the other hand, this method did lead to some rather unorthodox utilizations of technologies. For example, the use of Jabber (an IM protocol) on the back-end network. While it makes perfect sense to use IM to have servers “talk” to each other (that's what IM is for, isn't it?), it's a somewhat unorthodox utilization of the technology; in my opinion. I think we're very happy with what we have, but we're always making tweaks.

The Future of Evergreen

GPLS has formed a partnership with the University of Windsor for the development of an acquisitions/serials control module that is particularly important to the academic library community. The GPLS staff is exploring development partnerships of Evergreen in many library settings with libraries in the United States, Canada, and other countries.

Recent mergers, acquisitions, and significant management changes in the U.S. library automation marketplace have been cause for concern in libraries, and the Evergreen project has received a great deal of interest from public, academic, research, and school libraries seeking an alternative to proprietary vendor solutions. Instability and uncertainty about vendor products and directions have sent librarians seeking a new path that results in the flexibility to grow and change as quickly as the information world is changing. Evergreen represents an attractive, viable option for libraries wishing to take a larger role in shaping the primary software that drives critical library operations.

While Evergreen is proven in a successful production environment, plans for the next phases of development and enhancement proceed. The development of acquisitions and serials control modules are currently well underway, and the GPLS staff is working with academic and public library systems, consortia, and provincewide library associations to identify strategies and partnerships to move Evergreen forward. Such features as academic reserves, equipment booking, and a wide array of social networking options for the public catalog are being discussed and planned. The exploration of partnerships for the continued development and enhancement of Evergreen is an exciting prospect.

At the time of writing, the University of Windsor (Windsor, Ontario) and several libraries in the province of British Columbia planned to implement Evergreen software during 2007. The British Columbia implementations are the first steps in an ambitious five-year plan to migrate multi-type libraries across the province to Evergreen.

Positive publicity for Evergreen is spreading rapidly across the country and internationally, with feature-length articles appearing in a number of print and online journals, including American Libraries, Library Journal, Smart Libraries, Library Technology, Quill & Quire (the Canadian equivalent of Publisher's Weekly), Panlibus (a quarterly magazine published in Birmingham, England), The Digital Librarian, and Linux Librarian. Evergreen was featured in national presentations at the American Library Association annual conference in Washington, DC, in June 2007, and will be a featured program at the Public Library Association conference in March 2008 in Minneapolis.

Lessons to Learn from Evergreen/PINES

• Dream big when designing a new service: “What if it was magic?” If you could answer that question, what would you say when designing a new service? Sometimes in the early stages of the planning process, the constraints (time, money, and staff resources) should not be considered too strongly. Develop a proposal for the optimum service, and then see if you can create the service with the resources you have. Creative thinking can solve some, though not all, resource issues.
• If something does not work, try something else. Even if the application of a tool is unconventional, if it works for you, then the application is right.

History of the Project

LibraryFind is a metasearch or federated-search tool built by Oregon State University Libraries with funding from OSU and the Oregon State Library. OSU wanted to build an open-source tool that worked the way federated search was meant to work. It wanted more consistency and less lag time between the entering of the search query and the return of results.¹ LibraryFind has a built-in open URL resolver that allows the user to look for an item and find it within two clicks. LibraryFind is built on Ruby on Rails and allows for local indexing of collections, Web-based administration of the tool, a caching of searches for a quicker return, and a customizable user interface. You can view the development page for LibraryFind on the trac wiki listed in the gray box.

LibraryFind trac wiki https://trac.library.oregonstate.edu/projects/libraryfind

Interview

with Jeremy Frumkin, Gray Family Chair for Innovative Library Services at Oregon State University

What was the estimated amount of time the project took to go from the planning process to launch?

It took approximately 4 months for our first php-based version to go live here at OSU. For our initial Ruby on Rails version, it took about a year. After we had completed the php version, we stepped back to examine where we were and how we architected LF [LibraryFind], and chose to move over to Ruby on Rails to address long-term development and sustainability issues, as well as providing a more structured framework within which a team of programmers could collaborate and develop.

About how many people were involved in the project? Were these people geographically in different places? Where were they?

We have had one person work primarily on the back-end of LF and one person work on the user interface. In addition, we contracted for a half-time developer for a year to help on all aspects of the software. Our contractor was located on the east coast, and our user interface developer started out locally, but moved to Seattle during the course of the project, where she still works on LF. In addition to our developers, our Unix/Linux sysadmin has devoted a good deal of time to administrating LF, particularly in learning the details of Ruby-on-Rails webserver setup and deployment.

What, if any, technology or tools did you use to communicate, plan, and execute your project? Please explain briefly why each tool was chosen.

We used a few different tools. Initially, we had free access to an online collaboration tool called Breeze (an Adobe product, I believe)—this allowed us to hold meetings where we had voice, video, and screen presentation capabilities, as well as collaborative whiteboarding and document editing. Eventually, our free access to Breeze ended, and we migrated over to using Skype for our weekly meetings, and Campfire, an online chatroom service from 37 Signals. Skype was software that most of the team already used, and it provided us the ability for both voice and video communication. Campfire was chosen because it was relatively inexpensive, and it allowed us to communicate and capture our written conversations. Campfire is also browser-based, so all we had to do to use it was to point our browsers to the correct URL.

Did any of the people participating require any training on the technology you used during your work process? If there was no training offered, was there a learning curve that you observed? If there was no learning curve, would you say that the people involved in the project were fairly proficient with technology?

The people involved in this project are all proficient with technology, so no training was needed.

Do you feel the technology changed your planning, work, or interaction on the project? How?

The technology allowed our project to include members who were (and still are) geographically dispersed. While we still come together for semi-regular face-to-face meetings (every 3–4 months), we are able to meet and communicate using the combination of VOIP w/webcam, the Campfire chatroom, and our internal discussion list. In addition, we utilize trac, a ticket-based project management system for communicating code changes and additions, as well as to keep track of our development timeline.

Would you choose to do anything different with the experience behind you? For instance, would you have chosen different tools, utilized the tools you did choose differently, or used more or less technology?

This is difficult to say. While the technology does allow us to work from various geographic areas, with a small group of our size, it is still probably more effective to be physically located in the same area. However, the technology does allow us to work proficiently without the physical proximity, and it works well enough to meet our communication needs. There are still some inconsistencies, mostly due to bandwidth, with adding video to our VOIP chat, but other than that, we are happy with the technologies we have employed.

Is there anything else you would to add?

It is interesting to note that ten years ago, working in this manner would have been much more difficult and probably not feasible.

The Future of LibraryFind

At the time of publication, only two libraries have instituted LibraryFind, Oregon State Libraries and University of Houston Libraries. Both of these libraries are large public universities. The software, LibraryFind, has been downloaded over 2,000 times since its release, so it is possible that other libraries are experimenting with it. In the future, it is hoped that some public and other types of libraries will look to LibraryFind as a search tool solution.

Lessons to Learn from LibraryFind

• The LibraryFind team is continually working to improve the tool they have created. One of the lessons to learn from Web 2.0 is that our tools and services should always be evolving into something better to serve our users.
• Library Find also utilized members that were geographically dispersed and kept the team productive. They engaged each other through the use of a variety of tools, including face-to-face meetings. Variety is important to remember because not all mediums will appeal to everyone.

History of the Project

MatDL stands for “Material Digital Library Pathway.” It is part of the National Science Digital Library, and it provides a clearinghouse of materials related to the study of material science. MatDL was created for undergraduate and graduate students, educators, and researchers. It includes a repository of information from government-funded research projects, teaching materials, and archives; a wiki dedicated to soft matter; and a place for the development of simulation and modeling tools.

Interview

with Kathy Lowe and Laura Bartolo, College of Arts and Sciences at Kent State University

What was the estimated amount of time the project took to go from the planning process to launch?

The overall project began as part of the National Science Digital Library (NSDL) in September 2003 with the Materials Digital Library collection project. The project became the NSDL Materials Digital Library Pathway in September 2005. A central repository system was launched in September 2004 and remained in place for approximately 2 yrs until a different repository system was implemented. Within the 1st year of the Pathway project, two collaborative tools were launched:

1. The MatDL wiki portal (http://matdl.org/matdlwiki/index.php/Main_Page) and Soft Matter wiki (http://matdl.org/matdlwiki/index.php/softmatter:Main_Page), which provides a publicly accessible, expert-community-driven site for scientific communication and dissemination in support of materials research and learning with emphasis on the sub-domain of soft matter
2. MatForge (http://matforge.org/), a workspace for collaborative development of modeling and simulation software.

About how many people were involved in the project? Were these people geographically in different places? Where were they?

There are currently 9 PIs and SIs directly involved in the MatDL Pathway project along with 8 staff, undergrad students, and grad students. Project members are very geographically disbursed (e.g. OH, MI, MA, MD, IN, IA).

For The MatDL wiki portal and Soft Matter wiki, ∼40 people (researchers/faculty, grad students, undergrads) are actively involved in this facet of the project (MI, NJ, MA, NY, IL).

For MatForge, ∼45 researchers/faculty & graduate students (MD, PA, CA, MI, MA) are currently participating.

Did any of the people participating require any training on the technology you used during your work process? If there was no training offered, was there a learning curve that you observed? If there was no learning curve, would you say that the people involved in the project were fairly proficient with technology?

For The MatDL wiki portal and Soft Matter wiki, informal training and supporting documentation was offered to the researchers/faculty and grad students, who are very proficient with technology. Since the undergrads' level of proficiency was more of an unknown, one formal training session was conducted either in person or via conference call, and more support was made available.

For MatForge, informal training and supporting documentation were offered to the researchers and grad students, who are very proficient with technology.

Do you feel the technology changed your planning, work, or interaction on the project? How?

Various technologies are integral to the MatDL project. Collaborative tools are changing the way people work, making the process more accessible and interactive. These tools allow a comprehensive view of the work throughout the development process rather than just a “finished product.” The importance of controlling who can view the work at a given point in time varies by project.

Would you choose to do anything different with the experience behind you? For instance, would you have chosen different tools, utilized the tools you did choose differently, or used more or less technology?

Our project is still ongoing. The tools that we have chosen are currently meeting our needs.

The Future of MatDL

MatDL is a continually expanding clearinghouse of information. It currently has four main areas: Research Experience for Undergraduates, a Repository of Soft Materials, the National Institute of Standards and Technology, and the Materials Teaching Archive. With a huge team working on the success of this project from six different organizations, MatDL will continue to be an indispensable resource.

Lessons to Learn from MatDL

• MatDL is built by the experts who utilize the information, and they learn from each other for their teaching and research. When building tools for users, participation from the users is essential. Libraries should be willing to give up more control over some content in order to utilize the rich knowledge base of the experts in our user community.
• The team working on MatDL also understood that sometimes you need tools that control who can see what and when they can see it. Transparency is a good thing, but sometimes tools with a built-in security process are needed if the project is sensitive. Many tools come with the option of keeping content private, protecting information behind a password, or publishing it wholesale on the Internet. Each team and group leader should decide what is best for their particular project.

History of the Project

MyHamilton is a community portal for Hamilton, Ontario. Several local organizations, including Hamilton Public Library and McMaster University Library, are involved in this project. The project started in June 2001 when local support was rallied, user needs were assessed, and the technology options for portals were examined. In July 2003, Hamilton was awarded the funds needed to build the community portal. With funding secured, MyHamilton issued a request for proposals for vendors interested in building the portal needed, and the vendors began work in April 2004.

This project is notable because it involved people from many different organizations and backgrounds and because of the way MyHamilton was marketed. The project was high tech, involving many different city systems, but the advertising involved more mainstream efforts, such as billboards and bookmarks.

Interview

With Paul Takala, Manager Electronic Service, and Kit Darling, Director Information Technology and Bibliographic Services

What was the estimated amount of time the project took to go from the planning process to launch?

MyHamilton was a complex project that took a lot of planning and involved several partner organizations. Its development can be divided into 2 distinct stages:

• Stage 1: Development of Business Case and Acquiring Funding: 2 Years (June 2001–July 2003) The Hamilton Team spent 2 years developing a detailed business case and attracting local support for the initiative. During this process, business processes were studied, user needs were analyzed, and portal technology options were investigated. The culmination of this work was the submission of a business plan to our provincial government. We applied to the Connect Ontario program, which was offering communities up to $1 million in matching funds to develop a comprehensive community portal that would promote economic development, enhance community capacity, and move us towards being a “Smart Community.” Our business plan was submitted in March 2003, and we were approved for up to $1 million CDN in matching funding by the Ontario government in July of 2003.
• Stage 2: Technology Acquisition and Implementation of Portal: 2 Years (August 2003–September 2005) Building on the work of the business plan, once funding was secured, a formal procurement process was initiated. A detailed RFP was issued in November 2003. The successful vendors were awarded the work in April of 2004. During implementation, efforts were made to gain a better understanding of user needs and to ensure the site in development was adequately testing. More information was gathered by: subject matter expert interviews, card sorting exercises to determine appropriate information architecture, in the final stages we did task-based testing on a live prototype. Numerous meetings with stakeholders were held to address policy and strategic issues.

Note: Our project took 4 years because we needed significant capital investment to ensure the portal would include a lot of integration with legacy systems that our municipal government was using. We learned during our investigations that a lot of vendors have experience building portals, but few vendors had a lot of proven success integrating with back-end government and library applications.

About how many people were involved in the project? Were these people geographically in different places? Where were they?

The development of MyHamilton involved the work of many people from many different organizations. Prior to launch we have counted at least 45 local organizations that had staff involved in some way in the portal. The people involved were from Hamilton, Ontario, but often from organizations with very different cultures.

Because the Hamilton Public Library and the City of Hamilton fully integrated their sites into the portal, staff from these 2 organizations made up the bulk of local participation. Community participation in the project included significant contributions of time, effort, and expertise by numerous volunteers from other local organizations such as: McMaster University, Mohawk College, the Chamber of Commerce, the Hamilton Conservation Authority, our local FreeNet, the Community Information Centers, and several other not-for-profits in our community.

We involved outside expertise in helping us select the right technology. Involving input from McMaster University and Mohawk College, for example, in our formal RFP process ensured we were able to take to City Council a sound recommendation that was backed up by outside objective expertise.

What, if any, technology or tools did you use to communicate, plan, and execute your project? Please explain briefly why each tool was chosen.

During implementation we made extensive use of a Web-based collaboration space. This enabled us to keep all members of the Steering Committee and other team members up-to-date on plans without e-mailing massive documents. Having a Web-based tool was critical because participants came from several organizations. Early in the implementation stage, we got our vendor to provide a hosted version of the collaboration tools (MS SharePoint) we were installing locally as part of the portal. This enabled team members to become familiar with the technology and assisted with finalizing our requirements for the local installation.

Because the project was very complex, we developed extensive project plans, and for this we used MS Project. This assisted us with tracking the progress of several teams and with communicating progress to our stakeholders.

To promote the portal at launch, we went for a decidedly low-tech approach to reach out to the community. Some of the tactics we employed to promote the portal included: outdoor billboards strategically located on busy streets; we partnered with our local professional football team, the Hamilton Tigercats, and launched the portal at one of their home games; we distributed 600 MyHamilton T-shirts, 300 MyHamilton baseball caps and created 20,000 MyHamilton postcards and 10,000 MyHamilton bookmarks; we were also able to attract good local media coverage.

Did any of the people participating require any training on the technology you used during your work process? If there was no training offered, was there a learning curve that you observed? If there was no learning curve, would you say that the people involved in the project were fairly proficient with technology?

Many of the participants required some help learning how to use the project collaboration space. Demonstrations were provided at meetings, and we developed very detailed specific instructions.

The level of proficiency varied considerably. We also learned that it is important not to use every tool just because you have it. We decided to push the envelope and experiment with online voting, discussion forums, and online task management assignment. While some of these experiments were successful, some participants did not like having to learn to use new tools.

Do you feel the technology changed your planning, work, or interaction on the project? How?

The technology, particularly the use of a Web-based collaboration space, assisted us with achieving transparency. It enabled all the partners, whether internal to the city network or not, to have access to the all the critical documentation as it was being developed. In addition to transparency, the collaboration tools enabled us to gather input in an effective way. For example, during our user acceptance testing (UAT) stage we had over 30 people involved in testing different components and features. We had the participants post their input directly in a custom online database. As the project team resolved issues, we posted updates directly into the same system. We resolved over 400 issues that were raised in UAT using this system.

Would you choose to do anything different with the experience behind you? For instance, would you have chosen different tools, utilized the tools you did choose differently, or used more or less technology?

The project was a tremendous learning experience that has enabled the library to demonstrate expertise and develop new skills in staff.

In retrospect, we would do things differently now because the world has changed a lot since we started the project in 2001. Given the great Web 2.0 sites that are available now, our next portal needs to integrate with these sites by pushing our information out in ways that work for users, as well as enable users to integrate their content with our portal. We do not need to nor can we recreate YouTube or Flickr; rather we need to figure out how our portal can best work with these sites.

Another point is, given the proliferation of open-source solutions and standards to enable effective integration; we need to look differently at how we move forward. As Mark Leggott argues, We need to look at our catalogue and portal as “Lego bricks”(http://www.lib.unb.ca/APLA/docs/LibraryAsOpenSource.pdf).

Instead of engaging in a massive application that solves all our needs, we need to build more organically. Projects of this size take a very long time, and by the time the project is completed so much has changed.

Is there anything else you would to add?

One of the library's goals was to empower non-technical staff to create and post their own content and to deliver their services. We have achieved this goal successfully. Staff members have embraced the concept with enthusiasm but are realizing that the effort of sustaining their information and services on the portal requires a review of service priorities and of staff work flow. We are also still struggling with the need for overall editorial control and quality assurance, made much more complex by the distributed model of content creation.

The Future of MyHamilton

The team behind MyHamilton is looking for ways to make the second-generation portal more successful than the first. An open-source project and the integration of Web 2.0 tools are some of the ideas that they have considered. In order for the MyHamilton project to continue to grow, staff time and use will have to be re-evaluated

Lessons to Learn from MyHamilton

• The MyHamilton team realizes that for a project that is ongoing or will continue to grow over time, open-source is a wonderful option. Having a community that will support the development of your project will make it more sustainable.
• Staff are encouraged by the trust that comes with management empowering them to create their own content for their organization's Web presence.

History of the Project

Scriblio started as WPopac, an OPAC built on the WordPress platform, an idea created in the mind of Casey Bisson. WordPress is an open-source blogging tool that is highly customizable and has a very large development community supporting it. In an interview with Karen Schneider of ALA TechSource, Bisson said that he knew libraries needed something that was accessible to everyone and that looking outside of the traditional library systems was the key to success.² Bisson used his library, at Plymouth State University, as the testing bed for his project. He built a prototype catalog on the back of WordPress that allowed better management and manipulation of materials data, but, like any good Web 2.0 tool, allowed participation from users as well. In December 2006, Plymouth State University was awarded a $50,000 Technology Collaboration Award from the Andrew W. Mellon Foundation to continue work on Scriblio.³

Interview

with Casey Bisson

What was the estimated amount of time the project took to go from the planning process to launch?

Scriblio started without any planning and without any management approval. I started working on it on my nights and weekends in late 2005 and had a working prototype by the beginning of the year after putting in less than 100 hours of work on it. I begged some help here and there from friends (MySQL optimization from Zach Tirrell, XHTML microformatting from Matt Batchelder), but overall it was low impact in terms of the human and technical resources I had to muster.

The project has grown since then and now involves more people and a lot more time and equipment.

About how many people were involved in the project? Were these people geographically in different places? Where were they?

I can't begin to count the number of people involved with the project, but I definitely need to call out a few people for their efforts. Lichen Rancourt worked to bring our first public library on board and helped shape the project early on, Jay Rancourt is the director of that first public library, Jessamyn West kick-started our documentation efforts, Jon Link designed the default theme, and Randall Hoyt designed the logo. We also have a great team here at Plymouth, and I get a lot of help and management oversight from David Beronä, Chris Williams, and Dwight Fischer.

Only a few of these folks are here at Plymouth, the rest are clustered mostly in New England.

What, if any, technology or tools did you use to communicate, plan, and execute your project? Please explain briefly why each tool was chosen.

The most important technologies in terms of the development and coding of Scriblio are LAMP: Linux, Apache, MySQL, PHP. Each of those open-source tools is free and has an active community, including the WordPress project on which Scriblio is based. That free-ness was important in getting things started, because I can't imagine trying to get approval for the project before I'd been able to start building it and prove it could be done.

Did any of the people participating require any training on the technology you used during your work process? If there was no training offered, was there a learning curve that you observed? If there was no learning curve, would you say that the people involved in the project were fairly proficient with technology?

Jay Rancourt, the library director at Tamworth Public Library, isn't afraid of technology, but she was new to a number of the applications we were using. Lichen introduced her to blogging, tagging, and IMing, among other things. She's working independently now, training her staff to use the software, and has no hesitation about IMing me with questions.

Google Docs (formerly Writely) were new to us all not long ago, but we've been quick to adopt them, especially within the management team.

Do you feel the technology changed your planning, work, or interaction on the project? How?

The project probably would never have gone beyond Plymouth without IM; it was really an enabling tool to communicate across geography. It's hard to describe how IM differs from a phone call, but that's the difference that makes it work.

The Future of Scriblio

Scriblio is currently being used by the Cook Memorial Library in Tamworth, New Hampshire; Beyond Brown Paper, a photo archive at the Brown Manufacturing Company in New Hampshire; and Lampson Library at Plymouth State University. The future of Scriblio is defined only by the ability of the developers and libraries to dream of the OPAC they have always wanted. As an open-source tool, Scriblio could take many different directions, which are limited only by the imagination and coding ability of the community built around this tool. As the team that is building Scriblio grows and as more libraries use the power of Scriblio, this project will continue to grow and impact the way we think about library catalogs.

Lessons to Learn from Scriblio

• The simplest tools, such as IM, are sometimes your biggest ally. Never underestimate the power of a tiny tool.
• Libraries should not be afraid to look outside of the library world to solve our problems. Especially when confronted with an entrenched issue, sometimes the best solution comes from the last place we would expect.