SPEC Kit 340: Open Source Software · 59
We use software to solve our problems that others have written. Better code is written when you have an external
audience of coders reviewing your contribution. There’s lots of it that’s relevant to an academic library.
We want to be able to influence the direction of the effort to align it with our needs. By participating in a larger
community, we can contribute the good ideas of our staff and in turn learn from the good ideas of others.
26. Please briefly describe up to three challenges your library encountered as a result of contributing
to OSS projects and the strategies employed to overcome these challenges. N=37
Adhering to community standards that differ from in-house. Committing the resources to develop contributions.
Understanding the code base and requirements according to the community need.
Agreement of product direction. Coordinate development.
Assessing value to OSS project. Confidence in coding standards. Compliance with OSS review process.
Contribution of developer time can compete with other local project priorities. Remote/asynchronous collaboration:
might have to wait a long time for responses. No clear, quantifiable ROI.
Coordinating effort across institutions challenging/varying opinions on functionality. Finding financial sources.
Maintaining and supporting software.
Coordination/management of developers. Getting good functional requirements.
Developer/programmer will graduate. Staff required to learn programming of system. Need to document every phase.
Developing a product that is generic enough to meet needs of multiple institutions. Supporting and growing the
community around the project. Sustainability: securing ongoing funding to support the software.
Difficult to make substantial contribution without more dedicated time to devote to it.
Extra time. Convincing stakeholders of value. Coming to terms with applicable licensing models.
Finding staff time to contribute. Disconnect between OSS priorities, which may be based on the funder’s priorities, and
our institutional needs. Ongoing financial commitment as OSS moves to a community source model.
Finding time and resources to devote to development process. Feature creep.
Finding time to contribute. Time to support and answer questions. Removing localization.
Getting library staff familiar with OSS/collaborative ways of working. Lack of control of timelines of collaborative OSS
projects, need to readjust expectations. Not enough staff time to both participate actively in OSS projects and continue
local responsibilities.
Increased time spent in detailed documentation.
Internal buy-in to benefit of time spent on OSS projects: communication about project at all levels of institution
reaching out to potential stakeholders early in process. General Consul was concerned about our distribution of code,
especially with development contributed by faculty who don’t have code development built into their job description.
The faculty had to sign a release before we could contribute the code.
It can take more work to contribute well to a public project, but that can tend to produce better results. We need to
review legal guidelines around assigning copyright to external organizations.
We use software to solve our problems that others have written. Better code is written when you have an external
audience of coders reviewing your contribution. There’s lots of it that’s relevant to an academic library.
We want to be able to influence the direction of the effort to align it with our needs. By participating in a larger
community, we can contribute the good ideas of our staff and in turn learn from the good ideas of others.
26. Please briefly describe up to three challenges your library encountered as a result of contributing
to OSS projects and the strategies employed to overcome these challenges. N=37
Adhering to community standards that differ from in-house. Committing the resources to develop contributions.
Understanding the code base and requirements according to the community need.
Agreement of product direction. Coordinate development.
Assessing value to OSS project. Confidence in coding standards. Compliance with OSS review process.
Contribution of developer time can compete with other local project priorities. Remote/asynchronous collaboration:
might have to wait a long time for responses. No clear, quantifiable ROI.
Coordinating effort across institutions challenging/varying opinions on functionality. Finding financial sources.
Maintaining and supporting software.
Coordination/management of developers. Getting good functional requirements.
Developer/programmer will graduate. Staff required to learn programming of system. Need to document every phase.
Developing a product that is generic enough to meet needs of multiple institutions. Supporting and growing the
community around the project. Sustainability: securing ongoing funding to support the software.
Difficult to make substantial contribution without more dedicated time to devote to it.
Extra time. Convincing stakeholders of value. Coming to terms with applicable licensing models.
Finding staff time to contribute. Disconnect between OSS priorities, which may be based on the funder’s priorities, and
our institutional needs. Ongoing financial commitment as OSS moves to a community source model.
Finding time and resources to devote to development process. Feature creep.
Finding time to contribute. Time to support and answer questions. Removing localization.
Getting library staff familiar with OSS/collaborative ways of working. Lack of control of timelines of collaborative OSS
projects, need to readjust expectations. Not enough staff time to both participate actively in OSS projects and continue
local responsibilities.
Increased time spent in detailed documentation.
Internal buy-in to benefit of time spent on OSS projects: communication about project at all levels of institution
reaching out to potential stakeholders early in process. General Consul was concerned about our distribution of code,
especially with development contributed by faculty who don’t have code development built into their job description.
The faculty had to sign a release before we could contribute the code.
It can take more work to contribute well to a public project, but that can tend to produce better results. We need to
review legal guidelines around assigning copyright to external organizations.