42 · Survey Results: Survey Questions and Responses
Flexibility. Low risk in the case of project failure, due to nature of projects chosen. Customizability.
Flexibility in responding to changing needs. Opportunities to look for added value enhancements to services.
Engagement with a wider community of library developers.
Flexibility to customize. Licenses are cost effective. Software easy to require.
Freedom to use, study, copy, modify, and redistribute solutions that work for us. Rapid access to really good ideas by
people who don’t work here with us. Implied membership in development communities.
Functionality that meets our needs. Ability to integrate software into our infrastructure, and with other library and
university systems. Professional development opportunities from participation in the community.
Functionality that was not present in affordable commercial software. Ability to customize to meet our needs. Ability to
integrate with local software.
Greater control of implementation timeframes. Lower up front costs. More flexibility with regard to customization.
Greater flexibility. No similar vended tools. Ability to develop new tools as needed from the OSS system.
Having access to a wide network of support for a system. Participating in a large community of developers with library-
centric OSS expertise. Having more control over features and interfaces.
Improved quality. Customizability. Cross application integration.
Integration with other library systems. Opportunity to test software with little investment low-cost testing/adoption.
Involvement at the national/international level. Can move to another product with no contractual lock-in. Opportunity
to improve the product.
It gives us greater control over the implementation. There can be greater interoperability with OSS systems. The cost is
internal it generally includes staff time and training.
Less staff time to modify and support OSS systems when compared to creating homegrown products. We have better
control over OSS software and our data than we do with vended products. OSS communities tend to have vibrant and
engaged members, which can be a good support resource.
Leverage adoption community support. Attract applied research funding for OSS projects. Align with institute mission to
share knowledge.
Lower acquisition cost. Complete control over user experience and user privacy. Flexibility.
Lower cost. Customizability. More control.
Lower licensing and maintenance cost. Fast deployment. Functionality sharing.
Many choices available. Allows for quick prototyping. Ability to modify to environment.
More options to choose from than just those provided by commercial vendors. Can frequently implement without need
of identifying and budgeting funds to purchase product. Can implement more quickly because there is no need to go
through a complicated and time-consuming licensing process.
No purchase cost. Community support. Flexibility to modify.
No purchase price. More control.
Obtaining functionality that best meets our needs. Control and customizability. Community participation.
Flexibility. Low risk in the case of project failure, due to nature of projects chosen. Customizability.
Flexibility in responding to changing needs. Opportunities to look for added value enhancements to services.
Engagement with a wider community of library developers.
Flexibility to customize. Licenses are cost effective. Software easy to require.
Freedom to use, study, copy, modify, and redistribute solutions that work for us. Rapid access to really good ideas by
people who don’t work here with us. Implied membership in development communities.
Functionality that meets our needs. Ability to integrate software into our infrastructure, and with other library and
university systems. Professional development opportunities from participation in the community.
Functionality that was not present in affordable commercial software. Ability to customize to meet our needs. Ability to
integrate with local software.
Greater control of implementation timeframes. Lower up front costs. More flexibility with regard to customization.
Greater flexibility. No similar vended tools. Ability to develop new tools as needed from the OSS system.
Having access to a wide network of support for a system. Participating in a large community of developers with library-
centric OSS expertise. Having more control over features and interfaces.
Improved quality. Customizability. Cross application integration.
Integration with other library systems. Opportunity to test software with little investment low-cost testing/adoption.
Involvement at the national/international level. Can move to another product with no contractual lock-in. Opportunity
to improve the product.
It gives us greater control over the implementation. There can be greater interoperability with OSS systems. The cost is
internal it generally includes staff time and training.
Less staff time to modify and support OSS systems when compared to creating homegrown products. We have better
control over OSS software and our data than we do with vended products. OSS communities tend to have vibrant and
engaged members, which can be a good support resource.
Leverage adoption community support. Attract applied research funding for OSS projects. Align with institute mission to
share knowledge.
Lower acquisition cost. Complete control over user experience and user privacy. Flexibility.
Lower cost. Customizability. More control.
Lower licensing and maintenance cost. Fast deployment. Functionality sharing.
Many choices available. Allows for quick prototyping. Ability to modify to environment.
More options to choose from than just those provided by commercial vendors. Can frequently implement without need
of identifying and budgeting funds to purchase product. Can implement more quickly because there is no need to go
through a complicated and time-consuming licensing process.
No purchase cost. Community support. Flexibility to modify.
No purchase price. More control.
Obtaining functionality that best meets our needs. Control and customizability. Community participation.
