44 · Survey Results: Survey Questions and Responses
Adopting open source software isn’t free. There are support costs. We schedule regular maintenance of our software.
Some vendors have more resources and can be quicker to market to meet a need or respond to changing environment.
To deal with this, we always keep our options open to swapping pieces between OSS and vended solutions.
Although we try to minimize support costs through good engineering, we nevertheless have to support the applications.
We move most application support to a support group after deployment, but some support issues require developer
attention, taking time away from development efforts on other projects. The time to deployment can be long depending
on the level of development or customization we undertake.
Bad software. Bad documentation. Too much staff time needed to get application running.
Bugs
Change in mindset on part of technical staff to contribute to open source communities.
Changing code: careful tracking of changes. Pressure to always provide latest version: lots of testing.
Compatibility. Waiting for developers to make/implement fixes. Staff support.
Complex environment: use virtualized environment. Poor documentation: staff enhance documentation through various
means. Rapid change: each successive version of a software is not necessarily implemented assessed to determine the
added value.
Configuration and customization may take time and may not be possible to customize to satisfaction. Idiosyncratic code
which will need to be documented and systemized. Attitude that open source may mean an inferior product.
Continued maintenance. Documentation.
Coordinating activities across developers not in the same location. Managing expectations for features and delivery
dates. Finding qualified developers and keeping them in the library.
Creation of new tools needs deeper understanding of the OSS system.
Customizability and time to maintain customizations. Resource time to support users in using as the software is
somewhat unintuitive.
Deciding whether to develop custom extensions or install existing. Resolved through cost benefit analysis.
Difficulty in getting timely accurate support. Requires developing in-house deep understanding to support. Finding
clearly written documentation. Building a documentation system to accompany OSS systems necessary. Understanding
limitations in the feature set of an application. Building prototypes and involving stakeholders in pre-production testing.
Difficulty with interoperability. More staff overhead for maintenance and support. Unclear migration path.
Documentation. Adoption.
Documentation: develop local documentation contribute testing, bug reports, and documentation to project.
Incomplete functionality: develop alternative workflows, contribute enhancements. Poorly developed or managed code
contribution process: minimize customization of software.
Ensuring enough cross training, especially to ensure continuity in case of staff loss. Handling non-core customizations in
upgrades of core. Occasional gaps in documentation of OSS systems.
Finding and selecting products with the appropriate functionality. Discovery committees are usually tasked with
the assessment and evaluation process. Conveying support knowledge from an experienced staff member to an
Adopting open source software isn’t free. There are support costs. We schedule regular maintenance of our software.
Some vendors have more resources and can be quicker to market to meet a need or respond to changing environment.
To deal with this, we always keep our options open to swapping pieces between OSS and vended solutions.
Although we try to minimize support costs through good engineering, we nevertheless have to support the applications.
We move most application support to a support group after deployment, but some support issues require developer
attention, taking time away from development efforts on other projects. The time to deployment can be long depending
on the level of development or customization we undertake.
Bad software. Bad documentation. Too much staff time needed to get application running.
Bugs
Change in mindset on part of technical staff to contribute to open source communities.
Changing code: careful tracking of changes. Pressure to always provide latest version: lots of testing.
Compatibility. Waiting for developers to make/implement fixes. Staff support.
Complex environment: use virtualized environment. Poor documentation: staff enhance documentation through various
means. Rapid change: each successive version of a software is not necessarily implemented assessed to determine the
added value.
Configuration and customization may take time and may not be possible to customize to satisfaction. Idiosyncratic code
which will need to be documented and systemized. Attitude that open source may mean an inferior product.
Continued maintenance. Documentation.
Coordinating activities across developers not in the same location. Managing expectations for features and delivery
dates. Finding qualified developers and keeping them in the library.
Creation of new tools needs deeper understanding of the OSS system.
Customizability and time to maintain customizations. Resource time to support users in using as the software is
somewhat unintuitive.
Deciding whether to develop custom extensions or install existing. Resolved through cost benefit analysis.
Difficulty in getting timely accurate support. Requires developing in-house deep understanding to support. Finding
clearly written documentation. Building a documentation system to accompany OSS systems necessary. Understanding
limitations in the feature set of an application. Building prototypes and involving stakeholders in pre-production testing.
Difficulty with interoperability. More staff overhead for maintenance and support. Unclear migration path.
Documentation. Adoption.
Documentation: develop local documentation contribute testing, bug reports, and documentation to project.
Incomplete functionality: develop alternative workflows, contribute enhancements. Poorly developed or managed code
contribution process: minimize customization of software.
Ensuring enough cross training, especially to ensure continuity in case of staff loss. Handling non-core customizations in
upgrades of core. Occasional gaps in documentation of OSS systems.
Finding and selecting products with the appropriate functionality. Discovery committees are usually tasked with
the assessment and evaluation process. Conveying support knowledge from an experienced staff member to an
