SPEC Kit 340: Open Source Software · 29
We plan out sustainability in the same manner as other software implementations and development activities.
We will adopt an enterprise OSS system or component only if it is developed within the narrow range of technologies—
languages and deployment platforms—in which we have expertise and experience, and only if the system or
component is supported by an established, stable community. We follow best practices, particularly around testing and
engineering for stability and scalability, in order to minimize support and maintenance costs. We move support out of
the development group and into a support group (with partial success).
When adopting OSS or engaging in development of OSS, we look for and/or try to establish a broadly-based community
of support in order to mitigate risks of being too dependent on one institution’s/individual’s resource commitment.
Exit Strategy N=15
Data migration is mandatory.
Exit strategy only concerning ability to export all data and relationships from software.
For the eXtensible Catalog (XC), our exit strategy (which we are now implementing) involves moving all infrastructure
support for the software to a library consortium (CARLI) that has been a major partner in developing the system. Our
strategy also has included a detailed communication plan for notifying all stakeholders. We have not deployed XC
locally. For IR+, we are now discussing possible options for future actions that may include a formal exit strategy.
Informal. Must have a reasonable exit strategy. Implementing department is accountable.
Native export tools/XML, etc. unique to each application
No formal exit strategy. We do choose software with open data standards so that our information can be exported on a
whim and used in different software.
Not only with OSS, but with all software systems, we develop such that dependencies are not vendor or product
specific, but could allow for replacement of a part of our infrastructure with a like service without having to redesign the
whole.
Our data adheres to open standard policies, so if we ever need to migrate out or exit out of the OSS, our data would be
compatible with any other system.
The plan will include an exit strategy to allow either end-of-life of the software, or mechanism for turning over software
to other interested parties.
To ensure that our data are portable, we require that an open source software be capable of exporting our data in a
standard data exchange format.
Use of a software system whether OSS or vended requires data export capability.
We always look at an exit strategy when making a decision about a particular technology solution, regardless of
whether it is open source or not.
We keep data and presentation layers separate, so that migration out is easier. We choose OSS with data storage
techniques that allow for complete export of all relevant data in a format for easy migration.
We may resort to a hosted/vended product for our institutional repository if we’re not satisfied with the results of our
pilot project using an open source software repository product.
Previous Page Next Page