With this page, we want to help public administrators on setting up their own OSPOs and encourage them to share their experiences with the community. You can join the OSOR collection and publish your articles here, or send us an email to EU-OSOR[at]ec.europa.eu.
Jump to:
FAQ
The role of an OSPO is to align the objectives of open source development or procurement with the wider strategy of the public entity. It supports and accelerates the consumption, creation, and application of open source software. OSPO also coordinates efficiently different departments, external ecosystems, and other stakeholders.
An OSPO can thus help ensure that public administrations get the most benefit from open source software.
OSPOs ensure coordination between legal, technical and strategic IT policy and they combine this with OSS expertise. With this coordination, processes can be better adapted to the workflows of IT staff. An OSPO can also assist the organisation in participating directly in OSS projects, thus bringing the possibility of the organisation having input into future development of the project and having access to more information about the software.
OSPOs also communicate externally. By engaging with the developer communities and citizens, the OSPOs promote the organisation and can demonstrate a commitment to transparency and secure processing of data.
OSPOs can also bring financial benefits by making use of possibilities that become available when an organisation uses OSS. Taking control of the software by having software developers working directly on the code is one option. Building new features on top of existing OSS, instead of starting a project from scratch, is another option. And collaborating with other public administrations to pool resources and share the benefits is another. By creating these links and ensuring code sharing, the OSPOs make sure the taxpayers money is used in the best possible way.
The mandates and functions of an OSPO will differ depending on the organisation and its goals, and the needs of public-sector OSPOs can be different from private-sector OSPOs. The most important thing is to ensure that the OSPO supports the wider organisational strategy.
For example, the functions of public-sector OSPO can include
- Ensuring legal compliance in coordination with the legal department
- Support different teams in launching new software projects using open source
- Developing and implementing OSS strategies with the IT department and management
- Set goals or KPIs for open source usage and measure the metrics and success
- Create funding programs for OSS
- Provide training and guidance for employees
- Ensure the secure consumption and contribution to externally developed code
- Support the procurement of OSS products
- Engage with the OSS communities and manage the diversity of stakeholders in the ecosystem
You can find information about how to build your OSS community and set up an OSPO on OSOR info page “Building your own public sector OSS community”, which is a part of the OSOR "Guidelines for creating sustainable open source communities" - there you can find many chapters discussing the topic in detail. For practical support and tips for tackling challenges, you can also connect with other public administration open source experts through the Open Source Observatory.
To set up a successful OSPO, the organisation needs to identify what strategic goals the OSPO can support. Set tangible key performance indicators. This will later help you measure success and demonstrate to colleagues and management how OSPO can bring benefit to the organisation.
The OSPO does not need to be large at the beginning. You can start with a few people working on key actions and expand later. Building the structure takes time. As legal compliance plays a big part in software ecosystems, the staff who work on legal support for IT systems should be included from the beginning. When your OSPO has developed further, you can get staff from other departments involved.
It is useful to try to work with the open source community from the beginning. Building relationships can take time and the possibilities are much broader—an organisation may have the possibility to interact directly with developers, or with multiple service providers or even with other public administrations who are also interested in that OSS project. This helps to shape your organisation’s culture from the start towards open source best practices.