Open Source Software in Libraries

Library Hi Tech News

ISSN: 0741-9058

Article publication date: 1 May 2001

612

Citation

Bretthauer, D. (2001), "Open Source Software in Libraries", Library Hi Tech News, Vol. 18 No. 5. https://doi.org/10.1108/lhtn.2001.23918eaf.002

Publisher

:

Emerald Group Publishing Limited

Copyright © 2001, MCB UP Limited


Open Source Software in Libraries

David Bretthauer

Open Source Software represents an exciting opportunity for libraries. Rather than forcing a library to depend on products which may not fully meet its needs, open source allows that library to participate directly in the development of its systems and innovate services in a manner consistent with the values of librarianship.

The ubiquitous presence of the Internet, powerful desktop PCs, a variety of standards, licenses which protect open source code, and a large and thriving open source community outside the library world have made open source system development possible. It is now relatively easy for a library to develop an in-house solution to a problem, share it with the outside world, and reap the benefits by allowing others to contribute improvements and additions to that solution.

Overview of Open Source

Open Source Software represents a major shift in software design. The traditional software design model, employed by most commercial software vendors, consists of small, tightly focused teams developing source code. Once this source code is compiled it becomes the commercial package which consumers buy, whether it's a word processor or an integrated library system. Usually the source code is proprietary and consumers cannot view it legally. While this model allows the original developers complete control over a product, consumers often find that the product cannot be customized to fully meet needs, and developers sometimes are ineffective at fixing bugs in a timely manner.

By contrast, the open source software development model usually starts as a volunteer project. In it, any interested party, usually communicating via the Internet, may participate in the development of a package. The source code, rather than hidden, is freely available to anyone. Likewise, the final product is freely available, although most licenses under which the software is developed allow individuals or companies to distribute and support the software at a profit as well. The advantage is that, with many people reviewing the source code, bugs are spotted and fixed more easily, or "Given enough eyeballs, all bugs are shallow" (Raymond, 1999a). As a result, mature open source software is usually much more stable and reliable than similar commercial, closed source software. Linux users, for example, regularly joke about the instability of commercial operating systems.

On its face, the open source concept may seem similar to the idealistic and even naïve in-house software development, which took place in several large libraries during the 1970s and 1980s, but there are significant differences. Home-grown software tended to be developed in isolated pockets to solve individual needs. This forced each library to have significant technical expertise in-house. But because this work addressed only an individual need in an individual institution, the work often could not easily be transferred to or shared with other institutions. By contrast, open source software offers several improvements:

It is developed by a process very similar to the peer review process successfully used for generations throughout academe, and specifically to strengthen the process of scholarly communication.

Several very successful software packages, including many that make the Internet and the World Wide Web work, such as Apache and Sendmail, were developed and are maintained using this model.

Companies such as RedHat are able to make a profit, selling and supporting open source software.

The best known license agreement for open source software is the GNU General Public License. Others include the PERL Artistic License and the BSD License; there is a list of such licenses at http://www.opensource.org/ These licenses are intended to protect the source code from ever becoming proprietary, while at the same time allowing authors and other contributors to make a profit distributing and supporting software.

The Open Source model ­ which has as a central notion that information should be freely shared ­ has functioned effectively in the computer science world for more than 15 years. This is thanks to the vision and effort of such people as Richard Stallman and his Free Software Foundation (see http://www.fsf.org/). This model is culturally quite similar to the values embodied in libraries, from Interlibrary Loan to the development and use of the MARC record. Until recently, libraries were limited to using packages such as the Apache Web server, which were developed outside the library world. Now a number of librarians with programming and system development skills are entering the profession. Some of these individuals are developing packages, using these license agreements, for development with, and use by, other libraries.

Library Solutions

Dan Chudnov maintains an excellent compendium of open source packages designed by library staff specifically for use in libraries: http://www.oss4lib.org/projects/ It includes course reserve packages, an online document delivery module for use with Ariel, Z39.50 servers, library portals, and many software tools for manipulating MARC records. There is even a functional integrated library system, Koha, as well as several others under development. Perhaps the best-known library open source projects to date ­ Prospero, a program which complements Ariel 2; Jake, a journal finding aid; and MyLibrary, a library-specific portal development package ­ are all included at this site.

In addition, a number of professional organizations are starting to recognize open source in a formal way. The LITA Open Source Systems Interest Group, NERCOMP, and affiliate of EDUCAUSE, and the several ASIS chapters have all sponsored programs on open source software for use in libraries.

To try using any of the packages listed at oss4lib, all that is needed is a computer, an Internet connection, and some staff time and expertise. Some products work under various Microsoft Windows operating systems, while others require some version of UNIX (including open source variants of UNIX such as Linux and FreeBSD). Hardware three to four years old or newer is likely to be sufficient for testing purposes and limited produc-tion use. Generally, a 100-133MHz Pentium, with a network card, 32MB of RAM or more and a 2-4GB hard drive will do for a start. Any product or service which a library deems useful and necessary, however, will need a commitment of new hardware in order to be reliable.

Of course, there are some drawbacks. While the only direct cost of Open Source software is for the hardware and Internet connection, the software is not really free, unless you have unused Pentium computers and possibly a staff member with Unix expertise and free time. Staff expertise is not easy to develop or to find in many libraries. Open source operating systems ­ Linux, FreeBSD, OpenBSD, and NetBSD ­ all resemble commercial Unix, with its complexity, unfamiliarity to Windows users, and potential for security problems. It takes time to experiment and learn, and it would be wise to invest in some staff training. However, complexity, security and training are concerns in the use of any network-connected server operating system, whether it is Linux, a commercial Unix such as Solaris, Windows NT or 2000, or MacOS.

On the other hand, if you have or are willing to develop these resources, which many libraries will need to do anyway, it takes much less time to experiment with an open source package which addresses a need you have than to develop your own solution from scratch.

Related to this challenge is the reality that system development, including programming, is only starting to become a core competency for librarians. As a result there are a limited number of librarians and library staff involved in development of open source tools for libraries. Compared with the large open source community, which may have a local interest group (perhaps even one meeting regularly in your library's public meeting facility), the library-specific open source community is presently minuscule. In a way this is a benefit, since "no one should ever have to solve a problem twice" (Raymond, 1999b). But it also means that librarians involved in open source development need to be aware of, and in sync with, the larger open source community. Regular checks of sites such as Freshmeat (http://www. freshmeat.net) and Slashdot (http://slashdot.org) can accomplish this.

Another drawback is outside technical support, if open source packages are limited to listservs devoted to the package you are using. Often, this support is very good, as package developers have strong personal commitments to seeing their software work. At times this support is equal or even superior to technical support provided for commercial products. But the fact remains that there is no 800 number to call in emergencies. On the other hand, if the software works well, there is no annual maintenance fee to budget for.

While not a drawback, there is another issue to consider: the attraction of being able to reuse old PCs can make one forget that old PCs can break down, and are not likely to be covered by warranty or service contract. If a package works for your institution in testing, it is wise to budget for new hardware before using it in production. The last thing anyone wants is to lose a semester's worth of online course reserves, because a four-year-old hard drive with no backup fails.

Contributing either your own time, or the time of your staff or other resources, to an open source project accomplishes several good things.

It means that you are contributing towards technology, which solves a problem for your own library and others, and will not become unavailable either through obsolescence or through product and/or license withdrawal. Remember that a key problem with any proprietary software is that it's only available as long as the license owner chooses to make it so. A commercial vendor of a proprietary closed source product can withdraw that product, discontinue its support, go out of business, and/or can be acquired by another vendor who can do any of the above. Such a vendor can also corner a market segment and raise the price of a product to the extent that it is practically unavailable. Any such action can render a library's previous investment worthless.

Another benefit of open source technology is that it has a tendency to push innovation. Several ILS vendors are beginning to offer portals, seemingly in response to products such as MyLibrary, and the next version of Ariel will include the functionality developed in Prospero. Undaunted, Prospero's author has learned that several institutions have found other uses for the software, and intends to produce further versions of it (Schnell, 2001).

Finally, as is the case with publication or any gift culture, contributing to an open source product, which works and is freely available to the library community, reflects well on the contributing institution. Indeed, institutions that hire the talented, conscientious individuals who develop open source tools can truly find open source a win-win situation. Not only does the individual have the enjoyment of pride of ownership in solving a problem ­ and the pride of contributing a solution to many other libraries ­ but the institution has a significant opportunity to attract and retain talented staff.

David Bretthauer (dave.bretthauer@uconn.edu), is Network Services Librarian, University of Connecticut, Storrs.

References

Raymond, E.S. (1999a), "The cathedral and the bazaar", The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, O'Reilly, Sebastopol, CA, p. 41.

Raymond, E.S. (1999b), "How to become a hacker", The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, O'Reilly, Sebastopol, CA, p. 234.

Schnell, E. (2001), "Ariel 3.0 and Prospero functionality", 24 January, Arie-LARIE-L@listserv.boisestate.edu http://www.escribe.com/library/ariel/m2994.html March 14.

Related articles