Integrating OSS into Institutional Software Pathways §
Pattern Summary §
Consult with researchers, faculty and staff about open source software (OSS) to create an educational resource on how the release and management of OSS fits within wider research translation, technology transfer and commercialization pathways.
Problem / Challenge §
- Researchers are often unaware of the institutional context their projects are operating in, the value of open source software (OSS) and how their projects may be impacted by decisions taken at earlier stages of development.
- Colleagues in start-up, spin-off and Technology Transfer Offices (TTOs) may also lack crucial knowledge about open source software in comparison to proprietary software.
Pattern Category §
Below is a list of common categories of academic OSPO activities - please choose which apply:
- Advocacy, Governance & Policy
- Promoting Best Practices
- Working with Tech Transfer / External Partners
Context §
A university committed to research, teaching, and the transfer of knowledge and technology with diverse departments of varying levels of OSS expertise and needs. An OSPO or staff member that is resourced to conduct a stakeholder consultation and to develop outputs based on the needs identified.
Forces §
Researchers are experiencing challenges in relation to the release and wider use of academic OSS in terms of OSS license management, compliance with institutional IP/OSS policies, aligning OSS license management with project goals and commercialization plans. TTOs are engaging at a later stage in development with researchers - after critical choices have been made about software release and licensing. TTOs may not be fully aware of the importance or value proposition of OSS. The OSPO or project lead has a working knowledge and relationship with TTO, contract, and/or spin-off colleagues.
Solution §
The solution below outlines some core activities to consider:
Identify stakeholders §
Identify key staff that are tasked with advising or supporting the translation of academic OSS projects (e.g. Technology Transfer, research contract teams, spin-offs and start-up teams). Identify faculty, researchers, research software engineers and post-docs involved in OSS research and related activities.
Outreach and promotion of consultation §
Organise individual or small group meetings with key staff members to identify pitfalls and needs related to OSS that have emerged in their work. Seek more extensive feedback from faculty and researchers by organizing small group meetings; contact Department heads in the first instance to organize support with distributing meeting invites.
Consultation process §
Designing questions §
Questions for staff may differ from faculty and researchers. Questions for staff in TTOs and related teams are likely to focus on: * The recurrent issues that they encounter. * When these problems typically arise. * The advice they currently provide on academic OSS.
Questions for faculty and students may need to capture: * Their areas of work. * What they may have misunderstood or ignored about open source in the initial research and development phases. * The impact of common pitfalls on the release, management, commercialization or translation of their projects. * The contact points for advice and interaction on the transfer or commercialization of software. * What type of materials/supports they would benefit from in relation to these issues and how best to promote them to a wider audience within the institution.
Initial consultation phase §
Organise meetings with each cohort to understand the common challenges and their understanding of software pathways within the institution.
Develop educational resources §
- Based on learning, create a draft resource that addresses the identified knowledge gaps and common pitfalls. This may include:
- Signposting contact points
- A process map or flowchart relating to software pathways and key decision points for all stakeholders.
Follow up consultation §
Meet with stakeholders for an internal review of the educational resources developed. Some additional work may be necessary.
Promotion of resources §
Use learning from consultations to promote resources or services as widely as possible.
Resulting Context §
The intended outcome is that all stakeholders have a clearer and common understanding of how academic OSS can be integrated into the common software pathways within their university.
Additional learning from the ETH Zürich §
We decided to use a clear infographic to capture the pathways for release and management of both OSS and proprietary software. Our TTO colleagues found this process particularly useful and we have been able to use this process to communicate the key contact points for faculty and students when they have questions or need support.
Known Instances §
ETH Transfer, ETH Zürich
References §
Contributors & Acknowledgement §
Ying Wang, ETH Zürich Ciara Flanagan, https://orcid.org/0009-0005-3153-7673