Decision Support Tools

As part of the Mellon Foundation grant funding the start-up of LYRASIS Technology Services, LTS is to produce a series of tools that enable libraries to decide whether open source is right for their environments. The grant says:

Identify useful tools that can support decision-making and create free, web-based versions for library self-use. Tools will enable libraries to look at products (open source or not) from the library requirement perspective as well as product functionality. Readiness assessment tools will assist libraries in evaluating local conditions to assess what resources exist or are needed to acquire, adopt, and support open source products. Selection tools will provide a structure for looking at such factors as usability, scalability, documentation, upgrade frequency, customization, maintenance requirements, community adoption levels, system support needs, and security in addition to product features. Existing models for assessing business requirements and readiness for other software applications will be used as a starting point for developing readiness assessment and selection tools for open source library products. The tools will be developed by staff and consultants, and tested/vetted with members and/or experts.

What follows is my description of the kinds of tools that will initially fall into this area. After review by the Advisory Panel, statements of work will be drafted for consultants to create these tools and the work will be let out for contract. The completed tools will be turned into web documents in the form of whitepapers, checklists, spreadsheets, etc., and published along with the open source software registry now under development. To encourage consultants to share their knowledge, we are considering allowing consultants 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.”)

With this background in mind, answers to these questions would be helpful:

• Based on your experience and/or knowledge of open source software adoption, are there other tools or techniques that would be useful to document and make available?
• Do you have suggestions for consultants to approach to complete the work of creating these tools?

In a blog post on Motionbuzz.com, 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.

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 document would contain questions to ask that 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 with 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 document 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.

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 document will be a spreadsheet 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.

As a library decides to 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. This matrix helps a library identify its strengths and position new projects as having strong or weak synergies with existing skills within the library.

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. 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, we will commission a consultant to create 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.