Regelungen zu Open Source für Modellprojekte Smart Cities

KfW-Merkblatt 436 (Stand: 03/2019 – 1. Staffel)

Die einschlägigen Formulierungen der Förderrichtlinie „Modellprojekte Smart Cities“ zu Open Source lauten: 

• „geförderte Softwarelösungen sind als Open Source beziehungsweise freie Software zur Verfügung zu stellen“ sowie:
• Die Modellprojekte Smart Cities sind dazu verpflichtet, „von aus Mitteln der Modellprojekte Smart Cities beauftragte Softwarelösungen als Open Source beziehungsweise freie Software inklusive nachvollziehbarer Dokumentation auf einer noch festzulegenden Webseite“ zu veröffentlichen.

Siehe hierzu: KfW-Merkblatt 436 (Stand: 03/2019 – 1. Staffel)

KfW-Merkblatt 436 (Stand: 02/2020 – 2. Staffel)

In den Modellprojekten Smart Cities sollen:

• Open-Source- und Open-Knowledge-Ansätze umgesetzt sowie interoperable Schnittstellen genutzt werden.

Die Kommunen verpflichten sich am Erfahrungsaustausch innerhalb der Modellprojekte Smart Cities und darüber hinaus am Wissens- und Kompetenzaufbau zur nachhaltigen Gestaltung der Digitalisierung mitzuwirken. Die Kommunen geben diese Verpflichtung auch an ihre Umsetzungspartner und beauftragten Firmen weiter. Dazu gehören unter anderem:

• Veröffentlichung von aus Mitteln der Modellprojekte Smart Cities beauftragten Softwarelösungen als Open Source beziehungsweise freie Software inklusive nachvollziehbarer Dokumentation auf einer noch festzulegenden Webseite.

Siehe hierzu: KfW-Merkblatt 436 (Stand: 02/2020 – 2. Staffel)

KfW-Merkblatt 436 (Stand: 10/2021 – 3. Staffel)

Dazu sind die geförderten Kommunen verpflichtet, am Erfahrungsaustausch über die geförderten Modellprojekte Smart Cities hinaus aktiv mitzuwirken und geförderte Softwarelösungen als Open Source bzw. freie Software zur Verfügung zu stellen.

In den Modellprojekten Smart Cities sollen:

• Open-Source- und Open-Knowledge-Ansätze umgesetzt sowie interoperable Lösungen und standardisierte Schnittstellen entwickelt und genutzt werden.

Die Kommunen verpflichten sich am Erfahrungsaustausch innerhalb der Modellprojekte Smart Cities und darüber hinaus proaktiv und regelmäßig mitzuwirken. Die Kommunen geben diese Verpflichtung auch an ihre Umsetzungspartner und beauftragten Firmen weiter. Dazu gehören unter anderem:

• Veröffentlichung von aus Mitteln der Modellprojekte Smart Cities beauftragten Softwarelösungen als Open Source beziehungsweise freie Software inklusive nachvollziehbarer Dokumentation auf einer noch festzulegenden Webseite.

Siehe hierzu: KfW-Merkblatt 436 (Stand: 10/2021 – 3. Staffel)

Veröffentlichung des Quellcodes

Das Open-Source-Gebot der Förderrichtlinie Modellprojekte Smart Cities wurde am 14. September 2022 dahingehend präzisiert, dass Software, die mit Fördermitteln des Bundes mitfinanziert wird,

• (1) auf OpenCoDE.de eingestellt und veröffentlicht werden soll und
• (2) eine der dafür zulässigen Lizenzen genutzt werden soll. Im Rahmen des Modellprojektes Smart Cities soll eine der unter OpenCoDE.de gelisteten, zulässigen Lizenzen verwendet werden.

Bereits bestehende Verträge werden seitens des BMWSB hingenommen. Neu eingeleitete Beschaffungen sollten in der Regel jedoch ab 1. Oktober 2022 eine entsprechende Vorgabe enthalten. Ausnahmen sind im begründeten Einzelfall möglich (siehe Kapitel 6 „Für welche Software-Lösungen gilt das Open- Source- Gebot, für welche nicht?“).

Inkrafttreten des präzisierten Open-Source-Gebots in Abhängigkeit vom gewählten Vergabeverfahren

Die Kommunen sind dazu verpflichtet, das Open-Source-Gebot auch an ihre Umsetzungspartner und beauftragten Unternehmen weiterzugeben. Das Open-Source-Gebot ist daher ebenso wie interoperable Lösungen und standardisierte Schnittstellen bei der Formulierung der Ausschreibung zu berücksichtigen und im Leistungskatalog zu definieren.

Für Beschaffungen wird der Stichtag 1. Oktober 2022 wie folgt konkretisiert:

• Für nicht-veröffentlichungspflichtige Beschaffungen gilt             
  Stichtag ist der Zeitpunkt, zu dem die Aufforderungen auf Angebotseinreichung an potenzielle Bieter versandt wird.
• Für auf Vergabeplattformen veröffentlichungspflichtige Beschaffungen gilt: 
  Stichtag ist der Zeitpunkt der Vergabebekanntmachung.
• Für Vergabeverfahren im Verhandlungsverfahren gilt:
  Stichtag ist der Zeitpunkt, zu dem die Eignungsprüfung abgeschlossen wird und die Bieter zur Einreichung von Angeboten aufgefordert werden. Hilfsweise kann der Zeitpunkt zur Aufforderung für die Einreichung der finalen Angebote herangezogen werden.

Beschaffungen, deren entsprechende Verfahrensschritte bereits vor diesem Stichtag durchgeführt wurden, sind aus vergaberechtlichen Gründen hiervon ausgenommen.

Open Source bedeutet in der Softwareentwicklung „quelloffen“ und „offene Quelle“ zugleich. Damit ist gemeint: Der Quellcode einer Software ist frei zugänglich – nicht unbedingt aber kostenlos –, lesbar und verständlich.

Zudem steht er jeder und jedem frei zur Verfügung, das heißt er darf beliebig oft kopiert, verbreitet und genutzt werden. Darüber hinaus darf der Quellcode verändert und in veränderter Form weitergegeben werden.

In der Softwareentwicklung entspricht Open Source damit einer Methodik, die auf bestehenden Softwarelösungen aufbaut und durch ihre Quellcode-Offenheit und Transparenz eine Kollaboration vieler gestattet, um Bestehendes weiterzuentwickeln. Die Open-Source-Initiative (https://opensource.org) definiert, Open Source unter anderem auch dadurch, dass die Lizenzbedingungen jeder und jedem lizenzgebührenfrei die Vervielfältigung, Bearbeitung und Weiterverbreitung der Software gestatten.

Hintergrund ist die Anforderung an die Modellprojekte Smart Cities (vgl. KfW-Merkblätter 436 aller drei Staffeln, Seite 1), dass die entwickelten Softwarelösungen zu hoher Verwertbarkeit in der gesamten kommunalen deutschen Landschaft führen sollen. Softwarelösungen sollen daher skalierbar und replizierbar sein und das wird durch Open Source am ehesten erreicht.

Dem Grundsatz Public Money – Public Code folgend sind die geförderten Kommunen verpflichtet, am Erfahrungsaustausch über die geförderten Modellprojekte Smart Cities hinaus aktiv mitzuwirken und geförderte Softwarelösungen als Open Source zur Verfügung zu stellen und zu dokumentieren. Hierfür wird die Open-Source-Plattform der öffentlichen Verwaltung OpenCoDE.de genutzt.

Um dies zu ermöglichen, sind die auf OpenCoDE.de zulässigen Lizenzen zu verwenden. Diese sind seitens OpenCoDE.de geprüft und werden als ausreichend sicher für die Verwendung durch öffentliche Verwaltungen angesehen. Die Zulässigkeit zusätzlicher Lizenzen kann dort beantragt werden.

Diese Verpflichtung ist laut den KfW-Merkblättern 436 für alle drei Staffeln (der Förderrichtlinie) auch an Partner und Beauftragte weiterzugeben.

Dem Fördermittelgeber sind im Zusammenhang mit dieser Verpflichtung Pfadabhängigkeiten und Lock-in-Effekte bewusst. Mit den Modellprojekten Smart Cities zielt er auf die Stärkung der kommunalen Handlungsfähigkeit durch Befähigung der Kommunen zu mehr digitaler Souveränität. Er hat deshalb in der Förderrichtlinie formuliert, dass in den Modellprojekten Smart Cities „Vendor-Lock-in-Effekte und Abhängigkeiten von Einzeltechnologien und Unternehmen vermieden werden“ sollen.

Open-Source-Lizenzen unterscheiden sich oftmals nur in wenigen Details; wesentlich ist die Differenzierung nach der Intensität des „Copyleft“. Unter Copyleft versteht man eine Lizenzvertragsklausel, wonach die Modifikation der Software jedermann gestattet, aber zugleich an die Pflicht geknüpft wird, diese Modifikationen bei der Weitergabe wieder der Ursprungslizenz zu unterstellen. Auf diese Weise stehen Weiterentwicklungen der Software stets als Open-Source-Software zur Verfügung.

Lizenzen unterscheiden sich in der Auslegung ihrer Einschränkungen und Lizenzbestimmungen in:

• (a) Lizenz mit strenger Copyleft-Auslegung,
• (b) Lizenz mit abgeschwächter Copyleft-Auslegung,
• (c) Lizenz ohne Copyleft-Auslegung, „permissive Lizenz“.

Lizenzen mit strenger Copyleft-Auslegung weisen die meisten Restriktionen und Vorgaben für die Weitergabe modifizierter Open-Source-Software auf. Beispiele für strenge Copyleft-Lizenzen sind die GNU General Public License (GPL), die European Public License (EUPL) und die Eclipse Public License (EPL).

Auch Lizenzen ohne Copyleft-Effekt räumen dem Lizenznehmer alle Freiheiten einer Open-Source-Lizenz ein. Sie unterscheiden sich von den Lizenzen mit Copyleft allerdings dadurch, dass sie für die Weiterverbreitung veränderter Software keine Einschränkungen enthalten. Damit kann der Lizenznehmer veränderte Versionen der Software unter beliebigen Lizenzbedingungen weiterverbreiten, also auch in proprietäre Software überführen. Er muss lediglich das originale Copyright und die originale Lizenz in allen Verbreitungen benennen.

• Die Nutzung einer Open-Source-Lizenz ohne Copyleft ermöglicht eine breite Wiederverwendung der lizensierten Inhalte. Eine solche Lizenz ist in der Regel einfach und freizügig gestaltet. Sie ermöglicht Dritten nahezu jedwede Verwendung des Projektes wie z.B. die Weiterentwicklung zu einem proprietären Produkt mit geschlossenem Quellcode.
• Die Nutzung einer Open-Source-Lizenz mit strenger Copyleft-Auslegung sollte gewählt werden, wenn man von den späteren Erweiterungen und Verbesserungen an der Software profitieren möchte. Sie ermöglicht Dritten nahezu jedwede Verwendung des Produktes mit Ausnahme der Weiterentwicklung zu einem proprietären Produkt mit geschlossenem Quellcode. Eine Open-Source-Lizenz mit strenger Copyleft-Auslegung sichert den dauerhaften Zugang zu einer Software und ihre Weiterentwicklung als Open Source.

Der Geltungsbereich des Open-Source-Gebots erstreckt sich auf die Förderung von Maßnahmen im Rahmen der Modellprojekte Smart Cities sowohl für die Strategiephase (Phase A) als auch für die Umsetzungsphase (Phase B).

Nachfolgend werden einige Beispiele ausgeführt, für welche Software-Lösungen das Gebot gilt und für welche nicht.

• Erste Maßnahmen in der Strategiephase (sogenannte „Quick-win-Maßnahmen“), für die im Einzelfall Ausnahmen vom Open-Source-Grundsatz genehmigt wurden, müssen in der Umsetzungsphase entsprechend den oben genannten Regelungen umgestellt werden.
• Bei hochkomplexer Spezialsoftware für Fachanwendungen der Stadtentwicklung, wie GIS-Anwendungen, CAD sowie der Architektur von urbanen Datenplattformen, sind Schnittstellen zu proprietären Systemen regelmäßig förderfähig, wenn diese Schnittstellen als Open Source zur Verfügung gestellt werden. Ist dies nicht der Fall, so sind die Aktualisierung der Schnittstelle und der Zugang aller deutscher Kommunen zu diesen Schnittstellen auf andere Weise von den Modellprojekten Smart Cities sicher zu stellen. Insbesondere für Tools/Anwendungen aus dem Bereich Geoinformationen existieren interoperable Standards und weit verbreitete Open-Source-Alternativen. Die Notwendigkeit der Verwendung von proprietären Schnittstellen ist hier gut zu belegen (Vertragsbedingungen, bzw. Nischenprodukte). Diese Fälle unterliegen einer Einzelprüfung.
• Bei Nutzung von am Markt verfügbarer Software für smarte Lösungen kann der Bund eine Modellhaftigkeit und den Mehrwert für andere Kommunen nicht erkennen. Daher ist er in der Regel nicht bereit, diese zu finanzieren. Im Zusammenhang mit Projekten, die eine hohe Modellhaftigkeit haben bzw. die Wissensbasis der Kommunen über den bestehenden Stand erweitern, könnte im Einzelfall eine Förderung erfolgen.
• Generell nicht betroffen vom Open-Source-Gebot sind Softwarelösungen, die nicht gefördert werden.

Hinweise zur Wirtschaftlichkeit:

Das Open-Source-Gebot ist eine wesentliche Voraussetzung für die Nutzung und Übertragung der mit den Modellprojekten Smart Cities erzielten digitalen Lösungen durch andere Kommunen und damit den Wissenstransfer in die Breite der kommunalen Landschaft. Dieser Mehrwert ist in den Modellprojekten Smart Cities elementar für das Bundesinteresse und damit die Förderentscheidung.

Die Wirtschaftlichkeit einer Maßnahme ist daher nicht nur auf der Ebene des einzelnen Förderprojekts zu bewerten, sondern vor der Gesamtheit aller Modellprojekte Smart Cities, der deutschen Kommunen und des Gesamtstaates im Sinne einer informellen Nachfragegemeinschaft. Dabei ist auch zu berücksichtigen, dass die Investitionen in diese Software dazu beitragen, die digitale Souveränität Deutschlands zu stärken und den Umfang der jährlich durch die öffentliche Hand zu finanzierenden Lizenzkosten zu reduzieren.

Dem Fördermittelgeber ist bewusst, dass Open Source nicht kostenlos ist und dass es einer Anfangsinvestition bedarf, um die bestehenden Pfadabhängigkeiten zu überwinden. Dazu will er u. a. mit den Modellprojekten Smart Cities beitragen und hat deshalb den Mehrwert der Wiedernutzbarkeit von Open-Source-Software höher bewertet als kurzfristige Einsparungen und Beschleunigungseffekte durch Nutzung von am Markt verfügbarer Software.

Das Open-Source-Gebot kann bei Vergaben im Rahmen der Leistungsbeschreibung berücksichtigt werden. Dies erfolgt typischerweise in der Leistungsbeschreibung, in welcher der Auftragsgegenstand und die „Rahmenbedingungen“ als Pflichtanforderung definiert werden.

Beispiel (wenn die gewünschte Lizenz unklar ist):

Rahmenbedingung 1: Open Source

Die Lösung muss auf Basis von Open-Source-Komponenten umgesetzt werden, um die Verbreitung zu weiteren Kommunen zu unterstützen und zugleich die Weiterentwicklung der Plattform durch Dritte zu ermöglichen. Die gesamte Lösung muss daher Open Source sein und spätestens zum Zeitpunkt der Bereitstellung an den Auftraggeber zur Veröffentlichung auf OpenCoDE.de übergeben werden. Als Lizenz zur Veröffentlichung muss eine auf OpenCoDE.de im Bereich Lizenz Compliance freigegebene Lizenz in Abstimmung mit dem Auftraggeber gewählt werden.

Beispiel (wenn die gewünschte Lizenz bekannt ist):

Rahmenbedingung 1: Open Source

Die Lösung muss auf Basis von Open-Source-Komponenten umgesetzt werden, um die Verbreitung zu weiteren Kommunen zu unterstützen und zugleich die Weiterentwicklung der Plattform durch Dritte zu ermöglichen. Die gesamte Lösung muss daher Open Source sein und spätestens zum Zeitpunkt der Bereitstellung an den Auftraggeber zur Veröffentlichung auf OpenCoDE.de übergeben werden. Als Lizenz zur Veröffentlichung muss die GNU Affero General Public License, Version 3 (AGPL) gewählt werden.

Open-Source dient wie zuvor dargestellt der nicht-kommerziellen Verbreitung von Software. Hierbei räumt der Urheber Dritten umfassende Nutzungsrechte an bestimmten Software-Versionen über Lizenzvereinbarungen ein (z.B. GPL 2.0, s.o.), im Gegenzug möchte er die Haftung hierfür weitestgehend ausschließen, was bedeutet, dass er bzw. der Sub-Lizenzgeber damit weder für Mängel der Open-Source-Software (z.B. Sicherheitslücken) noch für hierdurch entstandene Folgemängel (Vermögensschäden infolge der Sicherheitslücken) haften soll. Grundsätzlich können daher die MPSC beim Einsatz fehlerhafter Open-Source-Software haften. Rechtlich sind hierbei aber folgende Punkte zu beachten:

• Üblicherweise werden Open-Source-Lizenzvereinbarungen als Allgemeine Geschäftsbedingungen eingeordnet, was zur Folge hat, dass ein vollständiger anbieterseitiger Haftungs- bzw. Gewährleistungsausschluss auch im B2B-Bereich regelmäßig nicht zulässig ist. Wegen der Uneigennützigkeit des Lizenzgebers, soll dieser gleichwohl nur eingeschränkt haften müssen, etwa bei arglistigem Verschweigen von Mängeln sowie vorsätzlich oder grob fahrlässig in den Verkehr gebrachter mangelhafter Software (z.B., wenn der Lizenzgeber Open-Source-Software bereitstellt, obwohl ihm eine Sicherheitslücke bekannt ist). Die Lizenznehmer (hier: die MPSC) haben dann in der Regel einen Anspruch auf Beseitigung der Mängel (z.B. der Sicherheitslücke). Ist es in der Folge bereits zu Schäden gekommen (z.B. Cyber-Angriff, Daten-Leak, ggf. sogar Betriebsausfall), so ist nicht ausgeschlossen, dass auch ein Anspruch auf Schadensersatz gegenüber dem Lizenzgeber besteht.
• Darüber hinaus kann die Haftung des Herstellers oder eines Vertriebspartners der Open-Source-Software bei Produktfehlern nach den Grundsätzen des Produkthaftungsgesetzes vertraglich nicht beschränkt werden, denn danach wird allgemein ein gewisses Maß an Sicherheit der Software vorausgesetzt (etwa Freiheit von Viren und Malware). Es bestehen also anbieterseitig gewisse Produktüberprüfungspflichten, die bei Nichtbeachtung eine Haftung auslösen können.
• Enthalten die Lizenzvereinbarungen keinen vertraglichen Ausschluss der Haftung bzw. der Mängelgewährleistung so finden je nach Einzelfall die allgemeinen zivilrechtlichen Regelungen Anwendung (z.B. Recht auf Nacherfüllung, Rücktritt, Schadensersatz). Die MPSC sollten daher möglichst Software einsetzen, die keine Haftungsausschlüsse in den Lizenzvereinbarungen enthalten. Weil dies nur selten der Fall sein wird, ist darauf zu achten, dass die eingesetzte Software zumindest regelmäßigen Aktualisierungen unterliegt, um die Gefahr von Sicherheitslücken und Bugs zu minimieren.

Eine Haftung der MPSC bei Verwendung mangelhafter Software kommt etwa dann in Betracht, wenn der Softwareanbieter nicht in Anspruch genommen werden kann (z.B. bei Insolvenz) oder Schäden eigenverantwortlich herbeigeführt wurden, so z.B., wenn die MPSC wegen mangelhafter Organisation einen Hinweis des Anbieters auf eine Sicherheitslücke übersehen und es hierdurch zu einem Betriebsausfall bei Dritten kommt. Vor dem Hintergrund kann je nach Einsatzgebiet eine Obliegenheit bestehen, externe Beratungs- und Serviceleistungen zu beziehen, um sich nicht wegen eines Organisationsverschuldens haftbar zu machen, dies gilt insbesondere bei Einsatz entsprechender Software in sicherheitsrelevanten Einsatzgebieten, wie Finanzwesen, Gesundheitswesen (Krankenhäuser) oder Luftfahrt.

Wurde die Open-Source-Lizenz nicht wirksam vereinbart oder untersteht diese – anders als vereinbart – dem Urheberrecht eines Dritten, der von der Verwendung durch die MPSC keine Kenntnis hat, besteht ebenfalls das Risiko einer Haftung der MPSC, z.B. für Urheberrechtsverstöße. Es empfiehlt sich daher, dass MPSC sich von Ansprüchen im Zusammenhang mit diesen Fällen durch die Lizenzgeber freistellen lassen.

Weil die Haftungsmaßstäbe im Regelfall von besonderen Umständen abhängen (Lizenzvereinbarung, Software-Funktion, Nutzungsumfang), sollten Einzelfallfragen bereits frühzeitig geklärt werden, um etwaige Wechselwirkungen auch bereits im Vergabeverfahren berücksichtigen zu können.

Die nachfolgenden Empfehlungen stützen sich auf das mit dem Förderprogramm „Modellprojekte Smart Cities“ verbundene Ziel der Übertragbarkeit guter Lösungen.

Zur Erreichung dieses Ziels ist es von großem Vorteil, wenn ein ausführbares Softwareprodukt vorliegt. Dabei kann es sich auch um ein ausführbares, idealerweise in sich abgeschlossenes Teilprodukt einer größeren Lösung handeln. Grundsätzlich muss der finale, offene Quellcode in einem Zustand vorliegen, der es anderen Nutzern ermöglicht ggf. zusammen mit einer Dokumentation diesen zu verstehen, anzuwenden und zu modifizieren. Eine Reproduzierbarkeit muss gegeben sein, da ansonsten kein Beitrag zum Wissenstransfer generiert wird.

Im Folgenden finden Sie ausgewählte detaillierte Informationen, die Sie bei der Lösung von Detailfragen unterstützen:

• Schnittstellen zu proprietärer Software sind eindeutig förderfähig, wenn die Schnittstelle unter dem Open Source Gebot veröffentlicht werden kann.
• Die Kosten für die Beschaffung, Entwicklung und Weiterentwicklung von Open-Source-Software werden – unabhängig von der kommunalhaushaltsrechtlichen Einordnung – als investiv im Sinne des Programms eingeordnet. Sie sind damit als Maßnahmenkosten (Positionen 1.2 und 2.2 des Kosten- und Finanzierungsplans) förderfähig.
• Daten aus proprietären System dürfen bei der Umsetzung von Maßnahmen genutzt werden.

Um eine Maßnahme zu realisieren, werden neben Software oft auch Geräte benötigt. Viele Geräte enthalten ihrerseits wieder Software, die zum Betrieb des Geräts selbst notwendig ist, oder die es ermöglicht, dass das Gerät digital angesprochen werden kann. Das heißt, es ist für andere Systeme erreichbar und kann Daten zu ihnen übermitteln. Typische Geräte mit integrierter Software sind Sensoren (z.B. Temperatursensor, Pegelsensor, Besucherzähler), Aktuatoren (z.B. Türöffner, Schranke, Relais zum Schalten von anderen Geräten) oder Anzeigen (z.B. digitale Stele, digitales Verkehrsschild). Diese Gerätesoftware ist oft proprietär und wird vom Hersteller des Gerätes bereitgestellt und aktualisiert. Technisch gesehen versteht die Gerätesoftware das physische Gerät und kann es deshalb steuern. Auf der anderen Seite ist diese Gerätesoftware dafür notwendig, dass über entsprechende digitale Schnittstellen Daten oder Steuerbefehle mit anderer, höherwertiger Software ausgetauscht werden können. Diese höherwertige Software ist der eigentliche Erbringer des Mehrwerts der Maßnahme, da sie die vernetzende Intelligenz zur Verfügung stellt, die ein einzelnes Gerät nicht leisten kann.

Um in dem beschriebenen Fall dem Open-Source-Gebot gerecht zu werden, gelten diese Rahmenbedingungen:

• Die digitalen Schnittstellen der Geräte müssen offen sein und einem Standard entsprechen, wenn in dem Anwendungsbereich bereits Standards existieren.
• Die höherwertige Software, die zur Vernetzung und Steuerung der Geräte verwendet wird, muss als Open-Source zur Verfügung stehen.
• Die Gerätesoftware selbst, die die Gerätedaten bis zur Geräteschnittstelle liefert, muss nicht als Open-Source zur Verfügung stehen.

Hintergrund dieser Regelung ist, dass beim Übertragen einer Lösung in eine andere Kommune die Geräte, und damit auch die in ihnen enthaltene Gerätesoftware, ohnehin beschafft werden müssen. Sie sind als Mittel zum Zweck anzusehen und schaffen nicht den eigentlichen Mehrwert der Maßnahme. Da die Schnittstellen der Geräte dann einem klaren Standard unterliegen, kann die Ausschreibung dazu sowohl einfach als auch wettbewerbsoffen erfolgen und so die Unabhängigkeit gewahrt werden. Die vernetzende, höherwertige Software kann dank der standardisierten Schnittstellen in der nachnutzenden Kommune wiederverwendet werden und passt zu den beschafften Geräten.

Open-Source-Software (OSS)-Projekte werden auf Quellcode-Plattformen (OpenCoDe, Gitlab, GitHub, ...) häufig in Form (mehrerer) Repositories zugängig gemacht. Repositories fungieren für den Betrachter als zeitlich versionierter Ordner. 

Notwendige Dokumentationen oder Einstiegspunkte in weitere Dokumentationen werden hierbei häufig als Textdateien abgelegt, die oft mit der Dateiendung .md kodiert sind. .md steht hierbei für Markdown. Das Markdown-Format bietet Entwicklern eine rudimentäre Formatierungsmöglichkeit zur Strukturierung von Texten, etwa mit Überschriften, Links oder Bildern und erleichtert dem Leser die Erfassung des Inhalts.

Einige dieser Textdateien nehmen in Repositories besondere Rollen ein, etwa in Form des README.md, welches als Einstiegspunkt in Repositories genutzt wird, um Name, Lizenz und weitere Eigenschaften des Projekts vorstellen zu können. Im Folgenden werden einige dieser Dokumentationsaspekte aufgegriffen und Vorschläge für das Ablegen der Dokumentation in Repositories gemacht.

Es ist zu empfehlen, insbesondere weiterführende und umfangreiche (technische) Dokumentationen in externe Webseiten auszulagern, um etwa eine Durchsuchbarkeit zu ermöglichen. Diese Webseiten werden dann in der im Repository abgelegten Dokumentation verlinkt. Die jeweilige (Text-)Datei im Repository dient in diesem Falle lediglich als Einstiegspunkt. Zur Erstellung solcher Dokumentations-Webseiten sind im Folgenden verschiedene Softwarelösungen exemplarisch aufgeführt.

Folgende Dokumentationsblöcke sollten in OSS-Projekten beinhaltet sein:

Installations- und Betriebsdokumentation

Ziel: Dritte befähigen, die Systeme auf eigener Infrastruktur bereitzustellen und in einem produktiven Umfeld betreiben zu können.

• Definition der Systemgrenzen
  • „Was brauche ich an Drittservices?“
    • Beispiel: Datenbanken, Broker, Hardware, Betriebssystem etc.
• Definition von Anforderungen an die Betriebsumgebung
  • realistische Angaben (z.B. Speicherplatz möglichst präzise gestalten)
• Hinweise für Produktivbetrieb
  • technische Härtungsmaßnahmen
    • damit der Betrieb auch „sicher“ umgesetzt werden kann und der Betreiber eine Chance hat, Risiken einzuschätzen
    • Welche Maßnahmen sind bereits umgesetzt? welche müssen vom Betreiber durchgeführt werden?
    • weiterhin: Benennung der Komponenten, um das System absichern zu können
  • Skalierungsmöglichkeiten
    • Wie kann mit steigender Last auf dem System umgegangen werden?

Aktualisierungs- und Entwicklerdokumentation

Ziel: Dritten ermöglichen, die Anwendung zu aktualisieren und zu erweitern und dadurch in einem gewarteten Zustand zu halten.

• (Software-)Architektur vermitteln
  • Welche Module gibt es?
  • Was sind deren Aufgaben?
  • Welche Abhängigkeiten zu anderen Technologien gibt es?
• Vermeidung komplexer, nicht-standardisierter Lösungen
  • schlanke Lösungen sind zu empfehlen, da sie weniger Wartungsaufwand bedeuten
  • standardisierte Lösungen brauchen weniger Dokumentation, da auf Bestehendes verwiesen werden kann
  • komplexe Architekturen erfordern viel Dokumentation, damit es nicht zu Missverständnissen kommt

Nutzerdokumentation

Ziel: Dritten ermöglichen, (Prozess)-Konzepte zu verstehen und gegenüber eigenen Nutzern Anfragen beantworten zu können

• Kernkonzepte kurz erklären
  • Was ist der Nutzen der Software?
  • Welche fachlichen Funktionen gibt es?
• Dokumentation nach Anwendungsfällen strukturieren
  • Nutzer suchen in der Dokumentation, wenn sie an einem bestimmten Anwendungsfall hängen bleiben
  • ein allgemeiner Überblick hilft das System zu verstehen, die Anwendungsfall spezifische Dokumentation hilft bei der Benutzung
• Verlinkungen intensiv nutzen

  • zentrale Konzepte einmal erklären, dann an allen relevanten Stellen darauf verlinken

     

Weitere Dokumentation

Ziel: Klare Regeln für die Zusammenarbeit aufstellen

• Lizenzierung
  • Datei: LICENSE.md
  • Welche Lizenzen liegen vor?
• Mitarbeit
  • Code of Conduct/Verhaltenscodex
    • Datei:CODE_OF_CONDUCT.md / CONTRIBUTING.md
    • Standards definieren
    • Qualität von Beiträgen
    • Umgangston
    • weitere Regelungen: Abtritt von Rechten am Code, LLM Code verbieten, ...
  • Issue-Templates
    • technische Maßnahme, um neuen Tickets Struktur geben zu können
    • exemplarischer Inhalt:
      1. zuerst offene Tickets durchsuchen, bevor neue Tickets eröffnet werden
      2. wingend notwendiger Inhalt bei Fehlerberichten
      3. ...
    • festlegen, wo Diskussionen stattfinden sollen
      • Achtung bei GitHub: Wenn externe Diskussionsplattformen genutzt werden (z.B. Foren), sollte die Diskussionsfunktion im Repository deaktiviert werden!
• Ansprechpartner festhalten
• Meldekette „Sicherheit“ definieren
  • Datei: SECURITY.md
  • Über welchen Kanal kann eine Responsible Disclosure (=vertrauliche Meldung von Sicherheits-problemen) durchgeführt werden?

Form der Dokumentation

• Readme lediglich als Einstiegspunkt / Hub nutzen
• Bereitstellung einer einheitlichen, versionierten und durchsuchbaren Dokumentation
• PDF- / Office-Dateien meiden und stattdessen Generatoren nutzen, um umfangreichere Dokumentation als Webseite zu erzeugen

Beispiele für Generatoren (Text)

Diese Generatoren sind meist zur Erstellung von umfangreicher, textueller Dokumentation gedacht. Die Ausgangsbasis der Dokumentation kann dann versioniert werden und die eigentliche Dokumentation immer wieder aktuell generiert und auf einem Webserver abgelegt werden.

• Docusaurus
• Gitbook
• Readthedocs
• ...

Beispiele für Generatoren (Code)

Diese Generatoren und Technologien sind meist eng mit dem Code verbunden und erzeugen eine maschinen-lesbare Entwicklerdokumentation. Damit kann beispielsweise direkt Code zur Anbindung von externen Systemen generiert werden, da die Schnittstellen eindeutig beschrieben sind.

• OpenAPI
• JavaDoc
• Sandcastle
• ...