46 · Survey Results: Survey Questions and Responses
Managing all the associated software components of a software package. Getting the organization to make the
appropriate level of investments. Free software does not mean no cost. Have to monitor security patches more closely.
Metrics that can be used to compare against commercial software since much of what we develop and use is done
by OSS communities. We are not merely shopping, adopting, and tailoring we are building it together and have no
access to all the information needed for valid metrics. Strategy: gather information on cost for solutions that only
serve a portion of needs and be able to articulate that against ballpark expense of equivalent OSS. Getting software
developers from commercial sector to understand that the return on investment for day-to-day work is not exact. When
you preserve cultural heritage or the scholarly record, the impact on research or learning is very difficult to measure
there is no clear profit margin in terms of money. Strategy: make applicants aware of the mission and strategy of the
organization, be transparent about the institution and how the organization fits within the institution and the larger
educational community. Managing expectations: since we have OSS, people believe they can have everything but we
aim to standardize practices within our national and international communities so we have to manage expectations
on how much customization and one-off design is sustainable and practical. Strategy: engage early, often, and be
transparent into why and how work is being accomplished.
More complexity in implementation, configuration. Accommodating local customizations at time of software upgrade.
More up-front development work: it’s all our responsibility. “Forking” code: ending up with code that is removed from
the open source core.
Need to grow staff expertise: grew it.
New development method (agile) employed. Managing scope. Prioritizing desired enhancements.
Newer versions no longer supporting important features: overcome by changing to a different system. Minimal to no
support: overcome by increasing our knowledge and expertise, or securing third-party support where available. Lack of
availability of formal training in system use: overcome by taking a deep breath and figuring it out as we go.
Open source is not free. Infrastructure costs and developer salary/benefits add up over time. Keeping up with upgrades.
Future of the product is not entirely up to us and may go in an undesired direction.
Personnel to sustain systems: proposal to administration to re-hire. Priority conflicts with multiple systems: working
with leadership to implement portfolio management. No clarity on system expectations and service design when OSS
solutions are requested from the IT department: working with leadership to implement project management.
Poor documentation for the software: our Systems Department was helpful getting the server ready, then we depended
on an active and enthusiastic user group. Minimal tech support: we depended on fellow-users because help from the
software was limited.
Problems must be resolved by staff: network with community of users. Documentation lacking: network with
community of users acquire reviews of OSS. Maintenance and upgrades: don’t be the first.
Software ceasing to be developed by the community. Software being developed for technology stacks that we don’t
run. Inconsistent documentation.
Some software can have a steep learning curve.
Staff and consultant time spent on debugging and customization. Cost of implementation and support not much less
than commercial product. Product looks behind-the-times.
Staff cost. Long-term stability and robustness of software. Open source licenses can be variable.
Managing all the associated software components of a software package. Getting the organization to make the
appropriate level of investments. Free software does not mean no cost. Have to monitor security patches more closely.
Metrics that can be used to compare against commercial software since much of what we develop and use is done
by OSS communities. We are not merely shopping, adopting, and tailoring we are building it together and have no
access to all the information needed for valid metrics. Strategy: gather information on cost for solutions that only
serve a portion of needs and be able to articulate that against ballpark expense of equivalent OSS. Getting software
developers from commercial sector to understand that the return on investment for day-to-day work is not exact. When
you preserve cultural heritage or the scholarly record, the impact on research or learning is very difficult to measure
there is no clear profit margin in terms of money. Strategy: make applicants aware of the mission and strategy of the
organization, be transparent about the institution and how the organization fits within the institution and the larger
educational community. Managing expectations: since we have OSS, people believe they can have everything but we
aim to standardize practices within our national and international communities so we have to manage expectations
on how much customization and one-off design is sustainable and practical. Strategy: engage early, often, and be
transparent into why and how work is being accomplished.
More complexity in implementation, configuration. Accommodating local customizations at time of software upgrade.
More up-front development work: it’s all our responsibility. “Forking” code: ending up with code that is removed from
the open source core.
Need to grow staff expertise: grew it.
New development method (agile) employed. Managing scope. Prioritizing desired enhancements.
Newer versions no longer supporting important features: overcome by changing to a different system. Minimal to no
support: overcome by increasing our knowledge and expertise, or securing third-party support where available. Lack of
availability of formal training in system use: overcome by taking a deep breath and figuring it out as we go.
Open source is not free. Infrastructure costs and developer salary/benefits add up over time. Keeping up with upgrades.
Future of the product is not entirely up to us and may go in an undesired direction.
Personnel to sustain systems: proposal to administration to re-hire. Priority conflicts with multiple systems: working
with leadership to implement portfolio management. No clarity on system expectations and service design when OSS
solutions are requested from the IT department: working with leadership to implement project management.
Poor documentation for the software: our Systems Department was helpful getting the server ready, then we depended
on an active and enthusiastic user group. Minimal tech support: we depended on fellow-users because help from the
software was limited.
Problems must be resolved by staff: network with community of users. Documentation lacking: network with
community of users acquire reviews of OSS. Maintenance and upgrades: don’t be the first.
Software ceasing to be developed by the community. Software being developed for technology stacks that we don’t
run. Inconsistent documentation.
Some software can have a steep learning curve.
Staff and consultant time spent on debugging and customization. Cost of implementation and support not much less
than commercial product. Product looks behind-the-times.
Staff cost. Long-term stability and robustness of software. Open source licenses can be variable.
