The influence of procurement and information technology governance processes on the adoption of open infrastructure

Introduction and approach

In their role as builders, facilitators, and users of scholarly knowledge infrastructures, libraries and their host institutions are charged with providing cost-effective, sustainable, and mission-aligned services to their users (e.g. Goudarzi et al., 2021; ICOLC Strategies for Open Collaboration in Library Consortia Task Force, 2022; Lewis, 2017). Infrastructure solutions can be positioned along a gradient of openness and community accountability, ranging from fully open-source, community-supported and -governed applications and services to vendor-supported services that utilize open-source applications to fully proprietary commercial products. These applications and services may be sourced and developed locally (with local support and management within the institution), or procured from a vendor for a single organization or for a community (via consortia or other collaborative efforts).

Choosing among available technologies and services potentially engages an institution's procurement and/or information technology governance processes (see sidebar for definitions). In support of Invest in Open Infrastructure’s mission to increase the adoption of open infrastructure, we sought to understand whether and how procurement and IT governance processes can help or hinder the adoption of open infrastructure solutions at research institutions, and to identify opportunities to ensure fair and equal consideration of open infrastructure options.

Decisions around software or service adoption can engage one or both of these frameworks, and we wanted to understand their influence on adoption decisions. Alignment across an organization as to whether "open" is a strategic priority is perhaps the critical key to ensuring it receives serious consideration, but we wanted to do a deeper dive into how these processes themselves influence adoption. Our process for investigating this question was threefold. First, we reviewed selected articles on open-source software adoption, primarily (but not exclusively) in academia. Next, we conducted 12 interviews with individuals from research institutions, consortia, and networks.[2] Interviewees were associated with libraries or library-aligned organizations, because libraries are one of several key players in supporting the research enterprise in academia. We speculated that because libraries have distinctive values and concerns and may operate at greater remove from central IT and procurement, they might be more likely to encounter friction in selecting and procuring technology. The interviewees represent a range of roles, chiefly at the director level or above, including Associate University Librarian, Assistant or Associate Vice President/Dean/Vice Chancellor, Directors and Heads of departments, Programme Managers, and IT staff. Interviewees represent the interests of institutions or consortia located in the United States, Canada, the Netherlands, and Africa. Interviews were focused primarily on unit and campus-level enterprise IT decisions (rather than research IT), addressed descriptions of procurement and IT governance processes, decision-making around “build” versus “buy” solutions and what about these processes interviewees found helpful and/or challenging for the adoption of open infrastructure.[3] We also held a less structured conversation with members of the Higher Education Leadership Initiative for Open Scholarship (HELIOS) working group on Shared Open Scholarship Infrastructure (HELIOS Open, n.d.). Finally, we reviewed publicly accessible documentation on procurement and IT governance from the institutions represented in interviews. We noted and coded areas of concern for comparison across institutions.

Factors in the adoption of open-source software

The drivers of and impediments to the adoption of open infrastructure in general, and open-source software (OSS) in particular, are numerous and varied. Sánchez et al.’s 2020 systematic review of open source adoption considers three classes of factors that can influence adoption of OSS: technological, organizational, and economic.[4] Technological factors include security and reliability, data compatibility, documentation, customizability, portability, trialability, feature set, and user experience (Choi & Pruett, 2019; Petrov & Obwegeser, 2018; Sharma, 2022; Sánchez et al., 2020). The total cost of ownership is the chief economic barrier, and can encompass licensing costs, operational costs, and support costs (Sánchez et al., 2020). Organizational factors include availability of staff and staff expertise, lack of understanding or even active opposition to open source solutions in an organization’s central IT unit and/or at the senior leadership level, risk aversion and lack of accountability for OSS, and brand recognition or “prestige” associated with proprietary solutions (Choi & Pruett, 2019; Linux Foundation, n.d.; OSS Watch, 2008b; Petrov & Obwegeser, 2018; Sánchez et al., 2020). 

Some additional factors that argue more clearly for the adoption of OSS and open solutions include: customizability, lower costs of acquisition, interoperability and prioritizing the use of open standards and technologies, avoiding vendor lock-in, data portability, community accountability and transparency, digital sovereignty concerns, and a strategic intention to reduce reliance on proprietary software (e.g. Choi & Pruett, 2019; Günther, 2023; ICOLC Strategies for Open Collaboration in Library Consortia Task Force, 2022; Sánchez et al., 2020). 

Any number of these factors might be taken into consideration in both procurement and IT governance processes. “Build versus buy” decisions bear early and critical importance, as a buy decision is likely to engage both IT governance and procurement, while build may engage only the IT governance function. Designed specifically to manage the exchange of money for goods and services, procurement processes can be especially problematic for OSS adoption, where no such transaction takes place unless a vendor-supported OSS option is under consideration (ICOLC Strategies for Open Collaboration in Library Consortia Task Force, 2022; OSS Watch, 2008b; Teal et al., 2020; Teperek & Dunning, 2020; Thompson, 2009). IT governance can also strongly influence the likelihood of OSS adoption, and depends heavily on organizational culture and strategic priorities. How well OSS is understood in the organization (what OSS is, and how it is developed, deployed and supported) often directly impacts an institution’s interest in and willingness to implement OSS (ICOLC Strategies for Open Collaboration in Library Consortia Task Force, 2022; Linux Foundation, n.d.; OSS Watch, 2008b, 2008a).

Results

Analysis of documentation

We present a summary of documented areas of concern for each institution or organization we interviewed in Table 1.[5] A consistent concern across all eight sets of documentation we reviewed is information security and compliance with applicable laws, including in the U.S. the Family Educational Rights and Privacy Act (FERPA), the Health Insurance Portability and Accountability Act (HIPAA), the Financial Services Modernization Act, as well as the General Data Protection Regulation (GDPR), which applies to any system or service with users located in the EU regardless of the location of the service. Issues that are commonly addressed under the terms of a service level agreement were also a top concern across the board. These may include, among other things, the responsibilities of the parties, incident management and response, and the availability of technical and end-user support services. 

Technical specifications, intellectual property (retention of rights in content or code), web accessibility, support for integration with other systems and applications, and fit with overall IT strategy were the next most frequently mentioned concerns, and were flagged in five to seven of the documentation sets. Other topics that were mentioned less frequently (three to four times) include a clear exit strategy, value or cost-effectiveness, usability and user experience, and system scope (how widely used it is across an institution). Sustainability (resources required to implement a solution, total cost of ownership), governance and community accountability, and digital sovereignty concerns came up least frequently, never appearing in more than one document set among all the sets we examined.

Analysis of interviews

Most interviewees described a technology selection process that centers identifying the problem to be solved and the desirable attributes of the solution, and selecting the one which best fits the organization’s needs (via a solution’s features and functionality) and circumstances (based on resources and capacity or affinity for vended versus locally developed or hosted solutions). Decision-makers may have a strong preference for open technologies, but “openness” takes many forms, and in and of itself, openness is generally not considered sufficient to justify a decision. That said, some attributes of open technologies or infrastructures — such as interoperability, open standards, and community participation and accountability — can factor into decision making.

Build versus buy

The build versus buy decision — the point at which an organization chooses to develop and/or support locally (“build”) a particular technology or to contract with a vendor to provide a solution (“buy”) — is a critical decision point in the selection process. Some of the organizations we engaged indicated they have the capacity to at least entertain the possibility of build solutions, but most mentioned that buy solutions are often more attractive, whether the technology under consideration is open or proprietary. Decision makers do not always have the budget flexibility to reallocate resources from staff lines to funds for service contracts, or vice versa. In addition, the skills and staff needed to support one approach or the other differ and may not be readily interchangeable. When an organization does have the freedom to choose a build solution, they are often frustrated by the difficulty in assessing the total cost of ownership — the resources required to install, configure, and sustain a particular technology solution over time. Attributes of buy solutions that make them attractive include documented up-front and ongoing costs, and having a party that can be held accountable when issues arise. Multiple interviewees noted, however, that there is a distinctive skill set that is required for managing the proposal process and implementation for a buy solution. This includes the ability to identify and articulate detailed technical requirements, synthesize and evaluate the proposals that are received, negotiate contracts, and manage vendor relationships.

Navigating IT governance and procurement processes

Build solutions are likely to engage IT governance or similar review, while buy solutions are likely to engage both procurement and IT governance reviews. In both IT governance and procurement, risk mitigation and compliance concerns are paramount, particularly around information security. In other areas of concern, based on interviewees’ descriptions, procurement processes seem to tend towards greater formality and strictness than IT governance processes. Where IT governance is relatively flexible, there can be fewer roadblocks to adopting a particular solution, but also less rigorous scrutiny in important areas. 

Interviewees often described procurement evaluation criteria that are biased toward vended and proprietary solutions and/or unsuited for assessing open solutions. These criteria clearly relate to another concern articulated in multiple interviews about a lack of understanding in IT and business units of how OSS communities function and the advantages that open source may confer. Open solutions may offer opportunities for the community to influence a product roadmap and contribute to subsequent development, but interviewees reported that there may be no way to indicate this possibility and how such activities can ensure a solution will meet (in the future, if not the present) specified requirements in an assessment rubric. Other issues included concerns over the possible acquisition of technologies and services by larger commercial entities, low spending limits that require review of even small purchases, and processes that move too slowly to take advantage of one-time funding such as year-end account closeout.

Encouraging an organization’s senior leadership to embrace open infrastructure both on its merits and as a strategic priority emerged as the single most important way to facilitate OSS adoption. Such shared understanding and articulation of priorities alleviates the need for continual education around the benefits of open, and allows decision-makers to focus on the functional characteristics of technologies under consideration. Interestingly, we heard in one interview that while the individual’s organization does prioritize openness for research outputs, it does not assert the same priority for open research infrastructure. This apparent disconnect might represent an advocacy opportunity, or a need to consider the institutional priorities and their alignment with the goals of open research. This is an important point, and one we regret not exploring in all of the interviews.

More prosaic ways to successfully negotiate these processes include using approved vendors if available (who can typically be engaged with less administrative overhead), offering a sole source justification whenever possible (eliminating the need for a competitive process), and providing various types of documentation to expedite review. Most organizations reported that documentation such as a Voluntary Product Accessibility Template (VPAT) or Accessibility Compliance Report (ACR) for demonstrating compliance with web accessibility standards, or a completed Higher Education Community Vendor Assessment Toolkit (HECVAT) can expedite institutional review. VPATs in particular came up as valuable to these evaluation processes, but none of the organizations said any of these documents are an absolute requirement for consideration. 

The role of vended solutions

Some interviewees noted a trend in their own organizations away from buy solutions, and an emerging preference for vendor-supported ones. Vended solutions can leverage open-source or proprietary technologies, but the distinctions go further. Some open-source communities have approved service provider programs, often entailing financial or in-kind support for the community. Some may provide hosting services themselves, and some service providers operate completely independently from the open-source community. Noteworthy here is TU Delft’s[6] experience navigating a selection process for a data repository, a process that resulted in the adoption of a commercial solution and the expression of frustration by community-based providers of open solutions who argued that Delft’s tender process favoured commercial entities with the capacity to participate (Teal et al., 2020; Teperek & Dunning, 2020). Given a level playing field and a full range of choices, however, vended OSS-based options can be attractive to institutions wishing to leverage the advantages of open infrastructure even when they do not have the capacity to operate that infrastructure locally. This is consistent with what we heard in the course of our previous research (Goudarzi et al., 2021): that institutions with a history of locally developed or supported infrastructure, which has the advantage of greater customization and local integration possibilities, were starting to experience a negative impact on the sustainability of locally run and customized solutions.

Consortia and networks: Opportunities for adoption at scale

We want to highlight the unique role that alliances such as consortia and research or education networks can play in supporting the infrastructure needs of their members.[7] While one network we spoke with described the challenges of having to navigate and satisfy the diverse requirements of each and every member, we heard from others that these alliances can be a powerful means of fostering the adoption of open infrastructure at multiple institutions at once. When organizations have granted an alliance the authority to negotiate and procure services on their behalf, this can smooth the way for adoption. Even when a few participating organizations impose additional conditions or requirements on the process, the alliance usually has sufficient latitude to handle the process effectively. As a shared resource, these alliances can provide some of the skills and expertise noted earlier, such as contract negotiation and managing relationships with vendors. We heard in our interviews that vended solutions can be attractive for consortia, allowing for efficient and centralized management for a distributed community of users. Finally, moving forward as part of a larger group can alleviate concerns about being early adopters or adopting the “wrong” solution.

Areas of opportunity

What can be done to ensure institutions are able to give serious consideration to open options? Based on what we heard from decision-makers regarding how IT governance and procurement at their institutions influence the adoption of open infrastructure, we offer the following recommendations, organized by constituent group.

For organizations seeking to adopt open infrastructure:

• Educate organizational stakeholders, particularly at the senior leadership level, on the benefits open infrastructure can confer and work to influence strategic priorities in this direction.[8]
• Encourage review and modification of procurement procedures to identify and address biases against open infrastructure or towards proprietary solutions, and to include criteria that can aid in selecting among them. 
• Adapt selection criteria to allow for the distinctive characteristics of open infrastructure solutions, including possible input to product roadmaps and feature development.
• Explore and develop shared approaches to and support for open infrastructure via consortia, networks, or other kinds of alliances. Organizations with ample technical capacity might consider developing the skills to lead and support shared efforts, while those with fewer technology resources and staff may opt to participate principally as a client.

For open infrastructure communities:

• Complete and be prepared to share (or even make public) commonly requested assessment documents that apply to the infrastructure. The single most important example of this is a VPAT or ACR to demonstrate compliance with web accessibility guidelines.
• Consider completing (and making available the results of) a voluntary self-assessment using an established values framework such as the Principles of Open Scholarly Infrastructure (POSI, Bilder et al. 2020) or the FOREST Framework for Values-Driven Scholarly Communication (Lippincott & Skinner, 2022).
• Foster trustworthy service provider programs to support a variety of vended options for open infrastructure.

For consortia, community organizations and professional associations in the space: 

• Continue to identify and capitalize on opportunities to support and adopt open infrastructure at scale.
• Provide educational materials and guidance documentation to support decision making around technology adoption.[9]
• Provide professional development opportunities to skill up staff to effectively manage negotiations and operating relationships with vendors.
• Provide community fora for exploring and developing frameworks to understand the total cost of ownership for different solutions, and share resources such as contract templates.

Conclusion

We have summarized here what we heard from decision makers at research institutions, and identified some possible courses of action to ensure greater consideration of open infrastructures in technology and service selection. In the course of our work, we found that:

• If not deliberately crafted to fit the characteristics of OSS, procurement and IT governance processes can be a poor fit for open infrastructure options, potentially excluding some open and community-supported options from consideration.
• Buy-in at the senior leadership level is critical.
• Vended solutions can provide viable options for institutions lacking the resources to support infrastructure in-house, and/or smooth the way for open options to be considered in the IT governance and procurement processes. 
• Consortia and other alliances can both mitigate some of the complexity of navigating these processes and reduce the perception of risk among participants.

Finally, we offer some possible courses of action for adopting organizations, consortia, and open infrastructure communities.

References

Bichsel, J., & Feehan, P. (2014). Getting Your Ducks in a Row: IT Governance, Risk, and Compliance Programs in Higher Education. EDUCAUSE. https://library.educause.edu/~/media/files/library/2014/3/ers1402.pdf

Bilder, G., Lin, J., & Neylon, C. (2020). The Principles of Open Scholarly Infrastructure (v1.1, 2023). The Principles of Open Scholarly Infrastructure. https://doi.org/10.24343/C34W2H

Carraway, D., Arruda, K., Hagins, J., Martinez, B., Molina, H., Perry, J., Stingel, R., & Will, C. (2017). Higher Education IT Governance Checklist. EDUCAUSE. https://library.educause.edu/resources/2017/3/higher-education-it-governance-checklist

Choi, N., & Pruett, J. A. (2019). The context and state of open source software adoption in US academic libraries. Library Hi Tech, 37(4), 641–659. https://doi.org/10.1108/LHT-02-2019-0042

Coen, M., & Kelly, U. (2007). Information management and governance in UK higher education institutions: Bringing IT in from the cold. Perspectives: Policy and Practice in Higher Education, 11(1), 7–11. https://doi.org/10.1080/13603100601127915

Goudarzi, S., Pugh, K., Rhinesmith, V., Staines, H., & Thaney, K. (2021). Designing a Preparedness Model for the Future of Open Scholarship. Invest in Open Infrastructure. https://doi.org/10.5281/zenodo.5218968

Günther, C. (2023, November 16). Governments turn to Open Source for sovereignty. OpenSource.Net. https://opensource.net/governments-adopt-open-source-sovereignty/

HELIOS Open. (n.d.). HELIOS Open Workstreams & Outputs. Higher Education Leadership Initiative for Open Scholarship. Retrieved January 24, 2024, from https://www.heliosopen.org/workinggroups

HELIOS Open. (2023). Scholarly Communication Infrastructure Guide: Buy, Build, or Partner. https://www.heliosopen.org/s/HELIOS-Shared-Infrastructure-Decision-Making-Guide-3.pdf

ICOLC Strategies for Open Collaboration in Library Consortia Task Force. (2022). Strategies for Collaboration: Opportunities and Challenges to Build the Future We Need. https://icolc.net/system/files/Strategies%20for%20Collaboration%20-%20Opportunities%20and%20Challenges%20to%20Build%20the%20Future%20We%20Need.pdf

Lewis, D. W. (2017). The 2.5% Commitment. https://hdl.handle.net/1805/14063

Linux Foundation. (n.d.). Creating an Open Source Program. Retrieved October 19, 2023, from https://www.linuxfoundation.org/resources/open-source-guides/creating-an-open-source-program

Lippincott, S., & Skinner, K. (2022). FOREST Framework for Values-Driven Scholarly Communication. https://doi.org/10.5281/zenodo.6557301

OSS Watch. (2008a). Creating a “level playing field” for open source software options in IT selection and procurement.

OSS Watch. (2008b). Decision factors for open source software procurement. http://oss-watch.ac.uk/resources/procurement-infopack

Petrov, D., & Obwegeser, N. (2018). Barriers to Open-Source Software Adoption: Review and Synthesis. International Conference on Information Systems Development (ISD). https://aisel.aisnet.org/isd2014/proceedings2018/ISDMethodologies/3

Sánchez, V. R., Ayuso, P. N., Galindo, J. A., & Benavides, D. (2020). Open source adoption factors—a systematic literature review. IEEE Access, 8, 94594-94609. https://doi.org/10.1109/ACCESS.2020.2993248

Sharma, C. (2022). Tragedy of the Digital Commons. SSRN Electronic Journal. https://doi.org/10.2139/ssrn.4245266

Teal, T., Lowenberg, D., Smith, T., Gonzales, J. B., Nielsen, L. H., & Iannodis, A. (2020, August 26). Sustainable, Open Source Alternatives Exist. Dryad News. https://blog.datadryad.org/2020/08/26/sustainable-infrastructure-exists/

Teperek, M., & Dunning, A. (2020, August 18). Why figshare? Choosing a new technical infrastructure for 4TU.ResearchData. Open Working. https://openworking.wordpress.com/2020/08/18/why-figshare-choosing-a-new-technical-infrastructure-for-4tu-researchdata/

Thompson, M. (2009). Open Source, Open Standards: Reforming IT procurement in Government. https://markthompson1.files.wordpress.com/2012/02/open-source-and-open-standards-osborne-report1.pdf

Appendix A: Interview guide

For this interview, we are defining open infrastructure (OI) as open source software (OSS), but our working definition is broader: some combination of open source, free to use, community governed, transparent in operations, or operated by a non-profit or non-commercial entity. Feel free to keep in mind the definition that best fits your context.

1. If your organization were considering adopting OI, please describe the process(es) you would have to engage in order to do so (additional questions as needed)
   1. What is your role in these processes? NOTE: if short on time, might skip to question 2 and backtrack later if possible.
   2. Who else has a voice in these processes, and what types of roles do they play?
   3. How do you decide whether you are managing something locally vesus working with a vendor?
   4. How do the processes differ if…
      1. You are planning to work with a vendor
      2. You are planning to host or implement the OI locally
   5. Is there any supporting documentation I can see - policies, checklists, or forms, for example?
   6. Are there standard documents - Voluntary Product Accessibility Template (VPAT), Accessibility Compliance Report (ACR), Software Bill of Materials (SBOM), Higher Education Community Vendor Assessment Toolkit (HECVAT), certifications (e.g. Open Source Security Foundation best practices badge), or other attributes (Internet2 service) that are
      1. Required to get approval?
      2. Not required but very useful to have, to get approval?
   7. Who ultimately approves (or denies) the request?
   8. What happens if the request is denied?
2. What works well about these processes?
3. What is challenging? 
4. If you could wave a magic wand, what procedural changes would you make that would make it easier to adopt OI?
5. Who else should we speak to, or what work should I be aware of, as we work to better understand this topic?

Appendix B: List of interviewees by organization

IOI is grateful to the following individuals for sharing their time and perspectives.

AfricaConnect: Leïla Dekkar, International Relations Project Manager - AfricaConnect3 & GÉANT

Carnegie Mellon University: Sayeed Choudhury, Associate Dean for Digital Infrastructure and Director of Open Source Programs Office

Columbia University: Rob Cartolano, Associate Vice President for Technology and Preservation, Columbia University Libraries

Cornell University: Phil Robertson, Director of Software Development and Simeon Warner, Associate University Librarian, Cornell University Library

Delft University of Technology (TU Delft): Alistair Dunning, Head, Research Services, TU Delft Library

GALILEO: Lucy Harrison, Assistant Vice Chancellor for Academic Library Services and Executive Director of GALILEO, University System of Georgia

GÉANT: Nicky Wako, Advocacy Manager

HELIOS Open’s Shared Open Scholarship Infrastructure working group:

• Caitlin Carter, HELIOS Program Manager
• Alicia Salaz, Vice Provost and University Librarian, University of Oregon
• Robert Hilliker, Associate Provost for Libraries, Rowan University
• Julieta Arancio, Open Accelerator Fellow, Open Research Funders Group
• Torsten Reimer, University Librarian and Dean of the University Library, University of Chicago

Massachusetts Institute of Technology (MIT): Carl Jones, Digital Repository Services Engineer, MIT Libraries

Ontario Council of University Libraries: Kate Davis, Director of Scholars Portal

Partnership for Academic Library Collaboration and Innovation: Jill Morris, Executive Director

University of Oregon (UO): Franny Gaede, Director, Department of Open Research, UO Libraries

Appendix C: Area of concern definitions

• Compliance: Data security. Data collection and storage, security of institutional data, privacy policy and practice, and alignment with applicable law. Examples of applicable law include the Family Educational Rights and Privacy Act (FERPA), the Health Insurance Portability and Accountability Act (HIPAA), the Financial Services Modernization Act, and General Data Protection Regulation (GDPR).
• Compliance: System scope. Systems of record (systems that are the authoritative source of institutional data), and systems used widely across the institution are often subject to extra scrutiny.
• Digital sovereignty. Retaining control over a country, region, or population's data and/or technical infrastructure - for example, requiring that cloud services use infrastructure that is located in a client’s country.
• Exit strategy. The ability to opt to change to a different service or infrastructure. For example, the ability to export all data and metadata without limitations or cumbersome contractual obligations. Disposition of data upon termination of service.
• Fit with IT strategy. Infrastructure characteristics are consistent with an organization's overall IT strategy. For example, an institution might have a cloud-first preference for infrastructure, or a preference for vended solutions over locally-managed ones.
• Intellectual property. Retention of intellectual property rights in content or code.
• Service level agreement. Service level agreement attributes, for example: responsibilities of the parties, incident management and response, and availability of technical and user support services.
• Sustainability. Overall effort and resources required to adopt and use the proposed solution; total cost of ownership.
• Technical: Integration. Ease of integration with local and external systems, availability of API(s). For example: single sign-on and email.
• Technical: Specifications. Attributes of the system and degree to which local requirements are met.
• Governance and community accountability. Characteristics of the infrastructure and its community such as governance, open roadmap, and corporate social responsibility criteria.
• Usability and user experience. The user experience and usability of an application.
• Value. Cost-effectiveness of the solution.
• Web accessibility. Compliance with web accessibility requirements.

Feedback

1. IT governance has its origins in corporate governance, the importance of which was made clear following the corporate governance failures of the early 2000s and the passage in the United States of the Sarbanes-Oxley Act of 2002 (Bichsel & Feehan, 2014). Its uptake extends beyond the U.S., however. For example, Jisc engaged consultants to develop an IT governance framework for use in higher education (Coen & Kelly, 2007).
2. Organizational affiliations of interviewees included: AfricaConnect, Carnegie Mellon University, Columbia University, Cornell University, Delft University of Technology (TU Delft), GALILEO, GÉANT, HELIOS Open, Massachusetts Institute of Technology, Ontario Council of University Libraries, Partnership for Academic Library Collaboration and Innovation, and University of Oregon. Please see Appendix B for a complete list.
3. We include the complete interview guide in Appendix A.
4. Our consideration of open infrastructures is intended to be broader than open source software specifically, but the findings of research into the uptake of OSS are still usefully applied here.
5. No formal documentation was available for PALCI. GÉANT and AfricaConnect ; instead of having their own independent policies or processes, they work within those of the institutions they support.
6. We have avoided attributing specific comments to specific institutions throughout this report, but in this case, the details of the story are published.
7. We offer some specific examples of successful shared adoption efforts in the section of this report, “Trends in open infrastructure performance and adoption.”
8. The Higher Education Leadership Initiative for Open Scholarship (HELIOS Open) community in higher education is working towards this objective.
9. HELIOS Open’s (HELIOS Open, 2023) excellent guide offers an excellent such example.