Draft report of a meeting convened by the Digital Library Federation on October 5-6, 2001 in Washington DC to consider Open Source Software for Libraries

Notes by D Greenstein
October 22, 2001

Present: Dave Bretthauer (University of Connecticut), Rachel Cheng (Wesleyan University), Daniel Chudnov (MIT), David Dorman (Lincoln Trail Libraries System), Jeremy Frumkin (University of Arizona), Daniel Greenstein (DLF), Marilu Goodyear (University of Kansas), Martin Halbert (Emory University), Thom Hickey (OCLC), Eric Lease Morgan (University of Notre Dame), John Ockerbloom (University of Pennsylvania), Victoria Reich (Stanford University), Art Rhyno (University of Windsor), Kyle Fenton (Emory University), Aaron Trehub (University of Illinois at Urbana-Champaign), Beth Warner (University of Kansas), Joan Frye Williams

I. Executive summary

The meeting was convened to consider how to assess various claims made for open-source software and, if appropriate, to identify steps to move OSS activity into the mainstream of digital library development in a manner that might appeal to all sectors of the library community.

The meeting focused almost exclusively on the assessment agenda and accomplished the following:

1. Seven testable hypotheses about open source software and its impact on libraries that might focus some review and assessment
2. Development of a review, assessment, and publication agenda designed to test those hypotheses and to inform decisions about open source that need to be taken by a range of key stakeholders in the library and related communities
3. Specification of a functional requirement for a "library of open source software"
4. Initial contemplation of a development agenda for those interested in open source software for libraries
5. Identification of immediate next steps to accomplish these aims

The report on the meeting is set out under these five heads.

II. Hypotheses

The meeting identified seven testable hypotheses about Open Source Software (hereafter OSS). The first three of these hypotheses (1-3 below) reflect claims made for the economical and functional importance of OSS for libraries and stem directly from the values that OSS developers bring to their work. A further four hypotheses (4-7 below) attempt to explain why OSS development remains in the hands of a few activist developers and is not more a part of the library's mainstream.

1. OSS is an economical alternative to libraries' reliance upon commercially supplied software. That is, despite the real costs involved in the development, maintenance, and use of OSS software but these are lower than those associated with library reliance upon commercial software. Accordingly, OSS economical is not free opens an economical alternative to reliance upon commercial software
2. OSS is essential if libraries are to develop software and systems that meet their patrons' needs. With OSS the IT infrastructure that is essential to library operations and services can be:
   • open (that is, built according to open standards and as such potentially inter operable with other essential software and systems);
   • ubiquitously available to libraries;
   • capable of being tailored to suit the needs and circumstances of individual libraries
   • documented (and documentation must be available); and
   • errors can more effectively be identified and corrected ("many eyeballs make bugs shallow")
3. OSS ensures that library systems and online services will be more functional for libraries and their patrons and as such be good for library patrons. This hypothesis is posited because, through OSS developments, libraries:
   • are reinserted into the research and development process that results in systems and software;
   • share a stake in software development and as such have greater influence over (and as a result take a greater interest in specification of) the functional and performance requirements associated with particular software tools and systems
   • motivate and empower systems librarians and related technical staff by encouraging creativity and positioning them to make a difference; and
   • are able more easily to collaborate with other information science communities involved in common research and development area
4. OSS can lack formal support making it difficult for libraries without significant capacity in their systems department to participate in OSS development or to use OSS.
5. OSS needs to develop a participatory organizational model that allows many to contribute perhaps in different ways to OSS development.
6. OSS is not always easy to use. It is therefore largely inaccessible to the many libraries and library system departments that require plug-and-play software that is well documented and supported and can be easily installed (and uninstalled).
7. OSS initiatives do not always do enough to get non-systems librarians and library patrons involved in design and testing of OSS. As such, they are seen as being something that exclusively offers benefits to and holds interest for library systems staff and not for the wider library community.

III. Research and publication agenda

The group recommended the development of two publications that would test hypotheses developed above and inform decisions about OSS as need to be taken by members of key communities. The aims, objectives, contents, and target audiences of these publications are set out below.

Publication 1. OSS. A critical review and assessment

Aim: To raise awareness about the potential value of OSS and to encourage informed decision making about potential investments in its development and use.

Contents of publication: This publication would

• introduce and define OSS;
• provide a synoptic and annotated inventory (illustrative, perhaps, more than comprehensive) of OSS activity for libraries in the US and abroad, assessing the extent and nature of tat activity;
• include case studies of OSS initiatives (involving different kinds of software and different kinds of libraries) written wherever possible to a common outline that ensures the studies' comparability and their use in assessing costs, benefits, functionality, sustainability, viability of OSS;
• include a critical assessment (based on the inventory, the case studies, and on additional research) of some of the hypotheses stated above about the economic viability and functionality of OSS as an alternative to commercially produced software;
• offer some of the cost-benefit considerations that libraries need to consider when thinking about investing in OSS development/use.

Where appropriate, the study might also review some of the barriers to library's more effective exploitation of OSS and how those barriers might be reduced.

Target audience: The report should be written principally for the following audiences giving preference to library directors and to decision makers and program officers at both federal and philanthropic agencies that invest in libraries, digital libraries, and mechanisms that support scholarly communications

• library directors (including directors from libraries with both large and highly constrained IT budgets),
• decision makers and program officers at both federal and philanthropic agencies that invest in libraries, digital library, mechanisms that support scholarly communications, etc
• CIOs (e.g. in large public libraries, but also in institutions such as universities which host libraries and where CIOs may manage appropriate R&D budgets and staff)
• officers and lead participants in library consortia (particularly where those consortia are responsible for operational systems)
• reference and other librarians who are affected by but not party too the strategic, tactical, and operational decisions made in library systems departments
• library system vendors
• a general professional audience and readership such as that targeted by library professional associations

Possible development process: The background, inventory, and assessment could be commissioned from a single author, while case studies could be commissioned from a variety of authors as appropriate. In order to ensure the study was written for and responsive to the interests and needs of its target audience, it might be developed in consultation with an advisory or editorial board.

Publication venue: The study should be published by a creditable journal or organization such as Library Trends, CLIR/DLF, etc.

Publication 2. OSS. An introduction for systems librarians

Aim: To support informed decision making about OSS by library systems and other technical staff who are involved in the day-to-day development or management of operational IT services in or for libraries.

Content of publication: The report should:

• Include an introduction defining open source, offering a synoptic assessment of OSS activity to date for libraries in the US a and indicating why systems librarians should take an interest in OSS developments
• Review the issues that need to be considered within a library systems department that is thinking about implementing OSS tools or getting involved in OSS development (including technical, funding, human resource, managerial issues)
• Review of good practice in development, documentation, and licensing OSS and with regard to participation in OSS development processes
• Review of next steps for departments wishing to get more involved with OSS

Target audience: The report should be written principally for:

• programmers/developers, other information scientists and software and system developers
• library system vendors
• professional schools and other agencies from which systems librarians are recruited

Production process: to be resolved

Publication venue: a creditable publisher of similar texts

IV. An OSS Library or Portal

The group identified the potential value of an OSS library or portal service

• to assist in the identification and review of OSS for libraries and support in informed decision-making as pertaining to its application and use and
• to lower some of the barriers that currently impede the more effective development and exploitation of OSS for libraries.

As a library, the service might maintain an organized catalog of selected and consistently documented persistent and accessible OSS for libraries. In addition, it could:

• maintain a list (formally or otherwise) of OSS for library development projects. In this respect it would be a repository of projects as well as of products;
• support an open review and feedback mechanism whereby library users could review, provide feedback about, develop case studies arising from their use of catalogued OSS;
• provide a mapping between software systems and tools including in that mapping both open source and commercial systems and tools. With such a mapping, a user would be able to identify and then assess the various tools capable to supplying a particular function or functions;
• act as a broker able to match institution's specific human resource needs (e.g. for people able to supply or install particular tools) with the qualified people able to meet them and to marry programmers to development projects;
• provide access to general information (e.g. about the costs and benefits involved in using OSS, about criteria that may be used to assess OSS) and pointers to related information resources; and
• encourage good practice, e.g. with respect to licensing arrangements, documentation, etc).

In these several capacities the OSS library or portal could:

• provide an inventory of OSS;
• act as a clearinghouse for information about OSS that may assist in its identification, location, assessment, access; and
• lower the barriers for libraries in identifying, assessing and possible using/developing OSS

In addition, the library or portal's very existence could supply a number of vital functions almost as byproducts. Use of the library or portal would:

• help to document trends in library software development, notably in the kinds of software tools and systems libraries;
• incubate and facilitate the development of selected OSS projects;
• encourage informed decision-making about OSS licensing;
• inform (identify need for further) OSS development work;
• support attempts to articulate system and service functions required by libraries;
• support standards development work as appropriate to integration of library software and systems (whether of OSS or commercial origins)

Remaining questions as yet to be resolved

• What selection criteria should be employed by such a library or portal (software would have to be accessible, persistent, applicable to use in libraries, etc)?
• What level of support would a portal supply to whom and for what software tools?
• What documentation should be associated with catalogued OSS - what subset of documentation (if any) should be required; what should remain optional. Here, it was noted that the exemplar of a good free software listing site (one that could be used by those interested in OSS for libraries). The freshmeat model basically supplies project name, project description, version history (announcement text, dates), names of one or two authors, link to project page, link to download page, link to change-log, link to binary/source download, link to alternate/mirror page, descriptive categorization, screenshot. In a follow-up communication, a participant noted the importance to OSS assessment of consistent documentation, suggesting that consistent documentation may preferably fit within a known documentation format and may include
  • problem statement
  • project background
    • narrative history
    • changelog
    • license
    • credits
  • protocol/spec/standard references
  • install how-to
    • requirements/dependencies
    • platform variations
  • administration guide
  • operating tasks
  • user guide or help subsystem
  • subsystem documentation (e.g. data model/dictionary, scripting guide)
  • to-do list (unfinished tasks)
  • how to help list (we need help doing X, Y, Z)
  • wishlist (blue-sky would be nice if la dee da...)
  • mailing list archives
• What template, if any, should be recommended for reviews and feedback in order, for example, to encourage comparability

V. OSS research and development agenda

Recognizing the likelihood that much OSS would support specific library functions, the group focused on the requirements for integrating these tools in any library environment. Although no concrete research agenda emerged, emphasis was given to the following:

• standards required to integrate software tools in a library systems environment with particular focus on APIs
• common understanding of digital library systems architecture and the formal systems relationship between component modules of that architecture
• identification of and possible concentration on the system functions and tools that libraries require but that are least likely to be supplied (or supplied well or effectively) commercially
• conduct a piece of survey research into licensing terms used with OSS with a view to developing a model license agreement (the work of Liblicense might be used as a model)

VI. Next steps

1. Discuss the meeting and its outcomes with stakeholders who may have an interest in and might wish to participate in some way in the review, assessment, and publications, activities contemplated above in section 2. Candidates for consultation include representatives from Educause, CNI, ARL, NLM, IMLS, NSF, Mellon, the Urban Library Council, the Oberlin Group, ICOLC.
2. Identify, in part through that discussion, support for and authors of relevant component parts of those activities
3. Work on the repository might be conducted along a parallel track. Alternatively, it might be formed by the review, assessment, and publications effort that could in effect act to develop a feasibility study for such a repository
4. Participants also agreed to undertake specific actions, for example to initiate development of a prototype portal, develop content appropriate to the research and publication agenda, explore outreach and awareness-raising opportunities e.g. at the ALA conference in summer 2002

return to top >>