14 · Survey Results: Executive Summary
Blacklight (5 respondents), and ArchivesSpace (4 re-
spondents). Below are some of the highlights of library
contributions to the projects.
• The most common contributions involved
code or developer time (47 respondents),
funding (36 respondents), hosting (36 re-
spondents), and testing (8 respondents).
• Across all types of contributions, the most
common types of projects included institu-
tional repositories (38 respondents), digital
preservation (30 respondents), digital asset
management (22 respondents), discovery
layer (15 respondents), publishing (13 re-
spondents), authentication/identity man-
agement (10 respondents), and electronic
resource management (10 respondents).
• Code was most commonly contributed
to projects on institutional repositories
(32 respondents), digital preservation (22
respondents), digital asset management
(20 respondents), and discovery layers (11
respondents).
• Digital preservation and institutional repos-
itory projects most often received funding
via monetary contributions (19 and 18 re-
spondents, respectively), followed by digital
asset management projects (8 respondents).
• Hosting was contributed most often to digi-
tal preservation projects (9 respondents), fol-
lowed by repository and publishing projects
(5 respondents each).
When asked about reasons for open sourcing their
project, respondents listed the following as being “im-
portant” or “very important”: a belief that open sourc-
ing would lead to better software (30 respondents), a
desire to contribute to an open source community (29
respondents), and shared effort in development and
quality assurance of the project (27 respondents).
Sixty respondents (78%) develop plugins, exten-
sions, or customizations for a library-related propri-
etary or vended system. Of these, 31 (54%) indicated
vendors allowed them to distribute the code under an
open source license.
As was the case with OSS adoption policies, 44
respondents indicated their library has no policy in
place for contribution to open source projects, while
20 respondents have an informal policy. Thirty-four
respondents stated that they have no tech transfer pol-
icy, while 23 respondents indicated that their parent
institution has a formal, written tech transfer policy.
Respondents were asked to describe three benefits
and three challenges associated with contributing to
OSS. The benefit most commonly cited was engage-
ment in the open source community (38 respondents).
Other common themes included control of product
features and direction (25 respondents), and recogni-
tion/reputation (14 respondents). The most common
challenge was allocating sufficient staff time to make
meaningful contributions (24 respondents). Other
commonly cited challenges included writing gener-
alized software for use by a larger community, and
securing the financial resources needed to support the
open source project and community (7 respondents
each).
Since open source project members are rarely col-
located, a variety of tools have been employed to help
coordinate development efforts. Common tools used
include shared version control (37 of 45 respondents,
or 82%), an issue tracker (36 or 80%), a mailing list, (32
or 71%), and a wiki (25 or 56%). Forty-one respondents
(79%) use a public repository or forge to share their
open source code Github was by far the most com-
mon (38 of 41 respondents, or 93%).
The most common licenses used by respondents
were GNU Public License v3 (16 respondents), Apache,
and Creative Commons (15 responses each).
Respondents were asked to rank a set of success
indicators in terms of their importance for the respon-
dent’s institution. A significant number (41 or 80%)
identified as most important that the functionality
better suits their institution’s needs.
Respondents were asked if any of their in-house
software could have been, but has not yet been,
released under an open source license. The 53 re-
spondents (69%) who answered in the affirmative
expressed concerns about the staff time commitment
required to support the community (41 or 77%), the
readiness of code quality for public adoption (39 or
74%), and dependence on other internal systems (30
or 57%).
Blacklight (5 respondents), and ArchivesSpace (4 re-
spondents). Below are some of the highlights of library
contributions to the projects.
• The most common contributions involved
code or developer time (47 respondents),
funding (36 respondents), hosting (36 re-
spondents), and testing (8 respondents).
• Across all types of contributions, the most
common types of projects included institu-
tional repositories (38 respondents), digital
preservation (30 respondents), digital asset
management (22 respondents), discovery
layer (15 respondents), publishing (13 re-
spondents), authentication/identity man-
agement (10 respondents), and electronic
resource management (10 respondents).
• Code was most commonly contributed
to projects on institutional repositories
(32 respondents), digital preservation (22
respondents), digital asset management
(20 respondents), and discovery layers (11
respondents).
• Digital preservation and institutional repos-
itory projects most often received funding
via monetary contributions (19 and 18 re-
spondents, respectively), followed by digital
asset management projects (8 respondents).
• Hosting was contributed most often to digi-
tal preservation projects (9 respondents), fol-
lowed by repository and publishing projects
(5 respondents each).
When asked about reasons for open sourcing their
project, respondents listed the following as being “im-
portant” or “very important”: a belief that open sourc-
ing would lead to better software (30 respondents), a
desire to contribute to an open source community (29
respondents), and shared effort in development and
quality assurance of the project (27 respondents).
Sixty respondents (78%) develop plugins, exten-
sions, or customizations for a library-related propri-
etary or vended system. Of these, 31 (54%) indicated
vendors allowed them to distribute the code under an
open source license.
As was the case with OSS adoption policies, 44
respondents indicated their library has no policy in
place for contribution to open source projects, while
20 respondents have an informal policy. Thirty-four
respondents stated that they have no tech transfer pol-
icy, while 23 respondents indicated that their parent
institution has a formal, written tech transfer policy.
Respondents were asked to describe three benefits
and three challenges associated with contributing to
OSS. The benefit most commonly cited was engage-
ment in the open source community (38 respondents).
Other common themes included control of product
features and direction (25 respondents), and recogni-
tion/reputation (14 respondents). The most common
challenge was allocating sufficient staff time to make
meaningful contributions (24 respondents). Other
commonly cited challenges included writing gener-
alized software for use by a larger community, and
securing the financial resources needed to support the
open source project and community (7 respondents
each).
Since open source project members are rarely col-
located, a variety of tools have been employed to help
coordinate development efforts. Common tools used
include shared version control (37 of 45 respondents,
or 82%), an issue tracker (36 or 80%), a mailing list, (32
or 71%), and a wiki (25 or 56%). Forty-one respondents
(79%) use a public repository or forge to share their
open source code Github was by far the most com-
mon (38 of 41 respondents, or 93%).
The most common licenses used by respondents
were GNU Public License v3 (16 respondents), Apache,
and Creative Commons (15 responses each).
Respondents were asked to rank a set of success
indicators in terms of their importance for the respon-
dent’s institution. A significant number (41 or 80%)
identified as most important that the functionality
better suits their institution’s needs.
Respondents were asked if any of their in-house
software could have been, but has not yet been,
released under an open source license. The 53 re-
spondents (69%) who answered in the affirmative
expressed concerns about the staff time commitment
required to support the community (41 or 77%), the
readiness of code quality for public adoption (39 or
74%), and dependence on other internal systems (30
or 57%).
