Zum Inhaltsbereich wechseln
English
Auf dem Laptop-Bildschirm ist verschiedenfarbige Schrift der Plattform GitHub zu sehen. An den Bildschirm gelehnt ist eine Karte. Auf dieser steht groß „Open by Default“, darunter in kleiner Schrift „Arbeite offen“.

Open Source: Warum – und wie?

Alle Software-Projekte des DigitalService werden als Open-Source-Lizenzen entwickelt. Warum? Weil wir mit öffentlichen Geldern arbeiten und damit auch unsere Ergebnisse öffentlich zur Verfügung stellen wollen. „Public money, public code“ nennen viele das Konzept. In der Privatwirtschaft sind Open-Source-Lizenzen lange etabliert. Die Verwaltungs­landschaft tut sich damit hingegen noch schwer – trotz eigentlicher Selbstverpflichtung dazu. Im Folgenden möchten wir erklären, welche Vorteile wir in Open Source sehen, wie wir Sicherheit garantieren und was andere beachten sollten, wenn sie Open Source entwickeln wollen.

OSS und Verwaltung: noch Luft nach oben

Von vorne: Was ist Open-Source-Software (OSS)? Als Open Source bezeichnet man Software, deren Quellcode öffentlich zugänglich ist, sodass jede:r den Code einsehen, verwenden, verändern und weiterverbreiten kann.

Das Prinzip ist gut – und nicht umsonst ist OSS auf einem aufsteigenden Ast: So gibt es auf EU-Ebene bereits bedeutende Initiativen wie das Open Source Observatory (OSOR), das eine zentrale Anlaufstelle für Informationen und Ressourcen rund um Open-Source-Software im öffentlichen Sektor darstellt. Das Ziel ist es, die Zusammenarbeit zwischen den EU-Mitgliedstaaten zu fördern und den Austausch bewährter Praktiken zu erleichtern. Darüber hinaus hat die Europäische Union im Rahmen ihrer Open-Source-Strategie klare Leitlinien entwickelt, die den Einsatz und die Weiterentwicklung von Open-Source-Software in öffentlichen Institutionen fördern sollen.

Auch in Deutschland hat Open Source zunehmend an Bedeutung gewonnen. Im aktuellen Koalitionsvertrag heißt es: „Entwicklungsaufträge werden in der Regel als Open Source beauftragt, die entsprechende Software wird grundsätzlich öffentlich gemacht.“ In der Realität passiert das aber leider noch nicht genug, viel Entwicklungsarbeit passiert weiterhin hinter verschlossenen Türen.

Die Initiative OpenCoDe, betrieben vom Zentrum für digitale Souveränität (ZenDiS), bietet eine Plattform, auf der Software-Lösungen der öffentlichen Hand geteilt und gemeinsam weiterentwickelt werden können. Das kann ein (weiterer) Startschuss sein, damit OSS in der Verwaltung richtig ankommt.

Vier Leute sitzen um einen Tisch herum mit ihren Laptops. Auf dem vorderen Bildschirm sieht man Codezeilen. Im Hintergrund sitzt ein Mann und lächelt nach rechts eine Person am Tisch an, deren Gesicht nicht zu sehen ist. Links von dem Mann schaut eine Frau auf ihren Bildschirm.

Vorteile: Vertrauen und Feedback gewinnen

Als DigitalService möchten wir hier ein Zeichen für Open Source setzen und in die unserer Meinung nach richtige Richtung vorangehen. Wir sind der festen Überzeugung, dass Software, die mit öffentlichen Geldern finanziert ist, später auch öffentlich sein sollte.

OSS bedeutet daher für uns: Wenn wir Projekte mit Bundesministerien und -behörden initiieren, legen wir bereits in der Ausarbeitung des Vertrags Wert darauf, dass einer unserer zentralen Unternehmenswerte gewährleistet ist: „Open by default“ (Arbeite offen). Diese Verträge legen wir übrigens – nach Möglichkeit – sogar ganz offen. Beispiele für Projektverträge finden sich auf unserer Transparenzzeite.

Für die Projekte selbst bedeutet das, dass wir all unseren Quellcode wie auch unsere Vorgehensweisen mit der Öffentlichkeit teilen. Mit Blick auf den reinen Code tun wir das, indem wir unsere gesamte Entwicklungsarbeit öffentlich auf der Plattform GitHub stattfinden lassen. Anstatt im Nachgang den fertigen Code hochzuladen, arbeiten unsere Entwickler:innen von Beginn an offen auf GitHub, lassen sich sozusagen bei der Arbeit digital über die Schulter schauen. Aktuell teilen wir 60 Repositorys mittels unseres GitHub-Profils mit der Öffentlichkeit. Die Mehrheit der Repositorys verfügen über eine Dokumentation in Form einer README.md-Datei und einen Code of Conduct. Das ermöglicht es uns, ganz praktisch von Feedback aus der Fach-Community zu lernen. Wir laden so nämlich andere Entwickler:innen aktiv dazu ein, sich mit unserem Code auseinanderzusetzen und uns darauf aufmerksam zu machen, was wir noch verbessern können. Dieser Austausch ist für uns besonders wertvoll.

Auch, wenn wir nicht immer überall und stetig Feedback bekommen, so senden wir mit der Offenlegung des Codes aber gleich mehrere Signale in die IT-Community, an interessierte Nutzende und auch die Verwaltung: Wir wollen offen arbeiten und wir wollen, dass aus den Steuergeldern, die für unsere Projekte aufgewendet werden, das Bestmögliche für die Bürger:innen herausspringt. Wir laden andere Stakeholder:innen ein, unseren Code zu nutzen und für ihre Zwecke anzugleichen. Gleichzeitig zeigen wir transparent, was wir mit den Mitteln, die uns zur Verfügung gestellt werden, gestalten.

Wir überprüfen selbst auch regelmäßig, ob unsere Projekte unseren Ansprüchen von Transparenz und Offenheit gerecht werden. Dafür kontrollieren wir uns selbst anhand des Servicestandards, einem Leitfaden für gute digitale Entwicklungspraxis: Diese Selbstaudits veröffentlichen wir ebenfalls. Wer mehr über den Servicestandard und unsere Arbeit mit und um das Tool erfahren möchte, findet im Blog „Wie der Servicestandard die Entwicklung digitaler Verwal­tungs­services unterstützt“ Informationen.

Wie Organisationen Open Source implementieren können

Für Unternehmen, die den Schritt in Richtung Open Source wagen wollen, gibt es einige wichtige Aspekte zu beachten.

Zunächst muss natürlich das Geschäftsmodell zu Open Source passen. Ein Vorteil darin, dass wir öffentlicher Akteur sind, ist nämlich, dass wir unseren Quellcode nicht aus proprietären Gründen schützen müssen, sondern den von öffentlichen Geldern finanzierten Code auch wieder mit der Öffentlichkeit teilen können.

Unternehmen, für die der Verkauf von Software zentrales Geschäftsmodell ist, geben damit natürlich ihre Inhalte, Patente beziehungsweise ihre Intellectual Property (IP) frei. Die Bereiche Dienstleistungen, Support und maßgeschneiderte Entwicklungen können durch OSS jedoch an Bedeutung gewinnen.

Entscheidet man sich trotzdem für OSS, dann sollte man direkt eine Klarheit über die Zielsetzung gewinnen. Warum soll der Code veröffentlicht werden? Ist das Unternehmen bereit, die notwendigen Fragen zu beantworten und die Veröffentlichung kommunikativ zu begleiten?

Mögliche Zielsetzungen:

  • Vertrauen gewinnen: Offener Code ermöglicht es Dritten, die Qualität und Sicherheit der Software zu überprüfen.
  • Wiederverwendung ermöglichen: Andere können den Code nutzen, anpassen und weiterentwickeln, was zu einer besseren Nutzung von Ressourcen führt.
  • Zur bestehenden Software beitragen: Unternehmen können bestehende Open-Source-Projekte durch eigene Beiträge unterstützen.
  • Partizipation ermöglichen: Durch die Öffnung des Codes wird eine breitere Beteiligung der Fach-Community ermöglicht. Diese Bürgerbeteiligung sollte vor allem im Interesse des Staates sein.

Klar muss sein: Eine erfolgreiche Open-Source-Strategie erfordert die volle Unterstützung des Managements. Transparenz bedeutet, dass jede Person den Code einsehen kann, was eine sorgfältige Dokumentation und Bereitstellung des Codes voraussetzt. Es ist entscheidend, dass die Leitungsebene nicht nur die Idee unterstützt, sondern auch die notwendigen Ressourcen für OSS bereitstellt. Dies umfasst sowohl Zeit für die Dokumentation als auch die technische Infrastruktur, beispielsweise durch die Nutzung von Plattformen wie GitHub oder OpenCoDE.

Mehrere gelbe und blaue Kabel stecken in einem Verteiler. Darauf klebt ein Sticker mit dem DigitalService-Logo und ein Sticker mit der Aufschrift „Rocky road to change“.

Dinge, die es vorab zu klären gibt

Neben der Zielsetzung und der Unterstützung durch die Geschäftsführung – und natürlich auch durch den Auftraggeber – gibt es weitere praktische Überlegungen, die bei der Implementierung von Open Source eine Rolle spielen:

  • Plattformwahl: GitHub ist eine weitverbreitete Plattform für die Veröffentlichung von Open-Source-Software. Die Verwaltung arbeitet mit dem eingangs erwähnten OpenCoDE, was auf GitLab aufbaut, aktuell an einer eigenen Alternative.
  • Lizenzauswahl: Die Wahl der richtigen Lizenz ist entscheidend. Der DigitalService nutzt die MIT-Lizenz, eine der offensten Lizenzen überhaupt. Eine Alternative könnte eine harmonisierte EU-Lizenz sein. Zusätzlich kann das ZenDiS Know-how auch in diesem Feld angefragt werden.
  • Transparenz sicherstellen: Es sollte klar sein, wer hinter den Code-Änderungen steht. Wir stellen das sicher, indem alle Entwickler:innen ihre Commits signieren.
  • Dokumentation: Gute Software lebt von guter Dokumentation und Klarheit. Hierbei sollte man sich im Voraus die Frage stellen: „Was bräuchte ich, wenn ich die Software selbst nutzen wollen würde?“
  • Kommunikation und Engagement: Neben der technischen Veröffentlichung ist es wichtig, über die Open Source-Ansätze zu informieren und Aktivitäten dazu zu planen. Ansprechpartner:innen für Sicherheit und Pflege des Codes müssen benannt werden.

Fazit: einfach anfangen!

Der Einstieg in Open Source muss nicht kompliziert sein. Wichtiger als jahrelange Planung ist der erste Schritt. Organisationen und vor allem Akteure im Verwaltungsumfeld sollten einfach beginnen und Erfahrungen sammeln. Wer noch Fragen zu OSS hat, kann jederzeit unter hallo@digitalservice.bund.de mit uns in den Austausch kommen. Außerdem laden wir alle Interessierten herzlich zu unserer NExT-CommunityOpen Source in der Verwaltung“ ein.


Porträtfoto des Autors Christian Kaatz

Christian Kaatz

ist Head of Engineering beim DigitalService. Während seines Studiums hat er Stadtpläne in Äthiopien angefertigt, bevor er dann bei Nokia und HERE unter anderem in den Bereichen Data Engineering, Backend und APIs tätig war. Christian ist Papa von zwei Kindern und nutzt jede freie Minute, um mit ihnen gemeinsam die Natur zu entdecken – gerne auch in den Gemeinschaftsgärten auf dem Tempelhofer Feld.

Porträtfoto des Autors Benedikt Liebig

Benedikt Liebig

ist Product Manager beim DigitalService. Er war Fellow der Tech4Germany Kohorte 2020. Seitdem unterstützt er die digitalen Vorhaben der Verwaltung – mit einer iterativen, datengetriebenen und human-zentrischen Sichtweise. Er schafft Räume, in denen Verwaltung, Design, IT und Recht als Team interdisziplinär und mit Spaß an einem Service arbeiten. Privat ist Bene viel mit seinem Rennrad unterwegs und engagiert sich für einen klimaresistenten Wald.


Mehr zum Thema lesen