Skip to main content
Deutsch
The GitHub platform is displayed in different colors on a laptop screen. A card is leaning against the screen. It says “Open by Default” in large letters and German translation in small letters underneath.

Open source: Why – and how?

All DigitalService software projects are developed under open source licenses. Why? Because we work with public money and, therefore, want to make our results publicly available. Many call this concept “public money, public code.” Open source licenses have long been established in the private sector. The administrative landscape, on the other hand, is still struggling with this – despite a voluntary commitment. In this article, we explain the advantages we see in open source, how we ensure security, and what others should keep in mind if they want to pursue open source development.

OSS and federal public administration: room for improvement

Let’s start with the question: What is open source software (OSS)? Open source software refers to software whose source code is publicly available and can be viewed, used, modified, and distributed by anyone.

The principle is sound – and this is reflected in the upward trajectory in OSS adoption: at EU level, for example, there are already important initiatives such as the Open Source Observatory (OSOR), which serves as a central point of access to information and resources in respect of open source software in the public sector. It aims to foster collaboration between EU Member States and facilitate the exchange of good practice. In addition, the European Union has set out clear guidelines as part of its open source strategy with the intention of promoting the use and further development of open source software in public institutions.

In Germany, too, open source is an increasingly important topic. The current coalition agreement states: “As a rule, development contracts are commissioned as open source, the corresponding software is made public as a matter of principle.” In reality, however, this has not yet been adequately achieved and a lot of development work is still taking place behind closed doors.

The OpenCoDE initiative run by the Center for Digital Sovereignty (ZenDiS) offers a platform for sharing public sector software solutions and collaborating on their further development. This may serve as a(nother) catalyst to ensuring that OSS is well-received in public administration.

Four people are sitting around a table with their laptops. Lines of code can be seen on the front screen. A man sits in the background and smiles to the right at a person at the table whose face is not visible. To the left of the man, a woman is looking at her screen.

Benefits: Increased trust and feedback

At DigitalService, we want to signal our support for open source and move in what we believe is the right direction. We are deeply convinced that publicly funded software should also be made publicly accessible.

OSS therefore means to us that right from the contracting stage of any projects we initiate with federal ministries and authorities, it is important to us that we ensure we are meeting one of our key corporate values: “Open by default.” Where possible, we even make these contracts entirely accessible. Examples of our project contracts can be found on our Transparency page.

For the projects themselves, this means that we publicly release all of our source code and show our approach. In respect of the pure code, we do this by conducting all of our development work on the GitHub platform, where it is available for public access. Instead of uploading the final code at the end, our developers work openly on GitHub from the outset – so that anyone can digitally observe their process. At this moment in time, we are sharing 60 repositories with the public via our GitHub profile. The majority of these have documentation in the form of a README.md file and a Code of Conduct. This allows us to learn at a very practical level from feedback provided by the expert community. In this way, we actively invite other developers to take a look at our code and let us know what we could improve further. These interactions are especially valuable for us.

Even if we are not constantly receiving feedback on everything we do, by disclosing our code we are still repeatedly signaling to the IT community, interested users, and public administrations that we want to work transparently and we want citizens to get the most value from the taxpayer money spent on our projects. We welcome other stakeholders using our code and modifying it to suit their needs. At the same time, we are openly demonstrating what we are creating with the funds that are put at our disposal.

We also regularly check that our projects meet our standards of transparency and openness. To this end, we audit ourselves based on the Servicestandard, a guideline for good digital development practices, and we publish these self-audits. If you would like to learn more about the Servicestandard and our work with and around the tool, please see our blog post “How the Servicestandard supports the development of digital government services”.

How organizations can implement open source

Organizations keen to embrace open source should bear in mind a number of important aspects.

Firstly, it goes without saying that the business model must be compatible with an open source approach. One advantage we have as a public entity is that we don’t have to protect our source code on proprietary grounds but can instead share the publicly funded code with the public.
Organizations for which software sales are crucial to their business model would then, of course, be giving up their content, patents, and intellectual property (IP). However, the areas of services, support, and custom development can take on greater importance with an OSS approach.

If an organization chooses to go open source, then it should be clear about its objective right from the outset: Why do we want to publish our code? Is our organization ready to answer the necessary questions and engage in the communication associated with such a measure?

Possible objectives:

  • To build trust: Open code allows third parties to examine the quality and security of the software.
  • To enable reuse: Others can use, modify, and further develop the code, leading to better usage of resources.
  • To contribute to existing software: Organizations can make their own contributions in support of existing open source projects.
  • To enable participation: Publishing the code allows the expert community to play a broader role. This public participation should be primarily aligned with the state’s interests.

It must be clearly understood that full managerial support is needed for a successful open source strategy. Transparency means that anyone can view the code, and this necessitates careful documentation and release of the code. It is crucial that leaders not only support the idea of OSS but also provide the necessary resources. This includes time for documentation work as well as the technical infrastructure, for example through the use of platforms like GitHub and Open CoDE.

Several yellow and blue cables are plugged into a distributor. A sticker with the DigitalService logo and a sticker with the words “Rocky road to change” are stuck to it.

Key points that need to be clarified in advance

In addition to the objective and support from management – as well as the client, of course – other practical considerations play a role in open source implementations:

  • Platform selection: GitHub is a widely used platform for publishing open source software. With Open CoDE (mentioned above), which builds on GitLab, public authorities are currently working on their own alternative.
  • License selection: Choosing the right license is very important. DigitalService uses the MIT License, one of the most permissive licenses available. A harmonized EU license could be an alternative. In addition, ZenDiS has know-how in this field that can be accessed upon request.
  • How to ensure transparency: It should be clear who is behind any changes to the code. We ensure this by having all developers sign their commits.
  • Documentation: Good software requires good documentation and clarity. For this, you should ask yourself in advance: “What would I need if I wanted to use the software myself?”
  • Communication and engagement: In addition to publishing the code and technical documentation, it’s important to provide information on the open source approaches and to plan related activities. There must be designated individuals responsible for the security and upkeep of the code.

In conclusion, just get started!

Getting started with open source need not be complicated. Taking the first step is more important than years of planning. Organizations and, in particular, public administration stakeholders should simply get the ball rolling and gain experience. If you still have questions about OSS, don’t hesitate to reach out to us at hallo@digitalservice.bund.de. All interested parties are also warmly invited to join our “Open Source in Public Administration“ NExTcommunity.


A portrait photo of Christian Kaatz

Christian Kaatz

is Head of Engineering at DigitalService. During his studies, he created city maps in Ethiopia before working at Nokia and HERE inter alia in the fields of data engineering, backend and APIs. Christian is the father of two children and uses every free minute to discover nature with them – including in the community gardens at Tempelhofer Feld.

A portrait photo of Benedikt Liebig

Benedikt Liebig

is a Product Manager at DigitalService. He was a fellow of the 2020 Tech4Germany cohort. Since then, he has been supporting the digital projects of federal public administration – with an iterative, data-driven, and human-centric view. He creates spaces in which administration, design, IT, and law work as a team in an interdisciplinary and fun way to provide a service. In his personal life, Bene is often on the road with his racing bike and is committed to a climate-resistant forest.


Read more on the topic