22 · Survey Results: Survey Questions and Responses
system has many different categories of help, and it is used by a variety of campus departments. Help requests are
triaged to the appropriate campus department based on need.
We occasionally hold focus group sessions with student users (generally undergraduates). These are sometimes very
informal introductions to prototypes on which we gather first-reaction comments to inform further development, at
other times, these are more structured formal feedback opportunities.
SYSTEMS BUILT IN-HOUSE THAT AREN’T OPEN SOURCED
5. Has your library built in-house any library-specific systems that could be, but have not been,
released as open source? N=77
Yes 53 69%
No 24 31%
If yes, what are the primary reasons for not releasing it as open source? Check all that apply. N=53
Concerns about staff time commitment required to support the community 41 77%
Concerns that the code quality is not ready for public adoption 39 74%
Dependence on other internal systems 30 57%
It didn’t occur to us 7 13%
Seeking to license or sell the system 2 4%
A competitive desire to have the best system 1 2%
Other reason(s) 12 23%
Please briefly describe the other reason(s) for not open sourcing the system. N=12
Highly customized to address local requirements.
Lack of clarity about campus policies for licensing and intellectual property ownership.
Legal considerations.
Narrow niche applications where a community is unlikely to develop.
Not approved for release.
Not documented for external audiences.
Often these systems reflect local practices. We’ve not viewed them as useful beyond our local environment.
Planning to release a service as open source, working on appropriate licensing language at this time.
Security
Security concerns related to embedded information.
Technology Commercialization Office needs to review any software developed at the university.
Time needed for review of and compliance with licenses of third-party components.
system has many different categories of help, and it is used by a variety of campus departments. Help requests are
triaged to the appropriate campus department based on need.
We occasionally hold focus group sessions with student users (generally undergraduates). These are sometimes very
informal introductions to prototypes on which we gather first-reaction comments to inform further development, at
other times, these are more structured formal feedback opportunities.
SYSTEMS BUILT IN-HOUSE THAT AREN’T OPEN SOURCED
5. Has your library built in-house any library-specific systems that could be, but have not been,
released as open source? N=77
Yes 53 69%
No 24 31%
If yes, what are the primary reasons for not releasing it as open source? Check all that apply. N=53
Concerns about staff time commitment required to support the community 41 77%
Concerns that the code quality is not ready for public adoption 39 74%
Dependence on other internal systems 30 57%
It didn’t occur to us 7 13%
Seeking to license or sell the system 2 4%
A competitive desire to have the best system 1 2%
Other reason(s) 12 23%
Please briefly describe the other reason(s) for not open sourcing the system. N=12
Highly customized to address local requirements.
Lack of clarity about campus policies for licensing and intellectual property ownership.
Legal considerations.
Narrow niche applications where a community is unlikely to develop.
Not approved for release.
Not documented for external audiences.
Often these systems reflect local practices. We’ve not viewed them as useful beyond our local environment.
Planning to release a service as open source, working on appropriate licensing language at this time.
Security
Security concerns related to embedded information.
Technology Commercialization Office needs to review any software developed at the university.
Time needed for review of and compliance with licenses of third-party components.
