SPEC Kit 340: Open Source Software · 47
Staff time. Lack of support. Lack of clear documentation.
Support for changes, bug fixes is dependent upon user community. Future development can be taken in a different
direction than desired, or stopped completely. Learning curve in the organization for production implementation &
support after development. Not all open source software is documented well.
The main supporting group provides poor support or abandons the software. Dependence on technologies that are not
well known within the library. Ability to both customize the system and track future releases.
Time to deploy. Compatibility among modules. Lack of documentation.
Total cost of ownership can be higher. Replacement of knowledge when staff involved in OSS project leaves. More
difficult to justify investment in OSS over vended solution in face of budget cuts/constraints.
Transition plans for stranded (abandoned) OOS systems. In-house resources to support and extend OSS system hard to
cultivate. Upgrade cycles are resource-intensive.
Trial and error approach is sometime necessary: need to have a tolerance for failure. Lack of community support at
times. Development takes time.
Understanding features and capabilities of OSS now and in the future so we do requirements analysis and trial
implementation. OSS can’t be included as part of a formal RFP process: no strategy to overcome. Understanding the
total cost of ownership for OSS: no strategy to overcome.
Unplanned costs associated with maintaining and customizing the code.
Variable level of support from the community, especially with older versions. Strategy: upgrade often! Sometimes
missing one or two key features that are beyond the library’s ability to develop in-house. Strategy: contract out to third
parties. Greater staff time required to support. Strategy: ensure staff know the system thoroughly.
We locally customized one system and are a bit stuck with our fork now, but it’s a tradeoff we manage just fine. Very
good modern software tools often don’t fit our legacy data; e.g., django requires utf8 db connections but Voyager
WordPress is not supported by our parent institution (university), so if we lost our in-library webmaster we would have
LIBRARY CONTRIBUTIONS TO OSS PROJECTS
18. Has your library contributed to any library-related OSS projects (either your own or another
organization’s project) in any way (e.g., code or developer time, money, hosting)? N=72
Yes 56 78%
No 16 22%
If you answered Yes, you will continue to additional questions about your library’s contributions to
If you answered No, you will skip to the section Additional Comments.