Public Sector Open Source Program Offices - Archetypes for how to Grow (Common) Institutional Capabilities

Abstract

Context: Open Source Software (OSS) is a crucial component of over 90% of digital infrastructure underpinning industry and public digital services, facilitating collaborative software development and dissemination. Its significance in the European public sector has been emphasised through various Ministerial Declarations, highlighting its potential to accelerate digitalisation, transform businesses, and foster a digitally skilled population. Research Aim: This study aims to explore how the adoption, development, and collaboration on OSS can be enabled through organisational support functions or centres of competency, also known as Open Source Programme Offices (OSPOs) within Public Sector Organisations (PSOs) in the European Union, Norway, Liechtenstein, and Iceland. Methodology: A qualitative research approach was adopted, involving an interview survey of 18 OSPO representatives across 16 cases of public-sector OSPOs. These cases were cross-analysed and categorised into six OSPO archetypes. The findings were validated and enriched through two follow-up focus groups that included earlier interviewees and additional experts. Results: The study identified six distinct OSPO archetypes, providing insights into their organisational structures, responsibilities, and contributions to OSS adoption. The archetypes, along with policy recommendations, offer guidance on how PSOs can design their own OSPOs, taking into account their specific context, resources, and policy goals. Conclusions: The findings enhance the understanding of OSPOs as strategic endeavours aimed at promoting O...

keywords

1 Introduction

Open Source Software (OSS) provides a mechanism for collaborative software development and dissemination, as well as a type of building block present in over 90 percent of digital infrastructure underpinning industry and public digital services  [58, 19] . Its importance in the European public sector domain has been stressed through several Ministerial Declarations  [12, 13, 16] , highlighting the potential of OSS to accelerate the digitalisation of public services, digital transformation of businesses, and the growth of a digitally skilled workforce as defined in the European Digital Compass  [15] . These arguments are supported by studies, for example, finding that OSS uptake and competence are essential for a region’s or nation’s digital autonomy and for economic growth in terms of start-ups, jobs, and GDP  [2, 40] . For digital services and products specifically, OSS is a tool to improve interoperability and quality while increasing transparency and accountability  [10] .

Public Sector Organisations (PSOs) are, however, commonly faced with numerous challenges in terms of leveraging the potential of OSS as an instrument in their digital transformations  [26] . One such challenge regards their reliance on the acquisition and outsourcing of technical capabilities  [33] , which has limited the development of competencies regarding OSS  [27] and software engineering practices  [3] . Regulatory constraints and complicated procurement frameworks  [30] , along with limited or short-term policy incentives  [1] , and a conservative IT sourcing culture  [64] further complicate matters. These challenges are particularly pronounced for municipalities due to their smaller size and limited resources, highlighting their need for support  [55, 65, 36] .

Within industry, an established approach to addressing these challenges has been to establish centres of competency, commonly referred to as Open Source Programme Offices (OSPOs)  [59] . Their structure and responsibilities vary depending on an organisation’s needs, goals, and conditions  [21] . However, they typically share the common goal of enabling the use of OSS on the strategic and operational levels in line with the overarching business goals of an organisation  [39] .

Since the OSPOs first appeared in the 2000s  [53, 50, 4] , their adoption has steadily increased. Today, more than 30% of Fortune 100 companies have established an OSPO  [19] , and the adoption is generally trending upwards  [60] . In the public sector, the phenomenon of establishing OSPOs has recently emerged. For example, the recent US Securing Open Source Act recommends that US federal agencies set up OSPOs  [63] .

In Europe, there are no formal recommendations or requirements, although there are some exceptions  [14, 38] . Yet, there are several examples of OSPOs being reported both on supranational (for example, European Commission 1 1 1 https://interoperable-europe.ec.europa.eu/collection/ec-ospo ), national (for example, Italy 2 2 2 https://developers.italia.it/ ), regional (for example, Galicia 3 3 3 https://mancomun.gal/es/ ), and local (for example, Paris 4 4 4 https://opensource.paris.fr/ossparis/english.html ) levels of government, as well as in state-owned enterprises (for example, Alliander  5 5 5 https://www.alliander.com/en/open-source/ ), academia (for example, Trinity College Dublin 6 6 6 https://www.tcd.ie/innovation/for-trinity-innovators/open-source-programme-office/ ), and international humanitarian organisations (for example, WHO  7 7 7 https://pandemichub.who.int/ ). The latter is recognised specifically in the context of how OSPOs can help tackle humanitarian and social challenges through the UN’s yearly OSPOs for Good conference  8 8 8 [https://www.un.org/digital-emerging-technologies/content/ospos-good-2024](https://www.un.org/dig...

The OSPO label is not used consistently across the examples, yet they all share similar features, which can be compared to many definitions of the OSPO construct  [59] . Research on how OSPOs are structured and organised, and what responsibilities they take on, is limited to a few notable examples.

Herpig  [23] ) explores how Cyber Security OSPOs can be set up as a part of an overarching public sector OSPO or an independent unit inside a national cybersecurity agency. The focus of such an OSPO includes “supply-chain security policy work, [and] coordinating across government agencies and offices to ensure that OSS security is no longer tied to a crisis cycle”. OpenForum Europe  [44] explores four cases of public sector OSPOs mainly from a policy perspective, highlighting underpinning goals and strategies of the hosting PSOs. The Linux Foundation  [28] surveys the state of OSS in the European public sector, highlighting OSPOs as a key enabler for OSS operations and adoption, drawing on insights from several OSPO interviewees. None of the reports, however, provides guidance for the public sector at large in terms of how OSPOs may be designed, considering contextual factors, such as the level of government, resources, and policy goals.

Existing guidelines and resources are practically oriented, providing guidance on governance, processes, and tasks a general OSPO or organisation may take on when considering OSS as a strategic initiative  [59, 47, 17] .

Academic literature has recognised their importance only to a limited extent  [22] and explored their representation in the industry context  [39, 69, 51] . Digital government research has meanwhile highlighted the potential for open and agile collaboration in governments through social coding platforms  [35, 36] , while also recognising challenges and the need for dedicated experts that can support OSS adoption inside PSOs (similar to the OSPO construct)  [55, 65] . Research has further focused on exploring the adoption of OSS solutions, for example, the organisational transition from proprietary to OSS alternatives  [56, 67] , and on identifying and evaluating potential benefits, risks, and challenges  [24, 8] . General factors highlighted include the clear need for technical  [45] and procurement-related support  [55, 36] and sustainable s...

This study addresses the gap in research and practice by exploring how the adoption, development, and collaboration on OSS can be enabled specifically through organisational support functions or centres of competency using the OSPO construct. The study is based on an underpinning report by the authors, commissioned by the Directorate-General for Digital Services (DIGIT) of the European Commission to OpenForum Europe and RISE through the OSOR project under Specific Contract 32 FWC DI/07929 with Wavestone SA.

The study thereby has an explicit focus on how PSOs within the European Union (EU), Norway, Liechtenstein, and Iceland work to support and enable the consumption, development, and collaboration of OSS. A qualitative research approach is adopted, with an interview survey of 18 OSPO representatives across 16 cases of different public-sector OSPOs. These cases were cross-analysed and categorised into six OSPO archetypes, providing an overview of how the OSPOs within each archetype are organised, what their responsibilities entail, and how they support OSS within their respective scope and domain. Findings were validated and enriched through two follow-up focus groups that included earlier interviewees and additional experts. We make the following contributions:

• 1.

An empirically grounded typology of OSPO archetypes and practice that can guide PSOs on the design of their own OSPOs, considering their own context, resources, and policy goals.

• 2.

Recommendations for policy for the implementation of support structures and programs to leverage the potential OSS brings as a vehicle for digital innovation and sovereignty.

• 3.

A foundation and several directions for future digital government research on how the implementation of OSS policy can be supported in various contexts of the public sector.

As this is a qualitative study, readers should specifically consider the contextual descriptions of the reported cases before making any anecdotal generalisations. Further, the presented OSPO archetypes are based on a limited sample of studied cases, and provide only a partial picture of how public-sector OSPOs can be organised and structured. Each OSPO will be unique to its organisation’s culture, focus, and practices. Still, the presented archetypes provide a source of inspiration and design knowledge for both practitioners and researchers.

The remainder of this report is structured as follows: first, background and related work are presented, followed by a conceptual framework based on this, which provides an a priori frame for the study (see Section 2). The research design is then introduced along with a discussion of the threats to the validity of the study (see Section 3). The results section is then provided, presenting the OSPO archetypes and the cross-analysis of cases studied (see Section 4), followed by the discussion and conclusions based on the findings (see Section 5).

2 Background and related work

Below, background and related work is presented that frame and provide input to the study, as well as the conceptual framework that is used as a foundation and framing for the continued investigation.

First, what constitutes an OSPO is defined based on a set of established sources. Then an overview is provided of how an OSPO may be structured, what roles may be included, and what responsibilities may lie with the OSPO in an industrial context. Following that, context is provided from an earlier report on public sector OSPOs from a public policy perspective. Finally, the conceptual framework is briefly presented.

2.1 What defines an OSPO?

The concept of OSPOs as a construct originates from industry at the beginning of the 2000s among larger software intensive companies such as Sun Microsystems, Hewlett-Packard, Intel, and Google  [53, 50] . Since then, the concept has grown and matured as several organisations and industries, also outside of the software industry, are adopting the construct  [60] .

With the growth of OSPOs, so has the definition and views of what an OSPO is. The TODO Group, an industry network, describes an OSPO as a “center of competency for an organisation’s open source operations and structure” which may include responsibilities such as designing and facilitating processes for selection and intake of OSS, compliance and auditing, contributions and community engagement, as well as training for an organisation’s different stakeholders  [59] . The OSPO Alliance (a joint initiative by for example, OW2, Eclipse Foundation, OpenForum Europe, and Foundation for Public Code) considers an OSPO as “a cross-functional team to help define and steer an organisation’s open source management strategy and organisational readiness”   [46] . Both networks agree that there is no ”one-size-fits-all”. Rather, its tasks and responsibilities will vary in line with the overarching organisation’s goals, strategies, and views of OSS.

From a public sector perspective, the concept is still emerging, and commonly under different naming conventions, although with similar meanings. OpenForum Europe, for example, considers it as “an institutional organisational construct that supports and accelerates the consumption, creation, and application of Open Source software”   [44] . Specifically, they highlight the focus on “working strategically to achieve the policy objectives of the institution that intersect with Open Source” , which contrasts with the business perspective in industry OSPOs. However, from a general perspective, the focus is still related to enabling OSS as a tool for creating value based on the goals of the focal organisation, public or private.

OSPO++, a network and community of collaborative OSPOs universities, governments, and civic institutions, accordingly looks at the construct from a public sector perspective, highlighting both municipal, government, and university settings. They consider how the public context can bring other organisational structures, incentives, and levels of bureaucracy than the private context  [9] . The common trend of outsourcing and acquiring technical capabilities  [37] , along with otherwise symptomatic short-term planning, and risk-aversive culture  [1] , further adds nuance that might affect how OSPOs in PSOs take shape.

Taking these nuances into consideration, this study uses the OSPO-construct to study how PSOs support and enable the growth of their own capabilities related to consumption of, development of, and collaboration on OSS. Hence, the unit of analysis is the support functions that PSOs provide, not limited by how it is organised, or under what label it is referred to.

2.2 Structures of an OSPO in the industry

The structure and organisational location of an OSPO vary depending on its goals and purpose. Haddad  [21] reports on five examples of how an OSPO can be set up in an industrial setting (see Table 1). The examples vary in terms of their internal sponsor, budget, staffing, which entities they support, and the size of the organisation they are suitable for, as presented in the table below.

The first example puts the OSPO within the R&D organisation with direct sponsorship and reporting to executive management. This setup isolates the OSPO from product departments, enabling it to execute on a general OSS strategy not limited by specific product strategies. More freedom to collaborate with external parties is also given.

The second yet similar example places the OSPO at the corporate level with support functions in each division when multiple product divisions are present. The support functions help adapt and execute OSS strategies, policies, and processes for the respective divisions’ contexts. In a third example, a virtual OSPO, there is typically a main responsible head of OSS but without a fully dedicated team. Individuals from different functions instead work part-time on related tasks coordinated by the head of OSS.

In a fourth example, there is no official OSPO present. Rather, the associated tasks are spread out over multiple individuals, a suitable option for smaller organisations. In the fifth and final example, the OSPO is positioned as a part of the CTO office or the engineering organisation, suitable for medium-sized organisations  [21] .

2.3 Roles within an OSPO in the industry

As with the structure and organisational location, the staffing of the OSPO depends on its goals and purpose. Haddad  [21] differentiates between five different roles, although highlighting that they do not necessarily need to be divided among different individuals. Rather, they can be either shared or aggregated, considering the structure of the OSPO. Roles include:

• 1.

A head of OSS is responsible for the design and execution of the organisation’s OSS strategy. The head also manages the reporting and follow-up of the strategy’s progress to the OSPO’s sponsor.

• 2.

A software architect is proposed with responsibility for high-level technical decisions related to OSS and the organisation’s various products and platforms.

• 3.

A technical evangelist is proposed to support and promote OSS contributions, engagement, and culture across the organisations and externally in relevant communities and foundations.

• 4.

A compliance engineer is proposed to oversee and maintain compliance related to the organisation’s OSS intake.

• 5.

A legal counsel is proposed that is knowledgeable in OSS licensing.

In their classification, the TODO Group differentiates between roles focusing on governance, project management, licensing, security, community engagement, developer education, individual contributors, and OSS advice  [59] .

2.4 Responsibilities of an OSPO in the industry

The TODO Group has defined a set of responsibilities typically maintained by OSPOs based on industry practice and an underpinning report by Haddad  [21] . Exactly which responsibilities an OSPO maintains depends on its purpose. Further, as responsibilities originate from state-of-practice in an industry context, not all may be considered relevant or correctly defined for the public sector context. Still, they provide a point of departure when investigating what responsibilities public sector OSPOs take on. Below, we briefly summarise describe an OSPO’s responsibilities primarily based on the work by Haddad  [21] :

• 1.

Develop and Execute OSS Strategy - An OSPO is responsible for setting and implementing an organisation’s long-term OSS strategy. This involves defining goals related to OSS consumption, participation, contribution, and leadership, depending on the organisation’s maturity and objectives.

• 2.

Oversee OSS Compliance - OSPOs manage compliance with OSS licenses to mitigate legal risks. This includes designing processes and policies to ensure obligations are met, protecting intellectual property, and managing potential infringements.

• 3.

Establish and Improve OSS Policies and Processes - OSPOs develop policies that guide the organisation’s OSS activities, including consumption, contribution, and business decisions. They also create processes for project creation, code release, communication, and training.

• 4.

Prioritise and Drive OSS Upstream Development - Organisations must prioritise which OSS projects to invest in. OSPOs help identify critical projects and establish strategies for community engagement, ensuring alignment with the overarching OSS strategy.

• 5.

Collaborate with OSS Organisations - OSPOs engage with relevant OSS organisations and foundations to align with business goals and influence key technologies. This collaboration can provide strategic advantages and influence within the OSS community.

• 6.

Track Performance Metrics - OSPOs measure the impact of OSS activities through performance metrics that align with business goals. This requires expertise in both metric design and operationalisation to support strategic objectives.

• 7.

Implement Inner Source Practices - Inner Source involves using OSS development practices internally to improve collaboration. OSPOs facilitate this by providing infrastructure, education, and support for cross-functional teamwork.

• 8.

Grow and Retain OSS Talent Inside the Organisation - Training programs are essential for developing internal OSS capabilities. OSPOs offer workshops, mentorships, and ambassador programs to nurture talent and integrate OSS contributions into performance reviews.

• 9.

Provide Advice and Support on OSS - OSPOs advise stakeholders on leveraging OSS in business strategies, evaluating technologies, setting community engagement goals, and ensuring compliance in various contexts such as mergers or outsourced development.

• 10.

Manage Open Source IT Infrastructure - OSPOs manage the infrastructure necessary for engaging with OSS projects and supporting Inner Source initiatives. This includes tools for compliance tracking, vulnerability scanning, and contribution monitoring.

2.5 OSPOs from a public policy perspective

A report from OpenForum Europe  [44] makes the case that the emergence of OSPOs is a result of the acknowledged need to increase OSS competence within different parts of the public sector administration. OpenForum Europe finds, looking at the trends from a managerial perspective that the motivations for building OSPOs in the public sector are diverse, but observe generally that there is a growing acknowledgement that OSS is essential for the public sector and that it is already used in everything from IT infrastructure to e-government services.

Herpig  [23] specifically highlights the criticality of cyber security and the need for establishing a Cyber Security OSPO, a recommendation also highlighted by the US Cybersecurity and Infrastructure Security Agency’s (CISA’s) Open Source Software Security Roadmap  [7] . Main tasks include monitoring the national OSS supply chain, educating on OSS security practices, advising policymakers, supporting OSS infrastructure development, and interfacing with the broader OSS ecosystem. These recommendations are in line with the overall changes in the political environment of OSS and OSPOs where there is an increasing emphasis on software supply chain security, and the ability to make technical sourcing and design decisions based on local needs, values, and laws  [10] .

From a more general perspective, both OpenForum Europe  [44] , and the Linux Foundation  [60] puts emphasis on how sharing and re-use of software between PSOs holds the biggest promise for potential benefits. Economic growth  [2] , increase in competitiveness and entrepreneurial growth  [42, 68] , and long-term interoperability  [11] make up some of these benefits, as well as targets for potential policy interventions.

Several reports, hence, also provide policy recommendations including the establishment of OSPOs looking beyond the specific topic of cyber security  [23, 7] . The Mission Bothorel  [38] report proposed the installation of an OSPO in the context of France, which was instantiated recently after in through the Free Software Unit at the French Interministerial Digital Directorate (Direction interministérielle du Numérique - La DINUM). Similar proposals has been laid forward in the US context  [41] , proposing a federal government OSPO aimed at coordinating OSS policies other public sector OSPOs, as well as overseeing and advising in the general implementation of OSS policy interventions, and interfacing the general OSS ecosystem and other OSPOs on the international level.

2.6 Policy implementations and support initiatives beyond OSPOs

Looking beyond the construct of OSPOs, there has been iterative reporting on overlapping and aligning needs and initiatives. Below, we review common challenges and the organisational approaches highlighted as ways to address them.

2.6.1 Challenges and barriers for OSS adoption

Digital government research draws attention to both the opportunities  [35, 36] and challenges  [55, 65] related to OSS and open collaboration in government and PSOs. Challenges needing attention can be generalised across several areas. Culture is highly cited, characterised by risk-averse and conservative procurement practices  [49] , with a preference for the status quo  [52] and existing solutions  [8, 24] . The need for customisation and integration efforts is also a common inhibitor  [5, 24] . IT departments have been characterised as both “sceptical and doubtful about the possibility of a radical change in the way they work and support their departments and the possibility that they would be requested to learn and support something totally new”   [24] .

Long-term support and mandate from policy and executive management are also common barriers  [56] , where long-term vendor relationships (and lobbying)  [45] and unknowns, such as costs and technical risk, are reiterated in reports  [5, 56] . Internal communication and hierarchy can also contribute to slow (or non-existent) adoption within a PSO  [5] .

Limitations in knowledge and capabilities to consider OSS in acquisition and procurement are further iterated  [5, 8] . This follows a historical trend in the public sector of relying on outsourcing to maintain and scale the technical capabilities needed to meet current needs  [33, 6] , a trend especially evident among local governments  [49] . This has led to a general lack of technical and software engineering expertise across the public sector, not just in OSS  [3] .

To fill this void, vendors and service providers are critical, while availability varies  [8] , and are commonly seen as a barrier for OSS adoption  [5, 24] . PSOs are characterised as sceptical towards the support that OSS communities can provide  [8, 24] , why professional support is critical to promote the adoption of OSS in general  [31]

2.6.2 OSPO-like means of addressing challenges and barriers

The need to foster internal technical expertise and capabilities is called for at both national  [45] and local levels  [55] of government. There is also an expressed need for internal champions and advocates, also referred to as boundary spanners  [65] , who can raise awareness of the opportunities and risks related to OSS and act as bridges to the broader OSS ecosystem and relevant stakeholders to enable trust and knowledge transfer. These champions can act as internal consultants and provide support throughout a PSO, as well as in those with active collaborations and partnerships  [55] . These expert and support functions align closely with the OSPO construct  [53] , and with the expressed need from industry to grow organisational capabilities to support OSS operations aligned with business goals.

For local governments and PSOs with limited resources, the will and budget to create a dedicated OSPO may not be a priority. In these cases, pooling resources and creating collaboration structures make economic sense  [33] , and are standard practices in general OSS collaborations  [43] . Examples have been reported on in, for example, Danish, Swedish and Wallonian contexts, showing how local governments collaborate through member-driven formal  [18] and informal  [49] associations, co-owned public service-providers  [66] , or through resourceful PSOs acting as the primary sponsor and facilitator of the OSS projects  [26] .

The literature stresses the need for professional support, as local government (even when organised) especially lacks technical capabilities. Cases (e.g.,  [18] ) stress the importance of “healthy ecosystem[s] of small and medium sized firms is stimulated to service public sector open source products” that can ensure availability of “detailed documentation, quality assurance, certification schemes, training, and support services”   [55] . The associations, as well as OSPOs, can act as an interface and facilitator of the dialogue and relationship between the concerned PSOs and vendors to monitor and support “the open source approaches, so that source code can be reused across the government” , and that development follows in an open and agile practice  [36] . Examples show that soft vendor lock-ins can easily become a reality  [49] .

2.7 Conceptual framework

Below the conceptual framework is presented (see Fig. 1), which is used to characterise OSPOs inside PSOs and capture their various practices and challenges, but also to provide recommendations for PSOs in terms of how they may consider setting up their own OSPO. Specifically, it is expected that there will be a set of archetypes and responsibilities similar to the work by Haddad  [21] , yet with different characteristics from the industrial context.

3 Research design

The study presents an exploratory qualitative survey  [34] investigating how the adoption, development, and collaboration on OSS can be explicitly enabled through organisational support functions or centres of competency using the OSPO construct. More specifically, the study considers an OSPO as an institutional organisational construct that supports and accelerates the consumption, development, and collaboration of OSS (adapted from OpenForum Europe  [44] .

It should, however, be noted that the OSPO label may be interpreted ambiguously and is not always labelled as such in PSOs. Hence, when searching for these support structures or functions, it was not expected that PSOs would have adopted the OSPO label. Accordingly, the unit of analysis is the support functions, independent of organisational structure or label.

With this scope, the following research questions were defined:

• RQ1:

How are support functions for OSS (i.e., OSPOs) organised and structured within PSOs?

• RQ2:

What are the responsibilities of these support functions (i.e., OSPOs), and how are they performed?

Qualitative surveys are “research methods aiming to identify the diversity of characteristic values, rather than measuring their distribution, in a targeted population”   [34] . In this study, the investigation is conducted iteratively over three research cycles as illustrated in Fig. 2: i) synthesis of a conceptual framework based on industry practice to provide deductive foundation for empirical investigation; ii) semi-structured interview survey across cases representing public sector OSPOs to inductively address our defined research questions; iii) focus-groups to validate and further enrich interview findings. Below, we expand on these in more detail.

3.1 Research cycle one: Conceptualisation of industry practice

To create a conceptual framework for the empirical and inductive investigation of public sector OSPOs, we build on the work by Haddad  [21] which provides a comprehensive source representing the body of knowledge from a practitioner context. The source was selected through a purposive review of practitioner-produced literature (similar to grey literature) of OSPOs in the industry context where practice has been thoroughly reported. Specifically, we leveraged reports and material from the TODO group  9 9 9 https://todogroup.org/ , and OSPO Alliance 10 10 10 https://ospo-alliance.org/ - two OSS communities gathering OSPOs mainly in the industry context. This focus follows from scientific reporting on OSPOs in general being sparse  [22, 39, 69, 51] , and even sparser in the public sector context.

Haddad’s work has also adopted as the foundation for the TODO group’s definition and classification of OSPO’s structure, roles, and activities  [61] . This was validated through personal email communication with a board representative of the TODO group. An initial conceptual framework was created to highlight the structures and responsibilities of OSPOs in an industry context, providing a foundation for characterising OSPOs in the public sector. The framework is presented in Fig. 1. The structure-related categories are explained in Section 2.2, and responsibility-related categories in Section 2.4.

3.2 Research cycle two: Semi-structured interview survey

Informed by the conceptual framework from cycle 1, semi-structured interviews were conducted to empirically investigate the problem domain.

3.2.1 Interview sampling

The first step was to create an overview of the population to sample from. In this process, PSOs with established OSPOs were mapped within the 27 EU member states, plus Norway, Liechtenstein, and Iceland (an exercise conducted in spring 2023) 11 11 11 The EU-centric geographical limitation was given by the commissioning body. Norway, Liechtenstein, and Iceland were included because they are active members of the European Economic Area (EEA). The following networks and resources were leveraged:

• 1.

The EU OSPO network, facilitated by the European Commission OSPO

• 2.

OpenForum Europe’s community network 12 12 12 https://openforumeurope.org/open-source/

• 3.

The Open Source Observatory’s Country Intelligence Reports 13 13 13 https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor/open-source-software-country-intelligence

The synthesised population (presented in table 5in Appendix C) consisted of 23 public sector OSPOs. This was not expected to be a complete representation of the population due to the aforementioned ambiguity in the construct, and the label may not always be used. Still, it provides a large enough population to sample from to gain a diverse set of cases (i.e., a public sector OSPO).

From the identified population, 12 cases were initially selected using a purposive sampling approach  [48] to achieve diversity across i) level of government (local, regional, national), ii) nationality (west, east, mid, north, south Europe), iii) scope (goals and vision), and iv) maturity (size and age). The sampling was performed in collaboration with the study’s commissioning body, which was interested in a diverse, broadly representative panel. To enable cross-analysis and provide context, cases were chosen within four initial clusters referring to local, regional and national levels of government, and Academia, with additional information collected as available and possible to further inform the sampling process. While our focus is on public sector OSPOs, we made an exception by including Code for Romania, a civil-society organisation that supports governments at all levels in Romania in adopting OSS solutions, thereby acting as an external OSPO-like function for Romania and providing an interesting case to compare and contrast with.

As these clusters evolved into what the study refers to as OSPO archetypes in section 4, four additional cases were included from the previously collected population (resulting in 16 included cases in total) to facilitate contrast and comparison within the different clusters. An exception was the Organisations with OSPO-like support functions archetype, which is only represented by the case of Code for Romania, as we did not find a comparable entity in our population. The decision not to include any further cases was influenced by both the availability and knowledge of potential corresponding cases, as well as the limited time and resources available for the execution of this study. A brief description of each case is provided in Appendix A.

3.2.2 Data collection

For each case, 1-2 interviews were conducted with key individuals, resulting in a total of 17 interviews with 18 individuals. Two representatives from the French Public Employment Service’s OSPO were interviewed in the same session, and two from the European Commission’s OSPO at separate occasions. As this is an interview survey aiming for breadth rather than depth, we limited ourselves to only one interview per case, except for the two aforementioned cases where the case organisations themselves encouraged the inclusion of two interviewees to cover appropriate perspectives. It may be noted, however, that all OSPOs were limited in size, and our sampled individuals maintained key positions, typically with overall responsibility of concerned OSPOs.

A comprehensive overview of the interviewees is provided in Table 3 below. The interviews were semi-structured, allowing for digression in topics as the interviews progressed. This flexibility allowed us to capture additional nuance, context, and examples that might have otherwise been overlooked. The interview questionnaire (see Appendix B) was based on the conceptual framework derived from practice in research cycle one and primarily consisted of open-ended, exploratory questions aimed at addressing the defined main research questions. Questions under section B.1. connects to RQ1, and questions under B.2-11 relates to RQ2, and more specifically the structural attributes and responsibilities defined in our initial conceptual framework as defined in Fig. 1.

The interviews lasted approximately 1 hour and were conducted and recorded online via Teams, Google Meet, Zoom, or Jitsi, pending the preference of the interviewee. The interviews were conducted by two researchers: the lead researcher led the interviews, and the second researcher took notes and asked follow-up questions as needed. The recordings were automatically transcribed using either built-in or third-party services. These transcriptions were then cleaned and processed to ensure readability and accuracy. Processed transcriptions were sent to the respective interviewees, along with a summary of the main findings, to validate the accuracy and make any necessary revisions or retractions.

Interviewees were provided with upfront information about the study’s background, design, and publication process, as well as the data collection and management processes used. They were offered the opportunity to ask clarifying questions about the process throughout the study. Each interviewee remains anonymous by name but is referred to by a generalisable and appropriate title.

3.2.3 Data analysis

Statements in the transcripts were coded in a stepwise sequence during the data analysis phase. Initially, structural coding  [54] , a first-cycle coding method, was applied to organise the text data from the transcripts based on an a-priori code book consisting of the codes relating to the conceptual framework elicited in cycle 1:

Structure-related codes (RQ1):

• 1.

Goals of the OSPO: Benefits, value, and defined business and policy goals or objectives for OSS.

• 2.

Organisation of the OSPO: Organisation, internal sponsor, staffing, and budget of the OSPO.

• 3.

Supporting entities: Main stakeholders, entities, or individuals that are supported internally or externally by the OSPO.

Responsibility-related codes (RQ2):

• 1.

Develop and Execute OSS Strategy

• 2.

Oversee OSS Compliance

• 3.

Establish and Improve OSS Policies and Processes

• 4.

Prioritise and Drive OSS Upstream Development

• 5.

Collaborate with OSS Organisations

• 6.

Track Performance Metrics

• 7.

Implement Inner Source Practices

• 8.

Grow and Retain OSS Talent Inside the Organisation

• 9.

Provide Advice and Support on OSS

• 10.

Manage Open Source IT Infrastructure

Structure-related codes are further defined in Section 2.2, and responsibility-related codes in Section 2.4.

The structured data was then coded using open coding, another first-cycle coding method used to inductively capture emerging trends or concepts in qualitative data  [54] . Transcript excerpts were accordingly assigned inductive codes along with short descriptive notes summarising the main findings in the statements. The open codes and notes were continuously grouped using an axial coding approach (a second-cycle coding method  [54] ), and the a-priori codebook. The process rendered in the revised structural attributes (RQ1) and responsibilities (RQ2) presented in Fig. 3. Finally, selective coding, a second-cycle coding method  [54] , was used to further synthesise data across the codebook into six common archetypes:

• 1.

National-Government OSPOs

• 2.

Institution-centric OSPOs

• 3.

Local government OSPOs

• 4.

Association-based OSPOs

• 5.

Academic OSPOs

• 6.

Organisations with OSPO-like support functions

Accordingly, each OSPO archetype is defined through its structural attributes (RQ1) and responsibilities (RQ2) as visualised in Fig 3, representing our posteriori code book. The archetypes are further described in Section 4.

3.3 Research cycle three: Focus Groups

Focus groups were used to further validate and explore the OSPO archetypes and the synthesised analysis from the semi-structured interview survey  [25] .

3.3.1 Data Collection and Analysis

Two focus groups were planned to provide sufficient coverage and detailed validation of the different archetypes. The first focus group focused on the cases within the three OSPO archetypes: National Government, Institution-centric, and Academic OSPOs. Out of ten invitations, seven participants attended, including former interviewees (I2-DEVIT, I4-LUX, I5-EC, I6-EC, I17-TRIN) and an external participant (I19-AUST). The second focus group focused on the three remaining OSPO archetypes: Local Government, Association-based, and Organisations with OSPO-like support functions. Of ten invitations, three participants attended, including one former interviewee (I11-OS2) and two external participants (I20-MUN and I21ECH).

In each focus group, participants were presented with a background on the study, followed by overviews of the different OSPO responsibilities characterised by the relevant OSPO archetypes, as well as the challenges and drivers identified in the studied cases. After each overview, the research team facilitated an open discussion among the participants. Each focus group lasted for 90 minutes, was recorded, and transcribed. Transcripts were analysed using a similar coding approach used in the second research cycle. No new high-level codes emerged through the analysis, but served as a validation of existing findings.

3.4 Threats to Validity

Since a qualitative research approach was adopted, a set of criteria for naturalistic inquiries proposed by Guba  [20] was utilised for discussing and evaluating the threats to validity of the study. These criteria include credibility, transferability, dependability, and confirmability.

3.4.1 Credibility

Credibility pertains to the truth value of the presented findings. To enhance this aspect, member checking was conducted, allowing each interviewee to correct, add, or retract any statements in the transcripts, as well as reviewing the full report before being published. Additionally, the researchers behind this study engaged in continuous discussions and peer debriefings to maintain situational awareness of their observations and the perceived level of saturation among the different OSPO archetypes.

The follow-up focus groups further contributed to strengthening this aspect of validity. It may be noted that the second focus group only collected three participants. Yet, all three participants were experienced, and two were external and new to the data, why we consider their input as valuable and still a partial validation of the findings, beyond other efforts such as the member checking process.

3.4.2 Transferability

Transferability concerns whether and how the presented findings can be applied to other cases beyond those studied. Since this is a qualitative and exploratory study, based on a limited sample of public sector OSPOs, the aim is not to make generalisations about an entire population. Instead, the goal is to develop an understanding of the problem context and generate knowledge that can be valuable for practitioners operating within this context. Consequently, readers must consider the context from which the data was collected to enable any anecdotal generalisations. Quotes from the interviews were used consciously to provide rich and contextually detailed findings.

Purposive sampling is another method that was employed to ensure the transferability of the results. The initial mapping yielded a broad sample of the overall population of PSOs with OSPOs (or OSPO-like functions) in place (see Appendix B). From this sample, sixteen cases were selected based on criteria aimed at achieving as wide a representation as possible.

3.4.3 Dependability

Dependability refers to the reliability of the results in terms of their replicability and traceability throughout the chain of evidence. To enhance this aspect, an audit trail was maintained throughout the data analysis and collection process. This documentation covers all stages of the research process, from the conceptual framework through the mapping, interview survey, and focus groups.

3.4.4 Confirmability

Confirmability relates to the extent to which the presented findings were objectively derived. In this regard, investigator triangulation  [20] , i.e., the involvement of multiple researchers, was leveraged throughout the research design and implementation process to ensure neutrality and reduce the risk of introducing researcher bias. This approach includes several steps aimed at maintaining research focus and a clear chain of evidence, from the initial assumptions to the design of the questionnaire and the iterative coding process.

4 OSPO archetypes

Our study investigates 16 cases of public sector OSPOs distributed across six different OSPO archetypes: National Government, Institution-centric, Local Government, Association-based, and Academic OSPOs. These archetypes, or categories, emerged organically through the investigation as additional cases were included. The archetypes can be further defined in terms of their structural attributes (answering RQ1), and responsibilities (answering RQ2), as visualised in Fig. 3. The structural attributes are presented per archetype in Table 3.

The latter two of these archetypes, the Academic and Organisations with OSPO-like support functions, to various degrees falls outside of the scope of this study which is to investigate OSPOs within the public sector. Regarding Academic OSPOs, these can be located both within private and public academic institutions. In this study, however, the sample is limited to public academic institutions. In terms of Organisations with OSPO-like support functions, this archetype falls outside of the public sector. Yet, the case and archetype is still included as one of its goals is to support the public sector, and it demonstrates an alternative model that is pursued in some jurisdictions, and the potential benefits and drawbacks of this approach.

The different OSPO archetypes are characterised in the subsequent subsections by comparing and contrasting the different cases of OSPOs in terms of the nine responsibilities as defined in Fig. 3.

The responsibility of “Developing and managing key OSS applications” emerged from the production and co-development of critical applications needed by larger parts of the public sector beyond the focal PSO where an OSPO is hosted. This responsibility was especially apparent in the cases of Local Government and Association-based OSPOs. Also worth noting is that the focus, content, and presence of each responsibility will differ per OSPO archetype depending on the needs and goals of the OSPO, the level of government, its maturity, budget, and capabilities.

4.1 National government OSPOs

National government OSPOs are hosted by PSOs, such as those responsible for matters related to digital government and transformation. These range in size and budget between smaller 2-4 people teams with a focus on general support, to larger 70+ people organisations which are more engineering-focused. Competencies typically include OSPO management, legal, community management, and engineering. In this study, four cases of such OSPOs were investigated:

• 1.

Free Software Unit at the French Interministerial Digital Directorate (Direction interministérielle du Numérique - La DINUM)

• 2.

Developers Italia at the Department for Digital Transformation (Dipartimento per la Trasformazione Digitale)

• 3.

Centre for Digital Sovereignty (Zentrum Digitale Souveränität)

• 4.

Luxembourg House of Cybersecurity OSPO at the Ministry of the Economy (Ministère de l’Économie)

4.1.1 Providing support for design and execution of OSS strategies

A central responsibility of National government OSPOs is to enable the operationalisation of high-level OSS strategies and policies determined by policymakers. The OSPOs act as mediators between legislative intent and practical implementation, translating legal or political mandates into actionable processes for PSOs. Through their coordinating role, OSPOs ensure that OSS is systematically considered in software procurement and development, while also providing guidance to support the drafting of further specialised OSS strategies within their remit, even if such tasks are less common due to varying degrees of adoption.

For example, in France, Italy, and Germany, national legislation and coalition agreements require PSOs to include OSS as a candidate when acquiring or procuring new software, and mandate that newly developed OSS is considered for release under OSS licences. The OSPOs, in turn, may support other PSOs within their scope to draft their own OSS strategies. This is yet an uncommon task, most probably due to the (in relative terms) limited adoption of OSS.

4.1.2 Providing support for use and adoption of OSS

A common practice for National government OSPOs (noted across German, French, and Italian cases) is the establishment and maintenance of centralised knowledge-sharing platforms that serve as repositories and facilitators for OSS within the public sector. These platforms help to systematically index OSS solutions of relevance to and used by PSOs, ideally by leveraging standardised metadata standards such as public-code.yml 14 14 14 https://yml.publiccode.tools/ to ensure consistency and ease of use. As put by I3-ZEN:

“We are often having the situation where things are developed in one end of Germany, and you’re not aware of what’s happening in the other end.” - I3-ZEN

Further, by codifying knowledge related to software selection, procurement, and adoption, National government OSPOs provide a critical resource that supports informed decision-making and lowers technical barriers. The Italian OSPO, for example, complements its platform with detailed procurement guidelines that assist public administrations in evaluating OSS projects from both technical and cost perspectives. In addition to the platforms and codified knowledge, OSPOs offer direct, capacity-dependent assistance to PSO engaging with OSS. This support is often limited to to resource constraints but is pivotal to use and interpret resources shared by the OSPOs.

4.1.3 Providing support for development and release of OSS

National government OSPOs play an important role as facilitators of OSS development and release within the public sector. They create integrated infrastructures that provide repositories for publishing OSS projects, and help to foster the conditions necessary for reuse and the growth of vibrant developer communities. The aforementioned knowledge-sharing platforms and software catalogues enable PSOs to contribute, discover, and collaborate on OSS initiatives. Communication mechanisms, ranging from integrated chat platforms to dedicated code hosting environments, serve as essential enablers for building and sustaining the social and technical collaborations fundamental to the success of OSS projects. Complementary to technological infrastructure, national OSPOs provide guidance through documentation, standards, and practical support, ensuring consistency and quality in OSS releases.

For example, the German OSPO’s knowledge-sharing platform includes a dedic...