Section 2: Key Issues and Concepts in Building an Open Source Ecosystem #

An Organization that Enables Open Source #

Open source software requires that individuals across different governmental business units, departments and agencies build new skills and adapt their day to day role in order to effectively support open source software. This includes individuals working in digital services, IT, any number of direct service delivery departments (e.g. traffic and parking), procurement, budgeting or accounting, legal, and other functions across and within organizations.

Everyone involved needs to be able to: ask the right questions, identify the right outcomes, and have a basic knowledge of the fundamental principles of modern software design.¹

In-House Skills and Expertise #

Technical staffing is one of the greatest perceived barriers to open source software adoption. Because open source software requires active involvement from the user (as opposed to proprietary software, which is serviced and maintained by the vendor), many assume that it is inaccessible without software development capabilities.

Conversely, many assume that obtaining proprietary software from a vendor means they don’t need technical experts on staff. Without in-house expertise, however, the processes of contracting, procuring and implementing proprietary software can have harmful outcomes. Without adequate knowledge of data ownership and monetization, a proprietary software contract can end up disempowering the public sector in the long term (see Module 3).

Clients – government in particular – rely on software vendors for ongoing support. In the case of proprietary software, there is no choice. The source code is hidden and proprietary, so the vendor is the only party with access. In the case of open source software, anyone can contribute, but there is no single vendor. Governments need to have capacity in-house, collaborate with peers, or hire a provider that can offer support.

Staff Roles to Support Open Source Software #

It is possible to undertake open source software projects without formalized roles. However, this approach may not be sustainable in the long run if your organization’s open source ‘champions’ become unable to drive open source software efforts off the side of their desks in addition to their formal job requirements.

Ideally, you will be able to draw on the skills and expertise of several different roles when embarking on an open source software initiative (see Table 2.1). These roles step into the foreground or background, depending on the specific phase – and once again, not all of these roles need to be in-house or full-time.

Table 2.1: Roles involved in each phase of an open source software initiative, Involvement by Phase

* Indicates a role that can exist outside of your organization (e.g. within a peer jurisdiction or contracted through a vendor)

Breaking Down Departmental Silos #

A systemic lack of collaboration between departments and business units can impact open source software adoption. This can happen for a couple of reasons:

• Departments may have divergent or conflicting agendas, which can cause misalignment in priorities and friction before and during the software procurement and development process.

• Software often falls between existing business unit siloes (for example legal, IT, service delivery, budgeting and procurement), which can make it difficult to determine who actually owns a process. This is especially true with new or unconventional processes.

Transitioning to cross-departmental protocols and standards requires process change management that is independent of the implicated departments.

Many large private sector firms have established Open Source Program Offices (OSPOs) as a clearinghouse for all things open source within the organization. This can include: “developing collaborations with foundations/organisations and OSS communities, ensuring legal compliance, developing and implementing OSS strategies, launching new projects, providing training, providing guidance to employees on how they could engage in OSS activities and others.”²

Some governments and public sector institutions are now adopting the same approach, including the European Commission which created its Open Source Program Office in October 2020. Ultimately, the value of an organizational structure like an OSPO is to move governments beyond simple enactment of high-level policies and towards ensuring “their enforcement and maintenance in a more horizontal, strategic manner coupled with ensuring [their] implementation in a daily practice.” ³

• Previous
• Next