60 · Survey Results: Survey Questions and Responses
It is more expensive to write code that is generalizable than custom code for your institution. The development process
is slower and requires a higher mind.
Larger than expected contribution time required of local resources.
Legal and licensing issues. Strategy: involvement of in-house legal expertise (our Director of Copyright and Digital
Scholarship) and coordination with the university Technology Transfer office. Need to provide support or decide how
much support to provide. Strategy: clearly communicate expectations regarding level of support provided. Need to
support a wider range of environments than would be necessary for an internal-only deployment. Strategy: reducing
over-dependence on current architecture can actually reduce costs over the full life of a project.
Maintenance of contributed code to fill the needs of the outside community. Monitoring feedback through multiple
channels (pull requests, forum posts, IRC, etc.)
Managing expectations, sometimes you have to compromise. Strategy: engage with people and be transparent.
Determining which projects to engage and to what degree. Strategy: stay connected at a management level, know your
strategic objectives, know your staff and what culture is a good fit for your resources. Resources. Strategy: be able to
show value toward strategic objectives for the resource investment.
Meeting expectations of adopters when we are the primary contributors.
More meetings take time away from local development.
Not having solid business models to refer to showing the real costs of developing, supporting, using OSS. Not being able
to devote enough staff effort to OSS projects. When they are on a project less than 50% their return on investment is
not as great. Getting institutional support beyond the library for certain solutions. Many administrators seem to prefer
vendor provided out-of-the-box solutions.
Opportunity cost: developers not able to contribute to local initiatives.
Partner reliability.
Product was too narrowly focused for our exact needs to be worthy of sharing out to the community.
Some open source applications don’t have formal paid support options available, so support risks are transferred from
a vendor to the institution: careful evaluation of the risk, and level of risk before making the decision to do an OSS
project. Sometimes a lack of understanding that open source doesn’t equal free. The cost to the institution may be the
same or even greater than a proprietary solution, just the money is spent on different aspects of the project: discussions
with library stakeholders to make sure everyone clearly understands the full cost of OSS projects. Lack of institutional
understanding to the open source model and licenses can hinder contributions of code back to the community.
Staff time: we just juggle this part with regular projects.
Support requests related to OSS projects takes some time.
Time and effort for creating it. Maintenance.
Time and resource commitment
Time spent to keep track of project.
Time to develop: fit in around other responsibilities. Time to support/answer questions: make part of professional
development responsibilities.
Time: overcome only by choosing not to move forward on other projects at that time.
It is more expensive to write code that is generalizable than custom code for your institution. The development process
is slower and requires a higher mind.
Larger than expected contribution time required of local resources.
Legal and licensing issues. Strategy: involvement of in-house legal expertise (our Director of Copyright and Digital
Scholarship) and coordination with the university Technology Transfer office. Need to provide support or decide how
much support to provide. Strategy: clearly communicate expectations regarding level of support provided. Need to
support a wider range of environments than would be necessary for an internal-only deployment. Strategy: reducing
over-dependence on current architecture can actually reduce costs over the full life of a project.
Maintenance of contributed code to fill the needs of the outside community. Monitoring feedback through multiple
channels (pull requests, forum posts, IRC, etc.)
Managing expectations, sometimes you have to compromise. Strategy: engage with people and be transparent.
Determining which projects to engage and to what degree. Strategy: stay connected at a management level, know your
strategic objectives, know your staff and what culture is a good fit for your resources. Resources. Strategy: be able to
show value toward strategic objectives for the resource investment.
Meeting expectations of adopters when we are the primary contributors.
More meetings take time away from local development.
Not having solid business models to refer to showing the real costs of developing, supporting, using OSS. Not being able
to devote enough staff effort to OSS projects. When they are on a project less than 50% their return on investment is
not as great. Getting institutional support beyond the library for certain solutions. Many administrators seem to prefer
vendor provided out-of-the-box solutions.
Opportunity cost: developers not able to contribute to local initiatives.
Partner reliability.
Product was too narrowly focused for our exact needs to be worthy of sharing out to the community.
Some open source applications don’t have formal paid support options available, so support risks are transferred from
a vendor to the institution: careful evaluation of the risk, and level of risk before making the decision to do an OSS
project. Sometimes a lack of understanding that open source doesn’t equal free. The cost to the institution may be the
same or even greater than a proprietary solution, just the money is spent on different aspects of the project: discussions
with library stakeholders to make sure everyone clearly understands the full cost of OSS projects. Lack of institutional
understanding to the open source model and licenses can hinder contributions of code back to the community.
Staff time: we just juggle this part with regular projects.
Support requests related to OSS projects takes some time.
Time and effort for creating it. Maintenance.
Time and resource commitment
Time spent to keep track of project.
Time to develop: fit in around other responsibilities. Time to support/answer questions: make part of professional
development responsibilities.
Time: overcome only by choosing not to move forward on other projects at that time.
