Decision Support Tools

From Code4Lib
Jump to: navigation, search


LYRASIS is seeking to engage consultants to create decision support tools in the form of whitepapers, self-guided assessments, and worksheets (collectively “Tools”) for libraries considering open source software. This work is funded by a grant from the Andrew W. Mellon Foundation to help libraries of all types determine if open source software is right for them, and what combination of software, hosting, training, and consulting works for their situation. These Tools are to be paired with a software registry to become a community exchange point and stimulant for growth of the library open source ecosystem by connecting libraries with projects, service providers, and events.

Appendix A to this document describes the Tools to be created. Prior to the response due date I will send questions and answers about the Tools to all who are interested; if you have questions or would like to register to receive questions/answers, please contact me. Responses are due by close-of-business on Tuesday, September 6th, sent by e-mail to, and include the bulleted elements below.

  • The topic of the Tool from the statement of work to be covered
  • An overview of your expertise in this area (between 400 and 600 words)
  • A firm price to complete the work described (note that the tools will not require an equal amount of effort, and consequently an equal price, to complete)
  • A writing sample on a similar topic

Consultants may submit responses for more than one Tool; only one Tool per consultant will be awarded. Incomplete responses may not be considered, and selection criteria will include cost, review of experience and review of the writing sample. Selected consultants will be notified on or before Wednesday, September 9.

I will be the contact for this project (; 678-235-2955). I am looking forward to reviewing your proposal.



Appendix A: Statement of Work and Fee Schedule


The objective of this work is providing to libraries whitepapers, self-guided assessments, and worksheets (collectively “Tools”) to guide them in determining whether open source software is right for their environments. The completed Tools will be turned into web pages and published for libraries to use royalty-free along with the open source software registry now under development.


  • Submit a draft outline by Friday, September 23, 2011.
  • Submit final version by Friday, October 14, 2011.
  • Review posted HTML version between October 31 and November 4 (estimated).


In responding to this statement of work, consultants should supply a fixed cost to complete the creation of the Tool. Payment will be made on this schedule:

15% Signature of contract
60% Receipt of final version
25% Completion of review of HTML version as posted on the website

Intellectual Property

In accordance with the Mellon Foundation Intellectual Property Agreement, consultants must assign LYRASIS the copyright of all works created under contract. LYRASIS must in turn publish the tools on a website with a royalty-free license. Consultants may elect to identify themselves in the text of the document (e.g. “Prepared for LYRASIS with funding from the 2011-2012 Mellon Foundation Open Source Support Grant by name of consultant.”)


The Tools will be converted to HTML and stored on a Drupal-based website (the same website that will host the open source software registry). If there are Drupal 7 modules that would enhance the use of the Tool, please contact LYRASIS early in the writing process to ensure the modules can be supported.

Consultants are not expected to work from LYRASIS’ offices in Atlanta, GA. Office space and network connections can be provided in LYRASIS’ Atlanta offices after negotiation with LYRASIS. Key LYRASIS staff on this project will be available via Skype video conferencing or regular phone conferencing. Discussions and knowledge transfer can occur using LYRASIS’ Centra Saba or Adobe Connect online meeting service.

Description of Tool Topics

Control versus Responsibility

In a blog post on, Thomas Gapinski describes a two dimensional matrix into which he places self-hosted and closed/open-source solutions to determine where an organization places its technology systems. Along one axis is a “Responsibility” gauge, with organizations that desire more flexibility trending towards self-hosted systems and organizations that do not tending towards Software as a Service installations. Along the other axis is the “Control” gauge, with organizations desiring less control trending towards closed source software and organizations desiring more control towards open source software.

This tool will ask questions of the library to determine where on these two axes it wants to place the desired system and show graphically the quadrant its answers place it. This tool can be used to determine an organization’s desire to adopt an open source software system and whether they have the capabilities of running it in-house or whether the services of a hosting provider will be needed.

Questions for Parent IT Organization

A library may not have the inherent capabilities to run its own systems and may rely on an external information technology organization (e.g., campus IT, city government IT, contracted service provider). This tool would contain questions to ask that parent/external organization, such as:

  • The desired system depends on a community of users for support and bug fixes. Resolving issues may result in extended interactions with volunteers running the same software. How will the parent IT organization ensure sufficient community engagement to resolve issues?
  • The open source software that end-users use usually depends on other open source components. For example, a content management system will use MySQL or PostgreSQL as a database rather than Oracle or DB/2. The known dependencies are xxx, yyy and zzz. Will the parent IT organization support these open source dependencies or will it try to make it work with proprietary counterparts (and understand that such a configuration may be out of the community support mainstream)?

Although intended as a tool for libraries to explore general requirements for open source software with a parent IT organization, it may also be useful as a self-examination tool for libraries that will host/support their own systems.

Costs for Open Source Software

Open source software is not free. While there will not be costs to license and use the code, costs shift to other areas – typically to areas where open source software is weaker as compared to proprietary offerings. The Decision factors for open source software procurement document from the U.K. Open Source Software Advisory Service describes the kinds of costs that are traditionally unique to open source software. The Software Pluralism document says the total cost of ownership may be analyzed in terms of the following aspects in evaluating open source adoption:

  • Acquisition costs. This category primarily includes sale price and other sales-related costs.
  • Deployment costs. To implement open source solutions, systematic deployments such as planning, installation, migration, testing, monitoring, etc., need to be in place. The budgets for these processes are components of the total cost of ownership.
  • Staffing costs. The category includes costs in hiring, training, new payrolls, etc., in relation to the adoption of open source systems.
  • Support and services. Professional consulting costs fall in this category.
  • Opportunity costs. The decision to choose open source instead of proprietary solutions might miss the benefits of some offerings in proprietary systems.

This tool will be a worksheet that has columns for costs specific to proprietary solutions (e.g. software licensing), costs specific to open source solutions, and costs in common. It will also include a way to account for costs of self-hosting and Software as a Service. Along with a companion guide that gives definitions and sample benchmarks for each cost item, a library can use the spreadsheet to estimate the total cost of ownership of various options it is considering.

Technology Skills Matrix

As a library decides how and when to bring in new hosted software, one important factor to consider is the underlying technologies used by the software and how those technologies mesh with the skills of the library staff. At LYRASIS we have used a “technology skills matrix” tool where on one dimension is the array of possible technologies and on the other is the software packages under consideration.

The horizontal dimension of this table is broken up into three main parts: programming language, operating system, and database management system. The vertical dimension lists the packages currently in use and/or under consideration. If a package uses a technology, a mark is placed at the intersection of the package and the technology. At a glance, one can see what technologies are used in common across all packages.

Another version of this tool can list individual staff members rather than software packages to gain a visual understanding of how skills are distributed among the library staff. Each additional option added to the library’s environment across the horizontal dimension brings more complexity and a higher cost to retain staff with these multiple talents. Another version of this tool can list individual staff members rather than software packages to gain a visual understanding of how skills are distributed among the library staff. This matrix helps a library identify its strengths and position new projects as having strong or weak synergies with existing skills within the library.

This tool will contain questions needed for a library’s self-assessment of available skills and needed skills. It will prompt libraries to think about all aspects of hosting open source software – including dependencies that may be hidden from view

Software Selection

The grant text lists a number of criteria that can be used to select the software that is right for a particular library’s desires and circumstances (features, usability, scalability, documentation, upgrade frequency, customization, maintenance requirements, community adoption levels, system support needs, and security). They are similar to the informal Top tips for selecting open source software from the U.K. Open Source Software Advisory Service. Tristan Müller suggests a more formal methodology in "How to Choose an Free and Open Source Integrated Library System" (published on OCLC Systems & Services: International digital library perspectives. Vol. 27, no. 1, 2011, pp. 57- 78). Wikipedia also lists several open source software assessment methodologies for consideration.

Given all of these options, this tool will be a document describing a software evaluation methodology that takes into account unique aspects of the library sector and the need to review the sustainability of open source software projects