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 |






















