Seit einigen Jahren gibt es immer mehr Bestrebungen, Open Source Software (OSS) in allen Bereichen zu nutzen, in denen es möglich ist. In Richtlinien zur Vergabe öffentlicher Projekte finden immer häufiger Klauseln Einzug, welche die Realisierung als Open Source Software vorsehen (Open Source in der Öffentlichen Verwaltung). Die vom Fraunhofer IESE im Themengebiet Smart City bearbeiteten Projekte weisen häufig diese Förderrichtlinie auf, da hier oft dem Credo »public money, public code« gefolgt wird. Neue Projekte in diesem Bereich müssen oft von Anfang an mit dem Gedanken an eine Open-Source-Veröffentlichung entwickelt werden. Aber auch bestehende Projekte könnten davon betroffen sein und müssen während ihres Entwicklungszyklus oder bei Projektende unter einer Open-Source-Lizenz veröffentlicht werden.
Gerade Letzteres kann besondere Herausforderungen bei Projekten mit sich bringen, beispielsweise wenn diese bereits proprietäre Softwarekomponenten eingesetzt haben. Weiterhin können inkompatible Lizenzen, eine unsaubere Git-Historie oder auch Geheimnisverluste (die versehentliche Veröffentlichung von Zugangsdaten oder internen Informationen) zu Problemen führen, wenn die Konfiguration nicht immer sauber gehalten wurde. Eine weitere Herausforderung vor allem für bestehende Projekte ist, dass diese in internen Versionskontrollsystemen (VCS) entwickelt wurden, die sich nicht für externen Zugriff und Beteiligung eignen. Eine Freigabe als Open Source Software ist dabei ein Prozess und benötigt dadurch kontinuierliche Planung der Ressourcen. Diese werden unter anderem für die Moderation der Beteiligungen und die Reaktion auf Feedback benötigt.
Zur erfolgreichen Erfüllung von gestellten Anforderungen an die quelloffene Publikation von Softwareprojekten bestehen verschiedenste Möglichkeiten. In diesem Erfahrungsbericht gehen wir auf drei verschiedene Ansätze zur Bereitstellung ein und bieten Ihnen einen Einblick in die Themen Moderation und Vermeidung von Geheimnisverlusten. Im Artikel »Was ist Open Source Software? Definition, Vor- und Nachteile, Lizenzen« gehen unsere Kolleginnen Anna Maria Vollmer und Anna Schmitt auf allgemeine Aspekte von Open Source ein.
Veröffentlichungsansätze
Voraussetzungen
In diesem Artikel setzen wir diverse Aspekte voraus. Zum einen gehen wir davon aus, dass eine klare Entscheidung über die Auswahl der Lizenzen vorliegt. Diese muss auf einer rechtssicheren Entscheidung beruhen und ist nicht Bestandteil dieses Artikels, der sich auf die praktischen Prozesse bei der Veröffentlichung fokussiert.
Weiterhin gehen wir davon aus, dass die zu veröffentlichende Software zumindest zu den Release-Zeitpunkten einen Zustand hat, der die Bedingungen der eigenen Lizenz und aller Lizenzen von verwendeten Softwarekomponenten erfüllt. Hierzu kann exemplarisch zählen, dass keine Daten von dritten Urhebern im Repository ohne vorausgehende lizenzrechtliche Überprüfung enthalten sind. Handelt es sich bei der zu veröffentlichenden Software um ein Derivat einer bereits bestehenden Software, ist die entsprechende Ursprungslizenz zu beachten.
Des Weiteren gehen wir davon aus, dass die Entwicklung der Software in einem geschlossenem Versionskontrollsystem stattfindet. Es empfiehlt sich, auch die OSS-Veröffentlichungen über Versionskontrollsysteme durchzuführen, um die Möglichkeiten des Bezugs des Projekts sowie Bereitstellungsoptionen möglichst an bekannte Standards anzunähern. Es besteht zwar auch die Möglichkeit, Quellcode als Artefakt auf der eigenen Webpräsenz zum Download anzubieten, wodurch jedoch die Beteiligung als Prozess deutlich erschwert wird.
Auswahl des Open-Source-Hostings
Aus technischer Sicht ist die Auswahl der Publikationsplattform für OSS-Projekte irrelevant; die Auswahl orientiert sich primär an weiterführenden Bestimmungen der Ausschreibung. Eine häufig in öffentlichen Ausschreibungen angetroffene Anforderung ist beispielsweise die Veröffentlichung auf der OpenCoDE Plattform, die eine GitLab-Instanz mit einem durch Metadaten angereicherten Softwareverzeichnis ergänzt.
Es existiert eine Vielzahl weiterer Plattformen, die gemäß der gestellten Anforderungen ausgewählt werden müssen. Ein Vorteil großer Plattformen besteht darin, dass bereits viele User vorhanden sind. Dadurch wird die Interaktionshürde mit (neuen) Projekten gesenkt, da keine separate Registrierung o. ä. notwendig ist und die User oft mit den Prozessen in solchen Projekten vertraut sind.
Auch besteht die Möglichkeit, in eigener Infrastruktur ein Quellcode-Hosting zu betreiben. Jedoch ist der Betrieb solcher Plattformen stets mit Wartungsaufwand verbunden, der im Vorhinein eingeplant werden muss.
Gestaltung von öffentlichen Quellcode-Repositories
Maßnahmen in Repostitories von Open-Source-Projekten ähneln in vielerlei Gesichtspunkten einer Form der Suchmaschinenoptimierung, wie sie bei Websites angewendet wird. Die Readme-Datei stellt in diesen Repositories den zentralen Einstiegs- und Präsentationspunkt dar und sollte daher stets die wichtigsten Informationen beinhalten. In vielen Quellcode-Hostings wird die Readme-Datei durch eine Textdatei im Markdown-Format als HTML dargestellt, sodass dem Eigentümer des Repositories grundsätzliche Gestaltungsmöglichkeiten gegeben werden. Auch können Logos eingebracht werden, um eine Projektidentität in die Veröffentlichung einzubringen.
Ein Readme sollte dem User die Möglichkeit bieten, alle wichtigen Informationen zum Projekt abzurufen. Dazu zählen:
- Name und Beschreibung
- Konfigurations und Installationsanweisungen
- Lizenz
- Vermerke auf Beteiligungsmöglichkeiten und Limitierungen
- Hinweise zu Meldeketten für sicherheitsrelevante Themen
Um eine Beteilgung freiwilliger User auf OSS zu erleichtern, müssen Projekte Grundstandards im Bereich der Softwarequalität erfüllen. Hierzu zählt die Deklaration und Einhaltung von Konventionen und Standards innerhalb des Projekts oder auch die Verwendung von automatisierten Prozessen zur Ermittlung von Metriken der aktuell vorliegenden Qualität. Die Ergebnisse dieser Überprüfungen können als Bild (häufig als sogenannte Badge realisiert) im Readme eingebettet werden, sodass neuen Usern unmittelbar ein Überblick über qualitative Merkmale des Projekts vermittelt werden kann.
Prozesse für die Veröffentlichung in Open-Source-Repositories
Im Folgenden werden drei exemplarische Veröffentlichungsansätze für quelloffene Projekte vorgestellt. Die Prozesse unterscheiden sich in dem möglichen Grad der Beteiligung und eignen sich entweder für eine unidrektionale oder eine bidirektionale Veröffentlichungsrichtung, die sich je nach vorliegender Situation und gestellten Anforderungen ergibt. Natürlich ist es auch möglich, verschiedene Ansätze zu kombinieren, sofern es die Ausgangslage erfordert.
Releasegebunden
Der erste Ansatz ist die releasegebundene, summierende Veröffentlichung. Bei diesem Vorgehen geschieht die Entwicklung in einem geschlossenen Versionskontrollsystem und nur fest definierte Versionen sollten als Kopie veröffentlicht werden. Dieses Verfahren kann zur nachträglichen Veröffentlichung von Bestandssoftware genutzt werden, bei der die Historie der Änderungen (in der Abbildung durch C1-C4 repräsentiert) nicht 1:1, oder nur in gefilterter Form, veröffentlicht werden soll. Dieser Filter kann auch eine (manuelle) Qualitätssicherung beinhalten, die auch als Abnahmeschritt genutzt werden kann, um den Abfluss von Geheimnissen aus dem Code zu vermeiden.
Der Entwicklungsverlauf, inklusive der Kommentare der einzelnen Commits, geht folglich für die Öffentlichkeit verloren, sodass das Nachvollziehen gewisser Entscheidungen im Code erschwert werden könnte.
Durch die (automatisierte) Zusammenfassung des Bearbeitungsverlaufs ergibt sich ein unidirektionaler Fluss von Änderungen, der vom eigenen VCS zum OSS VCS führt. Beteiligungen von außen sind hierdurch nur durch händische Rückführung möglich. Dies erfordert die Definition eines transparenten, verständlichen Prozesses, der auch nach außen kommuniziert werden muss. Natürlich können nachgelagerte Prozesse auch kompilierte Artefakte für den User bereitstellen.
Um diese Veröffentlichung effizient und konsistent durchzuführen, empfiehlt es sich, den Prozess über eine CI/CD-Pipeline zu automatisieren. Der simpelste Prozess, den man abbilden kann, ist das Kopieren des Repository-Inhalts zum Stand der Version in das andere Repository, potenziell auch mit einer automatischen Filterung von internen Inhalten (bspw. Konfigurationsdateien). Je nach Technologie gibt es auch Tools, die das unterstützen können. So kann man zum Beispiel für Maven-basierte Projekte das Apache Maven AntRun Plugin verwenden, das Möglichkeiten für eine gefilterte Synchronisation zwischen Ordnern bietet.
| Nutzen | Herausforderungen |
|---|---|
|
|
Multiple Origin
Wenn die Historie und die Commits erhalten werden können, kann auch der Ansatz des Multiple Origins eingesetzt werden. Dieser Ansatz orientiert sich an Funktionen von Versionskontrollsystemen, bei denen der Code in mehreren Systemen abgelegt wird (»git remotes“). Bei diesem Ansatz ist es wichtig, ein führendes System zu definieren, hier exemplarisch das eigene VCS.
Als Ergebnis fungiert das Open-Source-Repository als Spiegel. Aus technischer Sicht ist dieser Ansatz eine schlanke Lösung, da viele VCS nativ Mirroring unterstützen. Man kann dies auch auf bestimmte Branches limitieren, sodass man intern auch noch an neuen Funktionen arbeiten kann, bevor diese öffentlich sind. Dies kann beispielsweise auch für sicherheitskritische Arbeiten relevant sein.
Grundsätzlich hat dieser Ansatz nur eine Richtung. Da die Historie und somit die Kompalibität von Branches zwischen OSS-Repository und eigenem VCS durch das Spiegelverhältnis vorhanden ist, können auch User Vorschläge auf Basis des OSS VCS unterbreiten. Anders als beim zuvor demonstrierten Ansatz können Änderungsvorschläge zwischen beiden VCS ausgetauscht werden. Jedoch ist hier auch eine klare Definition des Beteiligungsprozesses notwendig, der auch Moderationsaufwand erzeugt. Das Thema der Moderation wird im Verlauf des Beitrags noch näher beleuchtet.
Es sollte nachvollziehbar definiert werden, wie oft eine Synchronisation erfolgt, um Asynchronität der Spiegelung zu vermeiden. Diese Information sollte dabei auch im OSS-Repository einsehbar sein. Im Unterschied zum releasegebundenen Ansatz können hier auch hochfrequente Synchronisationen, z. B. täglich oder mit jedem Commit, vorgenommen werden. Daher eignet sich dieser Ansatz auch für Szenarien, bei denen das OSS-Repository möglichst aktuell gehalten werden muss.
Entwickler müssen bei diesem Ansatz zudem auch immer darauf achten, auf dem richtigen Origin zu arbeiten und nicht versehentlich in das Open-Source-Repository zu pushen.
| Nutzen | Herausforderungen | |
|---|---|---|
|
|
Direkt quelloffen
In diesem Arbeitsmodus wird die Entwicklung öffentlich vorgenommen, sodass auch Entwicklungs- und Designentscheidungen transparent nachverfolgt werden können.
Durch die transparente Entwicklung ergibt sich im Vergleich zu den zuvor vorgestellten Ansätzen ein zusätzlicher Moderationsaufwand, da neue Tickets sowie Diskussionen und Bemerkungen bearbeitet werden müssen. Es empfiehlt sich hier eine Untersützung durch Automatisierungsprozesse, z. B. zur Kennzeichnung neuer Tickets. Ähnlich wie bei dem zuvor dargestellten Spiegelungsansatz müssen auch hier Regeln definiert werden, um Veröffentlichungen »aus Versehen« zu vermeiden. Im Unterschied zu den bereits demonstrierten Ansätzen entfällt hier die Notwendigkeit von Spiegeln oder mehreren VCS.
Bei der Beteiligung von außen empfiehlt es sich, Funktionen des Quellcodeverwaltungssystems auszureizen und z. B. die Funktion von Pull-/ Merge-Requests zu nutzen, bei denen der beitragende User auf Basis einer modifizierten Kopie (»Fork«) seine Änderungen vorbereitet und diese dann als Änderungsvorschlag (»Pull Request«) bereitstellt. Auch können diese Vorschläge diskutiert werden, sodass Annahme oder Ablehnung von Vorschlägen transparent gemacht werden kann. Dadurch entfällt der Bedarf eines Medienbruchs, da Diskussionen z. B. nicht getrennt über E-Mail vorgenommen werden müssen.
Insbesondere bei extern bereitgestellten Quellcodeverwaltungen außerhalb der eigenen Infrastruktur sollte bedacht werden, dass die Anbindung eigener Build-Systeme an externe VCS durch eine Verbindung von außen mit Sicherheitsrisiken verbunden ist, die durch ein geeignetes Konzept gehandhabt werden muss.
| Nutzen | Herausforderungen |
|---|---|
|
|
Moderation in Open-Source-Projekten
Open-Source-Projekte benötigen ein Moderationselement. Fundament der Moderation sind klar definierte Prozesse, die auch für Externe dargestellt werden müssen.
Es hat sich in Open-Source-Projekten etabliert, diese Prozesse und Hilfestellungen als Markdown-Dateien im Repository beizufügen und somit für Nutzer direkt einsehbar zumachen. Es sind dabei mehrere dieser Informationspunkte denkbar. Eine Auswahl möglicher Themen ist der Tabelle zu entnehmen:
| Datei | Bedeutung |
|---|---|
| CODE_OF_CONDUCT.md | Definiert Community-Standards. Hierzu zählt z. B. eine Art Netiquette, die bei Diskussionen aufrechterhalten werden muss. |
| SECURITY.md | Definiert den Meldeprozess (»responsible disclosure«) für Sicherheitslücken. |
| CONTRIBUTING.md | Definiert den Prozess, wie User Inhalte besteuern können. Kann auch dazu genutzt werden, bestimmte Beteiligungen auszuschließen, z. B. wenn die Änderungen nicht eingespielt werden können. |
Für alle Beteiligungsprozesse empfiehlt sich ein Ansatz nach dem KISS-Prinzip (»keep it simple, stupid«), da durch definierte komplexe Prozesse der Moderationsaufwand steigen kann und sich die Einstiegshürde für Dritte erhöht.
Bei der Moderation von Änderungsanfragen sollten diese stets als Vorschlag gehandhabt werden. Zudem muss eine saubere und nachvollziehbare Kommunikation erfolgen, wenn Änderungen abgelehnt werden. Änderungsvorschläge müssen vor der Übernahme (»merge«) auf Erfüllung von Anforderungen geprüft werden, um rechtliche oder technische Probleme oder auch die Angriffsfläche für Supply-Chain-Angriffe zu reduzieren. Hierzu empfiehlt sich ein klar definierter Review-Prozess, der auch in einer CONTRIBUTING.md-Datei beschrieben werden sollte.
Automatisierung kann in Open-Source-Projekten händische Aufgaben effizient gestalten. Exemplarische Möglichkeiten sind:
- Kennzeichnung neuer, überalterter oder ungültiger Tickets mit Schlüsselwörtern (»Tags«)
- Security-Checks und Dependency-Prüfungen
Vermeidung von Geheimnisverlusten bei der OSS-Publikation
Software benötigt Konfigurationswerte. Es ist immer wieder möglich, dass Schlüssel oder interne Konfigurationsdateien in ein Repository eingecheckt werden, was zu einem Geheimnisverlust führt und im schlimmsten Fall zu einer Infiltration der Infrastruktur und einem Datenabfluss führen kann. Bei der Veröffentlichung von Software als Open Source gibt es Werkzeuge, um dies zu vermeiden. Vor der Veröffentlichung müssen Projekte einem Review unterzogen werden, um kritische Daten zu finden. Software kann diesen Prozess unterstützen. Der bestehende Verlauf des Projekts in der Historie sollte hier ebenfalls bedacht werden, da auch entfernte Inhalte aus der Historie wiederhergestellt werden können.
Die vorgestellten Ansätze können für die (Erst-)Veröffentlichung kombiniert werden. Als Startpunkt für ein bestehendes Projekt kann der releasegebundene Ansatz verwendet werden. Sobald der Übergang ins OSS VCS abgeschlossen ist, kann die Entwicklung dort oder über den Spiegelansatz fortgeführt werden.
Insbesondere in Cloud-native Umgebungen haben Images einen großen Stellenwert. Im Rahmen von CI/CD-Pipelines werden Repositories zu Container-Images kombiniert, was auch in Open-Source-Projekten realisiert werden kann. Ein konzeptioneller Ansatz zur Vermeidung von Geheimnisverlusten sind hierbei »dumme« Images. Ein solches Image ist kontextunabhängig und beinhaltet keinerlei Geheimnisse. Jede Form von Konfiguration wird über die Umgebung zur Laufzeit vorgehalten, z. B. via Volumes oder Umgebungsvariablen.
Durch diesen Prozess wird auch die Wiederverwendbarkeit von Images erhöht, da keine separaten Konfigurationsanpassungen in den Images vorgenommen werden müssen, weil keine Konfiguration Bestandteil des Images ist.
Fazit: Unterschiedliche Wege zu Open Source
Die in diesem Artikel vorgestellten Ansätze behandeln eine exemplarische Menge aus denkbaren Prozessen, um Softwareprojekte als Open Source zu veröffentlichen, was insbesondere für die öffentliche Verwaltung zunehmend relevant ist. Die Ansätze unterscheiden sich dabei im Grad der Möglichkeiten der Beteiligung, die je nach vorhandener Situation unterschiedlichen Nutzen und verschiedene Herausforderungen aufweisen.
Eine Verkettung der Ansätze bietet einen Pfad, auch bestehende Software in eine OSS zu überführen. In Kombination mit Review-Prozessen und einer Optimierung des Konfigurationsmanagements wird die Gefahr des Abflusses von Geheimnissen reduziert.
In jedem Fall empfiehlt es sich, mit den angebotenen Funktionalitäten des ausgewählten Quellcode-Hostings zu arbeiten und diese durch sinnvolle Automatisierung zu ergänzen. Jedoch ist in allen Fällen der Faktor der Moderation notwendig und einzuplanen, um die Kommunikation mit Dritten transparent zu gestalten.
Erfahrungswerte zeigen auch, dass man sich frühzeitig mit der Entscheidungsfindung für passende Lizenzen beschäftigen sollte, da die Entscheidung für eine bestimmte Lizenz starke Auswirkungen auf die Vermarktbarkeit eines Produktes und zukünftige Entwicklungsprozesse haben kann.