Library Journal Mobile
Log In  |  Register          Free Newsletter Subscription
Subscribe to LJ Magazine

Buy, Borrow, or Build

Karen Coombs says libraries have a new option for updating their systems: borrow existing code and improve it

By Karen Coombs -- netConnect, 10/15/2007

Librarians can meet their systems needs in three ways: buy, borrow, or build. Most libraries are very familiar with the buy option, since it entails licensing a piece of software to perform desired functions. Many librarians rely on this model for meeting most of their technology needs, particularly when it comes to choosing an integrated library system. This approach offers several advantages.

First, it shifts the development burden outside of the library, which helps preserve limited resources. Second, depending on how many user licenses you purchase, buying a system can also shift support and maintenance outside your doors. Another potential advantage is that, by purchasing a system, you can get it up and running more quickly than if your library built it internally.

Even with these advantages, buying has several downsides, notably your level of control. When you buy a system, you rely on a vendor to make changes, fix bugs, and add functionality. If something doesn’t work right or the way you prefer, you often have to wait for the next release for things to get fixed.

Be a borrower

The second option is to borrow, which is often accomplished by using open source software. In this scenario, a library implements a moderately stable piece of open source software to meet its needs. It may even modify the software. However, the library really doesn’t contribute to the developer community for the product.

This is a great option for libraries constrained by a fixed budget and limited technical staff. These software packages are quite easy to install. Open source software can also be customized and extended if you have staff with programming skills, though this can take time and may not be so simple. Also, it is important to help staffers understand that many open source packages are far from perfect and that it may take some time to adapt the software.

Build your own

The third option is to build it yourself. This can be a variation on open source, where the library creates a piece of software and makes it available for others to adapt. It also can create a local system that the library chooses not to share with the world. Years ago, many libraries followed this option, with unpleasant repercussions when it came time for migration. Indeed, several larger libraries had to abandon their homegrown integrated library systems.

Thus, the open source flavor of the build option is much more desirable. By making a piece of software available as open source, a community of developers can grow around it and lift the support burden from a single insititution. However, as Oregon State University, Corvallis, has discovered with its LibraryFind project (www.libraryfind.org), this doesn’t happen overnight [see Digital Libraries, LJ 10/15/07, p. 23]. Besides spreading the development burden, building it yourself gives you more flexibility in the underlying system architecture as well as other features and functionality.

If you build a system, you can draw on the knowledge of your existing staff. While this is possible through borrowing and adapting existing systems, you may or may not find a system to suit your needs that is written in a programming language familiar to your employees. Building a system also may meet more of your functional requirements. However, it takes time and energy—and you have to maintain the code for security holes and bugs.

At the University of Houston, we use all these methods together. We buy our integrated library system, OpenURL resolver, and survey software. We borrow open source systems like MediaWiki to run our wikis, Archon to create our Archival Finding Aids, and LibraryFind for federated search. And we build things inhouse, including our content management system.

This approach lets libraries draw on their organizational and personnel strengths. It also spreads out the systems support burden, since running all home-built systems requires a huge number of people. By combining all three methodologies, you can create a stronger library, with a flexible systems environment that can quickly respond to changes in technology.


Author Information
Karen Coombs (librarywebchic@gmail.com) is Head of Web Services, University of Houston Libraries, TX

Talkback

We would love your feedback!

Post a comment

» VIEW ALL TALKBACK THREADS

Related Content

Related Content

 

By This Author

There are no other articles written by this author.

Sponsored Links




 
Advertisement
Sponsored Links

More Content

  • Blogs
  • Podcasts
  • Photos

Blogs


Sorry, no blogs are active for this topic.

» VIEW ALL BLOGS RSS

Photos

  • Design Institute 2007
    December 11, 2007 at Chicago's Harold Washington Library Center:Design Institute 2007
  • Learning Gardens
    New York's GreenBranches program links the library to the street.
  • Green Picks: LBD May 2007
    Want to reduce your library's carbon footprint? Join the Cradle-to-Cradle revolution. Helen Milling shares the green products her firm is using.
Advertisements





LJ NEWSLETTERS

Click on a title below to learn more.

LJ BookSmack
LJXPRESS
LJ ACADEMIC NEWSWIRE
LJ REVIEW ALERT
CRÍTICAS
©2009 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy
Please visit these other Reed Business sites