Rund um Open Source gibt es viele Geschichten, die die öffentliche Debatte dominieren. Sie haben sicherlich oftmals einen wahren Kern. Die KGSt®-Umfrage zum Thema „Open Source in Kommunen“ im Jahr 2020 hat gezeigt, dass der Einsatz von Open-Source-Software nach wie vor mit vielen Vorurteilen belegt ist. Gerade aus diesem Grund braucht es in Zukunft eine differenziertere Betrachtung. Denn oftmals liegt das vermeintliche Manko nicht an der Freien Software selbst, sondern beispielsweise an fehlenden Steuerungsprozessen oder einem unzureichenden Projektmanagement.
In diesem Beitrag werden die sehr häufig diskutierten Vorurteile rund um Open-Source-Software aufgegriffen. Der komplette Broschüre mit Quellenverzeichnis ist unten verlinkt.
Vorurteil: „Von einer Abhängigkeit in die andere.“
Beim Einsatz von IT befinden sich Kommunalverwaltungen immer in einer Art „Abhängigkeitsverhältnis“. Unter „Digitaler Souveränität“ wird daher das selbstbestimmte „Steuern von Abhängigkeiten“ verstanden:
Ein bewusster Umgang mit Abhängigkeiten in der Digitalisierung setzt die Einsicht voraus, dass Abhängigkeiten unvermeidbar und nicht in jedem Fall problematisch sind. Vielmehr geht es um die planvolle Wahl von Abhängigkeitsgraden.
— Kar/Thapa: Digitale Souveränität als strategische Autonomie. Umgang mit Abhängigkeiten im digitalen Staat.
Beim Einsatz von Open-Source-Software (OSS) beschränkt sich das Abhängigkeitsverhältnis lediglich auf eine „Dienstleisterabhängigkeit“. Denn der Software-Code an sich ist öffentlich. Das heißt auch, dass mit Betrieb, Weiterentwicklung oder Support unterschiedliche IT-Dienstleister beauftragt werden können, ohne die IT-Struktur der Verwaltung durch vollkommen neue Programme grundsätzlich verändern zu müssen.
Dafür ist allerdings frühzeitig zu betrachten, wie „vital“ ein Open-Source-Projekt ist: Wenn es sich um eine Lösung von nur einer Handvoll Entwickler handelt, ist dies problematisch für einen professionellen Betrieb in der Verwaltung. Dies gilt im Übrigen auch für proprietäre Software und ist häufig bei Anbietern von „Nischenprodukten“ der Fall. Wenn hingegen eine große, durchaus auch kommerzielle, Community hinter der Lösung steht und mit dem Code arbeitet, dann ist ein nachhaltiger Einsatz in der Verwaltung möglich.
Dies ist im Rahmen einer üblichen Marktrecherche zu evaluieren und kann beispielsweise aus der Aktivität in Code Repositorys wie GitHub abgelesen werden. Dabei handelt es sich um Plattformen, auf denen Open-Source-Software communitybasiert weiterentwickelt wird. Auch ein Austausch mit anderen Kommunen bietet sich dafür an.
Kurzum:
Es gibt gerade im Kontext der IT immer „Abhängigkeitsverhältnisse“. Das Risiko von Abhängigkeiten lässt sich beispielsweise reduzieren, wenn hinter einer Lösung eine große Community steht. Durch den Einsatz von OSS werden insbesondere Herstellereinschlüsse vermieden, sodass sie mit einer richtigen „Governance“ zu mehr digitaler Souveränität beiträgt.
Vorurteil: „Open Source ist offen und dadurch nicht sicher.“
Natürlich ist ein Code, der veröffentlicht wird, im ersten Moment erst einmal „unsicherer“, da Sicherheitslücken einfacher entdeckt werden können. Aber gerade durch die Veröffentlichung kann dieser von einer großen Community umfänglich getestet und Sicherheits-Reviews unterzogen werden, was ihn dann grundsätzlich sicherer macht.
So wurde auch ein Sicherheitsrisiko in der Corona-Warn-App nur aufgedeckt, weil der Code ab einem gewissen Zeitpunkt öffentlich war. Dieser Fehler konnte dank einer aufmerksamen Community schnell behoben werden. Ein guter Beweis für die Sicherheit von Open-Source-Software ist, dass auch Verschlüsselungssoftware offen ist.
Sogenannte White-Hat-Hacker werden daher, beispielsweise im Rahmen von Hackathons oder sogenannten Bug-Bounty-Programmen, regelmäßig einbezogen, um OSS zu prüfen und für den guten Zweck zu „hacken“. Beispielsweise gab es hierzu das EU-Projekt EU-FOSSA2129, welches umfangreiche Sicherheitsaudits durch Expert*innen zum Ziel hatte. Bei Bug-Bounty-Programmen werden Preise an die „Hacker“ ausgelobt, die eine Sicherheitslücke entdecken.
Der gegensätzliche Ansatz will Sicherheit durch Geheimhaltung schaffen – auch als „Security through Obscurity“ bekannt. „Ein auf dem Geheimhalten des Software-Codes basierendes Sicherheitskonzept gilt unter Fachleuten als ineffektiv, weil Sicherheitsprobleme dadurch tendenziell eher versteckt als beseitigt werden.“ „Der Einsatz von FLOSS bietet per se keine Gewähr für ein sicheres System. Er bietet in diesem Prozess jedoch bedeutende strategische Vorteile“, so das Bundesamt für Sicherheit in der Informationstechnik.
Vorurteil: „Open Source hat eine wesentlich geringere Qualität und ist nicht so benutzerfreundlich wie proprietäre Software.“
Es ist nicht von der Hand zu weisen, dass OSS manchmal Einbußen in Design und „User Experience“ hat – also dem „Look and Feel“ beim Arbeiten mit der Software, insbesondere dann, wenn eine Anwendung nicht regelmäßig auf einen neuen Stand gebracht worden ist und veraltete Darstellungen enthält.
Das lässt sich aber keinesfalls pauschalieren: Viele bekannte Lösungen wie der Mozilla Firefox, das mobile Android-Betriebssystem oder die Content Management Systeme WordPress, Drupal und Typo3 basieren auf OSS und stehen proprietärer Software in Nichts nach beziehungsweise bieten sogar eine wesentlich umfangreichere Funktionalität.
Genau wie bei proprietärer Software, gibt es auch Open-Source-Software, die in Sachen User Experience noch Potenzial hat. Marktanbieter unterliegen hier sicherlich einem größeren Druck, da dies ein entscheidender Faktor sein kann, damit sich der potenzielle Nutzende für das Produkt entscheidet. Die „Ästhetik der Nutzung“ ist in einer digitalisierten Welt von enormer Bedeutung. Es zählt häufig die letzte Nutzendenerfahrung als Maßstab – und das kann dann eben auch Amazon oder Netflix sein.
Die Aussage lässt sich so pauschal nicht treffen. Perspektivisch sollte hier aber auch im OS-Bereich zunehmend „nachjustiert“ werden.
Vorurteil: „Open-Source-Software kann nicht ausgeschrieben werden.“
Der Code von Open-Source-Software selbst ist öffentlich. Damit ist er nach herrschender Meinung unentgeltlich. Die Software an sich unterliegt daher nicht dem Vergaberecht.
Vom Beschaffungs- und Vergaberecht umfasst sind allerdings die anhänglichen Dienstleistungen wie Weiterentwicklung, Support oder Sicherheitsaudits. Es ist daher im Einzelfall zu prüfen, inwiefern das Vergaberecht auch bei Open-Source-Software anzuwenden ist. Während der „Direktdownload ohne externe Dienstleister“ vergaberechtsfrei ist, ist Vergaberecht anzuwenden, sobald externe Dienstleister ins Spiel kommen.
Dienstleistungen im Kontext von Open-Source-Software können Gegenstand von Ausschreibungsverfahren sein. Dies betrifft auch Weiterentwicklungen. Wenn OSS zielgerichtet weiterentwickelt wird, sind nicht mehr so viele Neuentwicklungen erforderlich.
Vorurteil: „EVB-IT-Verträge sind nicht mit Open-Source-Software vereinbar.“
Klassische Vollverträge sind tatsächlich nicht mit OSS vereinbar. Denn es gibt ja gerade keinen Anbieter, der z. B. die Überlassung abdecken kann. Diese Vertragsform ist also schlichtweg nicht erforderlich!
Aber für Pflege und Wartung können auch im Open-Source-Bereich Dienstleistungs-EVB-IT Verträge abgeschlossen werden (s. o.). Die Beschaffung der mit OSS verbundenen Dienstleistungen ist auch unter Anwendung der EVB-IT-Musterverträge möglich. Dabei sind allerdings einige Besonderheiten zu beachten. Eine gute Hilfestellung liefert die „Handreichung zur Nutzung der EVB-IT beim Einsatz von Open-Source-Software“ von der OSB Alliance.
Vorurteil: „Die Öffentliche Verwaltung verstößt gegen das Gebot der Wettbewerbsneutralität, wenn sie Software unter freier Lizenz veröffentlicht.“
Wenn die Verwaltung die Eigenentwicklung kommerziell vermarkten würde, kann die Aussage zutreffen. Es verstößt aber nicht gegen die Wettbewerbsneutralität, wenn Anwendungen, ggf. auch in interkommunalen Entwicklergemeinschaften, selbst (weiter)entwickelt und verbreitet werden.
Die Öffentliche Verwaltung sollte sogar einen Beitrag an die Community leisten und nicht nur nehmen, sondern auch zurückgeben. Dies ist ggf. auch lizenzrechtlich so vorgesehen (Stichwort „Copyleft“) und entspricht dem Gedanken „Public Money? Public Code!“
Vorurteil: „Freie Lizenzen sind mit rechtlichen Risiken verbunden.“
Genau wie proprietäre Software unterliegt auch Open-Source-Software einer Lizensierung. Lizenzen sind mit Rechten verbunden. Bei Freier Software drücken diese sich in den vier Freiheiten aus – aber auch mit Pflichten. Die Pflichten sind gerade dafür da, anderen die Rechte zuzusichern. Die rechtlichen Risiken sind nicht größer als im proprietären Bereich, das Lizenzmanagement muss allerdings professioneller gestaltet werden.
Kommunen müssen sich im Rahmen der Open-Source-Governance mit dem Lizenzmanagement auseinandersetzen. Hier können auch externe Sachverständige oder Beratungsstellen, beispielsweise das sog. „Legal Network“ bei der FSFE, herangezogen werden.
Vorurteil: „Freie Software ist schlecht für die Wirtschaft.“
Auch mit Open-Source-Software lässt sich Geld verdienen! Und so gibt es auch eine wachsende Open-Source-Wirtschaft. Das Geschäftsmodell liegt hier in den Dienstleistungen, die es rund um den Einsatz von Open-Source-Software braucht. Beispiele sind Support, Weiterentwicklung, Service oder Beratung. Open-Source-Software ist mit Geschäftsmodellen vereinbar und die damit verbundenen Dienstleistungen können auch kommerziell angeboten werden.
Häufig sind diese Geschäftsmodelle gerade in KMU anzutreffen. Sie werden mit Open-Source-Software konkurrenzfähig, was gut für die Wirtschaft ist.
Vorurteil: „OSS ist sinnlos, weil der Code sowieso nur von Expert*innen verstanden wird“
Beim „Verstehen“ geht es insbesondere um den Zugang zu Information und Wissen, der bei öffentlicher Software Teil des demokratischen Selbstverständnisses ist („Public Money? Public Code!“). Auch wenn die Kommune in ihrer Rolle als Nutzerin den Quellcode nicht selbst verstehen kann, besteht die Chance, dass in der Community von „sachverständigen Dritten“ die Sicherheit der Software geprüft und Sicherheitslücken entdeckt werden.
Der Sinn eines öffentlichen Codes zielt nicht allein darauf ab, dass der Nutzende, beispielsweise die Verwaltung, ihn verstehen kann. Es geht insbesondere darum, den Code einer breiten Community zugänglich zu machen, die ihn in der Rolle eines „unabhängigen sachverständigen Dritten“ prüfen kann.
Vorurteil: „Open Source ist selbstgemacht und nicht kommerziell.“
Es gibt zahlreiche Unternehmen, die Geschäftsmodelle auf Basis von Open-Source-Software entwickelt haben. Sie bieten mit OSS verbundene Dienstleistungen wie Weiterentwicklungen, Support oder Services an. Teilweise wird Open-Source-Software auch mit weiteren Features versehen und zusätzlich proprietär lizenziert. Dann handelt es sich nicht mehr um gänzlich Freie Software. Dies ist häufig, nicht immer, bei sogenannten „Enterprise Editions“ von Software-Lösungen der Fall.
Der wohl beste Beweis für die kommerzielle Lukrativität von Open Source ist der größte Verkauf eines Software-Unternehmens in der Geschichte: IBM kaufte 2019 das Open-Source-Unternehmen Red Hat für eine Summe von rund 34 Milliarden Dollar. Open-Source-Software kann mit Geschäftsmodellen verbunden werden. Diese beinhalten dann nicht die Lizenzierung, sondern die Dienstleistungen rund um den Einsatz von OSS.
Vorurteil: „Open Source entsteht in der Bastelstube.“
Eine Vielzahl von Freie-Software-Projekten geht auf die Initiative von Freiwilligen zurück. Dass der Code ausschließlich von Hobbyprogrammierer*innen stammt, ist trotzdem ein Vorurteil. Viele Beitragende im Bereich der Freien Software sind hochqualifizierte IT-Profis.
— Free Software Foundation Europe; Kompetenzzentrum Öffentliche IT am Fraunhofer Fokus
Dieses Zitat drückt alles aus: „Community“ ist nicht gleichzusetzen mit „unprofessionell“. Ganz im Gegenteil! Hinter öffentlichem Code stecken regelmäßig gefragte Expert*innen und darüber hinaus auch große, weltweit agierende Unternehmen. Innovation entsteht in diesem Bereich gerade durch ein Open-Source-Ökosystem, das global auf Fachwissen zurückgreift. Dabei handelt es sich um ein Vorurteil. Dieses ist gerade im Kontext der Zusammenarbeit mit der Open-Source-Community abzulegen.
Es gehört daher auch zu einer Open-Source-Governance, die Community bzw. ihre Funktionsweise zu kennen und sie zu unterstützen.
Auszug (mit leichten Anpassungen) aus:
KGSt Kommunale Gemeinschaftsstelle für Verwaltungsmanagement (Hg): Open Source in Kommunen. Ein Baustein für mehr Digitale Souveränität. Teil 1: Grundverständnis, Potenziale und Herausforderungen. Bericht Nr. 05/2021. Der Bericht steht unter der Creative-Commons-Lizenz CC-BY-SA 4.0 (Namensnennung und Weitergabe unter gleichen Bedingungen).