Nachhaltiger Open Source Einsatz für die digital souveräne Verwaltung

Hinweise und Erläuterungen der OSB Alliance zum Einsatz von Open Source Software

Herausgeber: © 2020 Open Source Business Alliance – Bundesverband für digitale Souveränität e.V.
Die pdf-Version können Sie hier herunterladen.

Autoren:

  • Dipl.-Wirt.Inform. Alfred Schröder, GF Gonicus GmbH, Vorstand OSBA
  • Dipl.-Inform. Lothar K. Becker, GF .riess applications GmbH, Vorstand OSBA
  • Markus Feilner (Feilner IT), Mitglied WG Public Affairs OSB Alliance
  • Karl Krüger, Bereichsleiter Public Sector

1 Kurzfassung

Open Source ist unverzichtbarer Bestandteil auf dem Weg zu digitaler Unabhängigkeit, Flexibilität, Offenheit und Innovation. Dieser Weg bringt Veränderungen für etablierte Beschaffungsprozesse und Betriebsmodelle der Informationstechnologie in der öffentlichen Verwaltung mit sich. Große und erfolgreiche Internetkonzerne haben diese Veränderungen etabliert. Viele technische, wirtschaftliche und gesellschaftliche Innovationen der letzten Jahre wären ohne dieses Umdenken nicht möglich gewesen.

Nur wenn bereits bei der Beschaffung von IT-Lösungen auch das SoftwareEntwicklungs- und Lizenzmodell betrachtet wird, lassen sich die Vorteile und Herausforderungen von Open Source Software (OSS) erkennen und bewerten. Ebenso hilft es, die Geschäftsmodelle und Unternehmenskulturen hinter Open Source Projekten zu verstehen, wo große Unterschiede zu den Herstellern von proprietären Lösungen zu finden sind.

Im Open Source Umfeld bieten wirtschaftlich erfolgreiche, meist mittelständische Akteure ihren Kunden ein breites Spektrum an professionellen Leistungen. Sie erbringen individuelle Dienstleistungen, verkaufen Open Source Produkte oder offerieren „as a Service“-Dienste. Auftraggeber können so aus einer breiten Palette an Angeboten genau das individuell passende herausfiltern.

Damit der Beschaffungsprozess die vielfältigen Angebotsmöglichkeiten von Open Source berücksichtigen kann, sollte die IT-Beschaffung ein Umdenken weg von produktfokussierten Ausschreibungen anstreben. Zukünftig muss es um anforderungsund funktionsorientierte Ausschreibungen gehen. Diese ermöglichen einen umfassenden Blick auf die vielfältigen  Lösungsansätze, um den individuell besten Weg auswählen zu können. Die Betrachtung der Wirtschaftlichkeit sollte alle Kosten über den gesamten Betriebszeitraum einbeziehen und nicht nur die initialen Produktkosten berücksichtigen. Nur so lässt sich eine (diskriminierungsfreie) Vergleichbarkeit zwischen stärker dienstleistungsgeprägten Angeboten und Produktkäufen herstellen.

Der Open Source Weg bedeutet nicht nur Veränderungen für die Beschaffung selbst, sondern auch für die Umsetzung und den Betrieb von digitalen Lösungen in der öffentlichen Verwaltung. Innerhalb der Organisationen sollte das Verständnis für das Open Source Modell Schritt für Schritt aufgebaut werden. Jede in diese Veränderungen getätigte Investition bringt letztlich eine Fülle an funktionalen und strategischen Vorteilen, insbesondere bedeutet es die Unabhängigkeit von einzelnen Herstellern und ist damit die Grundlage für eine digitale Souveränität, die zu Recht auch von Seiten der Politik eingefordert wird.

Die Beschaffung digitaler Lösungen für die Zukunft muss folglich strategisch und nicht nur pragmatisch gedacht werden. Digitalisierung und der Einsatz von Open Source müssen deshalb „Chefsache“ werden.

2 Ausgangslage

Bei der Beschaffung einer Software stehen Themen wie Funktionalität, Benutzerfreundlichkeit und auch der Preis im Vordergrund. Aspekte wie das Entwicklungsmodell, Transparenz, Sicherheit und Vertraulichkeit von Daten sind selten zentrale Entscheidungskriterien.

Dabei hat gerade die Art und Weise, wie Software entstanden ist und unter welchen Bedingungen sie zur Verfügung gestellt wird, großen Einfluss auf die technischen und strategischen Handlungsmöglichkeiten des Anwenders. Der Open Source Ansatz zur Entstehung und Nutzung von Software spielt hier eine immer größer werdende Rolle. Das gilt umso mehr, weil bisherige Modelle sich aufgrund von einseitigen Abhängigkeiten für viele Anwendungsszenarien als ungeeignet erwiesen haben.

Beschaffung, Betrieb und Service von proprietären Produktlizenz Lösungen sind häufig kurzlebig, weil sie oft nur für den aktuellen Bedarf gedacht sind. Die Restriktion durch die Bindung an einen einzigen Hersteller macht sie sogar innovationshemmend und damit nicht nachhaltig, weil derartige Prozesse nicht der Kontrolle des Anwenders unterliegen, sondern dieser der Strategie des Anbieters unterworfen ist, beispielsweise bei der Weiterentwicklung.

Bei OSS bestehen Vorteile insbesondere in der Quellcodeverfügbarkeit, der Sicherheit durch Überprüfbarkeit, der Möglichkeit der Anpassung an neue Anforderungen sowie der Unabhängigkeit von einzelnen Anbietern. Damit diese Vorteile erkannt und für die eigene IT genutzt werden können, ist es erforderlich, die veränderten Umstände dieses Ansatzes zu verstehen und in Beschaffung und Betrieb zu integrieren. So wird eine wichtige Grundlage geschaffen, selbstbestimmt und professionell alle zunehmend größer werdenden Herausforderungen einer modernen IT lösen zu können. Mit anderen Worten: Es geht um nichts weniger als um digitale Souveränität!

Die heutige Abhängigkeitsproblematik der öffentlichen Verwaltung hat auch eine Studie von PricewaterhouseCoopers im Auftrag des Bundesinnenministeriums Ende 2019 klar herausgearbeitet.

Mit diesem Papier wollen wir näher erklären, wie mit den (notwendigen) Veränderungen in der öffentlichen Verwaltung der Weg in die Digitale Souveränität gelingen kann. Das gilt sowohl für die IT-Strategie und die Beschaffung, als auch für die Bereiche Betrieb und Service. Bedarfsträger und Erbringer sollen so schneller und einfacher zueinander finden.

2.1 Open Source Ansatz

Die Verfügbarkeit von Software im Quellcode und die Möglichkeit, diesen Quellcode nach den eigenen, ganz konkreten Bedürfnissen und Anforderungen anpassen zu können, ist nicht neu und lässt sich bis zu den frühen Zeiten der IT zurückverfolgen. Das Prinzip setzt darauf, dass sich gute Software durch gemeinschaftliche Arbeit, Kontrolle und Auswahlprozess mit einer breiten Anzahl von Entwicklern und Anwendern zur besseren Software entwickeln kann. Die Entwicklung folgt nicht dem Plan eines einzelnen Entwicklungsleiters, eines Architekten, sondern funktioniert nach einem evolutionären Ansatz, mit einer Vielzahl von Ideen, Lösungsansätzen und Tests: Gute Lösungen und Bausteine werden übernommen und weiterentwickelt; schlechte Ansätze und fehlerhafter Code setzen sich nicht durch.

Insbesondere Software für typische und alltägliche Herausforderungen in der Informationstechnologie profitiert von diesem offenen Ansatz, weil er eine optimale Ausgangsbasis für individuelle Anpassungen und konkrete, spezifische Lösungen ermöglicht. Das legt die Grundlage für gemeinsame Innovation und Wertschöpfung – Software ist dann eine Dienstleistung und nicht nur eine Vervielfältigung eines Massenprodukts. Das Spektrum reicht von Anpassung über Wartung und Support bis hin zu Software „as a Service“.

So entstehen Unabhängigkeit und Flexibilität für das beständig dynamischer werdende Umfeld des digitalen Wandels. Aber Open Source Software bringt auch neue Herausforderungen für Unternehmen und Behörden, die diese Vorteile nutzen möchten: Der Entwicklungsprozess, die Fülle an Softwaremöglichkeiten und die Anbieterlandschaft bedingen unter Umständen eine Veränderung von tradiertem Produktverständnis.

OSS, und damit natürlich auch das ihr eigene Entwicklungsmodell, hat sich in Zeiten des digitalen Wandels insbesondere bei erfolgreichen Akteuren der Internetwirtschaft, aber auch bei traditionellen Unternehmen durchgesetzt. Auf dieser Basis werden flexible, innovative und disruptive Ideen umgesetzt und haben zu großem wirtschaftlichem Erfolg geführt.

2.2 Open Source und wirtschaftliche Interessen (Business Modelle)

Auch wenn OSS immer mit der grundsätzlichen Idee der gemeinschaftlichen Entwicklung, der Freigabe einer Software und auch mit dem Begriff Community verbunden wird, so existiert für den professionellen Einsatz typischerweise ein ganzes Ökosystem an greifbaren, wirtschaftlich handelnden Unternehmen. Die Community steht häufig für Innovation und Problemlösung.

OSS ist natürlich auch oft kommerziell und ein erheblicher Teil ihrer Entwickler wird für ihre Arbeit von Ökosystem-Partnern bezahlt. Die Wertschöpfung dieser Unternehmen beschränkt sich nicht auf die Vervielfältigung einer einmal entwickelten Software, sondern bringt für Anwender ganz konkrete, wenn auch je nach Geschäftsmodell durchaus unterschiedliche, Vorteile mit sich.

Enterprise-Support auf branchenüblichem Niveau, das Übernehmen von Verantwortung, die Wartung der Software, das zuverlässige Einhalten von Releasezyklen, aber auch die Anpassung der Open Source Software an individuelle Bedürfnisse sind nur einige der etablierten Geschäftsmodelle. Die genannten Vorteile bleiben bei allen Modellen erhalten.

Von Haus aus sind die Unternehmen, die sich auf OSS fokussiert haben, etwas anders strukturiert und aufgestellt. Stark vertreten sind innovative, hochspezialisierte, kleinere und mittelständische Unternehmen.

2.3 Klassische IT Beschaffungs- und Einkaufsprozesse

Die IT-Beschaffungs- beziehungsweise Einkaufsprozesse in Behörden sind auf Mainstream-Produkte ausgerichtet, sowohl bei Hardware als auch bei Software. Gerade große Institutionen orientieren sich meist an besonders großen, proprietären Anbietern, aufgrund der Skalierbarkeit und dem Streben nach einheitlichen Lösungen. Dabei fokussiert sich die Beschaffung auf pragmatische, seltener auf strategische Fragestellungen. Vollständige und fertige Gesamtlösungen aus einer Hand sind gewünscht. Niemand möchte sich mit Aufgaben der Integration unterschiedlicher Softwarekomponenten auseinandersetzen.

In Ausschreibungen konzentrieren sich die Bewertungskriterien nur selten auf strategische Aspekte wie Digitale Souveränität oder die langfristige Unabhängigkeit des Auftraggebers. Meist stehen spezifische Produkteigenschaften und wirtschaftliche Aspekte wie der Preis pro Lizenz im Vordergrund.

Die Bevorzugung solcher Kriterien durch die zuständigen IT Fachleute in Behörden ist verständlich, tragen doch auch sie die Verantwortung für das Funktionieren der IT in ihrer Behörde und das oft mit geringen personellen Ressourcen. Sie sind die ersten die es trifft, wenn etwas nicht funktioniert oder auch nur, weil es anders funktioniert. Eine schnelle Antwort unter dem Hinweis auf den Quasi-Markt-Standard eines großen Anbieters fällt hier denkbar leichter als komplexe Erklärungen zur grundlegenden Neuorientierung. Nicht zuletzt bestehen dort auch Bedenken, das Nutzererlebnis mit einer neuen, anderen Lösung zu belasten, die nicht dem bekannten Quasi-Standard entspricht. Dabei geht es weniger um effektive Benutzbarkeit oder Benutzerfreundlichkeit, sondern vielmehr um Gewöhnung und Veränderung.

Ein weiterer Aspekte ist, dass man im Beschaffungsprozess von OSS mehr „Stellschrauben“ hat, die Implementierung einer Lösung zu begleiten. Open Source bedeutet in seiner Vielfalt manchmal auch die Qual der Wahl und man muss sich auf neue und andere Fragestellungen einlassen als die vergleichsweise einfache Frage nach Produkt A oder B. Hierauf gehen wir später noch einmal vertieft ein.

2.4 Der Betrieb von Open Source Lösungen

Im Einsatz bietet OSS, welche man mit verfügbaren Subskriptions- oder Supportvereinbarungen nutzt, sogar mehr Sicherheit und Flexibilität als proprietäre Software. Gewährleistungsrechte und gegebenenfalls eingeräumte Garantien sind gegenüber dem IT Dienstleister mindestens genauso gut durchsetzbar wie gegenüber einem proprietären Anbieter.

Darüber hinaus kann man sich als Anwender auch selbst mit seinen konkreten Wünschen oder Erfordernissen in die Weiterentwicklung einer Anwendung einbringen. Das ist bei großen proprietären Anbietern regelmäßig nicht vorgesehen.

3 Auswirkungen auf die Beschaffungsstrategie

3.1 Erwartungshaltung und Realität

Im Rahmen einer zunehmenden Auseinandersetzung mit strategischen Fragen wie zum Beispiel der digitalen Souveränität von Staat, Unternehmen und Individuen, gewinnt die  Beschäftigung mit OSS und deren Prinzipien für Bund und Länder noch mehr an Bedeutung. Auch im Rahmen verschiedener größerer Ausschreibungen wird immer häufiger auf den Aufbau von Open Source Lösungen abgezielt. Diese Entwicklung beobachtet die OSBA aufmerksam und freut sich über diese Signale, die zuletzt auch bei Themen wie der Corona Warn App oder auch bei Gaia-X und der SCS-Architektur des Souvereign Cloud Stack noch deutlich sichtbarer geworden sind.

Dennoch erscheint es weiter verbreitet zu sein, dass bei der Beschaffung von Softwareprodukten aus der langjährigen Praxis heraus oft der Wunsch nach homogenen Produkten eines einzelnen Herstellers (One-Stop-Shopping) vorherrscht.

Im Open Source Umfeld gibt es kaum Unternehmen, die alleine für die ganze Bandbreite eines Lösungsportfolios als Hersteller stehen. Stattdessen gibt es eine Vielzahl von hoch spezialisierten Softwareunternehmen, die Lösungen für spezifische Problemstellungen entwickeln. Es sind Distributionshersteller, die OSS zu gewarteten Sammlungen zusammen stellen. Es gibt Integratoren, die Komponenten zu Gesamtsystemen verbinden und Betreiber von Rechenzentren, die Open Source Lösungen „as-a-Service“ bereit stellen. Und es gibt Dienstleister, die sich auf Schulungs- und Supportbedarf fokussieren oder reine Beratungsleistungen zu den Komponenten anbieten.

All diese Angebote haben gemeinsam, dass sie viele Freiheiten in Bezug auf die Integration und das Zusammenspiel von einzelnen OSS-Lösungen bei der Adressierung von ganz konkreten Anforderungen bieten. Will man diese Freiheiten nutzen, bedeutet es aber auch gleichzeitig die Notwendigkeit, sich mit unterschiedlichen Lösungen und Partnern auseinanderzusetzen oder einen passenden Auftragnehmer als übergeordneten Koordinator einzubeziehen. Die Anforderungen an Auftraggeber oder auch an durch sie beauftragte Koordinatoren wachsen.

Die maßgenau passenden Lösungen für komplexe Anforderungssituationen kommen oftmals nicht von der Stange, sondern entstehen auch beim und mit dem Auftraggeber. Modulare Lösungsbausteine, die über offene Schnittstellen miteinander integriert werden, ermöglichen eine bessere Adressierung des individuellen Bedarfs. Diese Umsetzung erfordert aber auch entsprechende architektonische Planungen und die Zusammenarbeit von Bedarfsträgern und den Lieferanten der „Bausteine“.

3.2 Software als Dienstleistung

Spätestens die Verbreitung von Cloud-Lösungen hat gezeigt, dass Software nicht einfach ein Produkt wie jedes andere ist, sondern vielmehr eine Dienstleistung, die konkrete Anforderungen und Bedürfnisse von Anwendern adressiert. Während diese bei proprietärer Software mit Support, Wartung oder Software „as-a-Service“ endet, kann OSS hier noch einen Schritt weiter gehen und erlaubt eine detaillierte Analyse und auch Anpassung, um die Anwender-Anforderungen optimal abzudecken.

Mehr und mehr übernehmen Service-Modelle von Software Assurance und Mietmodellen bis hin zu Angeboten aus der Cloud den Markt. Nicht immer geschieht das zum Nutzen des Kunden: vor allem bei proprietärer Software aus der Wolke bestehen weitere, zusätzliche Sicherheits- und Abhängigkeitsrisiken.

OSS legt den Fokus dagegen auf die konkrete Wertschöpfung für den Kunden, es werden keine technologischen Abhängigkeiten geschaffen. Damit ist die Basis für echte digitale Souveränität gelegt. Software ist so wirklich eine Dienstleistung.

3.3 Situation der klassischen Supplier

Die klassischen, etablierten und vor allen Dingen großen Supplier von Bund und Ländern und deren Vertriebsmodelle orientieren sich immer noch an Lizenzprodukten. Auf diese Weise ist für alle Seiten bislang eine gute Vergleichbarkeit sichergestellt und die klassischen Einkaufs- und Angebotsprozesse können unhinterfragt weiter greifen.

Mit der wachsenden Nachfrage nach Open Source Technologien wächst die Erwartung, dass die Anbieter auch in diesem Umfeld Lösungen liefern können. Während einige Lieferanten verstehen, dass hier grundlegend andere Vorgehensweisen möglich und erforderlich sind, versuchen andere, die klassischen Produktansätze auch auf OSS und Dienstleistungen  anzuwenden.

Die Gewissheit, dass das Open Source Modell auch ganz andere Vorgehen ermöglicht, muss sich in der Breite erst nach und nach durchsetzen. Hier ist die Bereitschaft, sich auf andere Prozesse einzulassen, auf allen Seiten gefordert. Und nur ein Umdenken ermöglicht die volle Nutzung des strategischen Potentials von Open Source Technologien, ohne von einer  Abhängigkeit einfach nur in die nächste zu geraten.

3.4 Wirtschaftlichkeitsvergleich

Oberstes Prinzip eines Beschaffungsvorgangs in der öffentlichen Verwaltung ist das Wirtschaftlichkeitsprinzip. Dem stellt sich selbstverständlich auch Open Source. Allerdings sollte schon darüber nachgedacht werden, ob in die wirtschaftliche Vergleichbarkeit nicht zusätzliche Kriterien eingebracht werden müssen, um den oben benannten Vorteilen auch den Wert der höheren Souveränität, Nachhaltigkeit und Innovationsfähigkeit beimessen zu können.

So ist nach aller Erfahrung einem höheren Dienstleistungsanteil (OSS Business Modell: Anpassung, Integration, Supportaufwände) und Eigenanteil des Bedarfsträgers (Knowhow-Aufbau, höhere Komplexität der Lösung) am Beginn der Nutzung selten die höhere Ausfallsicherheit im Vergleich zu einem alleinigen Produkthersteller klassischer Lösungen (proprietäres (Miet)Lizensierungsmodell) gegenüber gestellt.

Open Source Lösungen haben aufgrund ihrer individuellen, bedarfsgerechten Natur eine bei weitem längere Nutzungsdauer. Wer dies in längerfristige Wirtschaftlichkeitsbetrachtungen,  über den Lizenzzyklus eines klassischen Produktes hinaus einbezieht, findet bei Open Source Lösungen regelmäßig bessere Total Cost of Ownership (ToC).

Keine Berücksichtigung finden in heutigen Wirtschaftlichkeitsbetrachtungen kalkulatorische und tatsächliche Kosten für die Abhängigkeit von einem Hersteller sowie die Ausfallrisiken  eines solchen. Nur weil ein Unternehmen sehr groß ist, bedeutet das nicht, dass es seine Produktstrategie nicht auch kurzfristig gegen die Interessen des Anwenders verändern kann – bis hin zum Totalausfall. Eine Risikobewertung kann dabei helfen, diese Faktoren zu quantifizieren.

Heutiges Risiko-Management bietet jedoch Wege und Berechnungen, solche Kosten in Wirtschaftlichkeitsbetrachtungen einzubeziehen. Dabei schlägt Open Source Software die klassischen Hersteller bei weitem.

4 Eckpunkte und Empfehlungen für den OSS-Einsatz

Wenn man die aufgeführten Aspekte in seine IT-Strategie und Überlegungen zur Umsetzung einbezieht, ergeben sich ganz entscheidende Vorteile, aber auch Herausforderungen.

4.1 Veränderung bei der Beschaffung und Einführung

4.1.1 Schrittweiser Aufbau von Erfahrungen

Der Einsatz von OSS eröffnet die Chance, sich erstmals im Detail mit einer Softwarelösung auseinandersetzen zu können. Dies bringt eine Reihe von Möglichkeiten mit sich, die sowohl strategische und operative als auch wirtschaftliche Vorteile bedeuten. Deshalb empfiehlt es sich im Idealfall, Stück für Stück eigenes Know-how und eigene Erfahrungen im Umgang mit den Open Source Ökosystemen aufzubauen oder einen passenden, erfahrenen Partner mit entsprechendem Ein- und Überblick dafür zu finden. Dann erschließt sich das volle Potential an Unabhängigkeit und Souveränität.

4.1.2 Prozess statt “Big Bang”

Im Gegensatz zur Stichtags-Einführung eines neues Produkts muss man, insbesondere in komplexen Anforderungssituationen, eine Migration zu OSS eher als Prozess begreifen. Anpassungen und Integration erlauben das schrittweise Erreichen eines optimalen Ergebnises unter Einbeziehung der Anwendererfahrungen.

4.1.3 Definition von Anforderungen – nicht von Produkten

Die Fülle von Möglichkeiten im Open Source Umfeld erlaubt die Formulierung von Anforderungen, ohne sich auf Produkte festzulegen. Diese Möglichkeit sollte man nutzen, um optimale individuelle Lösungen zu finden.

Wer sich dagegen von vornherein auf ein bestimmtes, gar marktbeherrschendes Produkt fokussiert, nimmt sich jede Möglichkeit der Individualisierung oder nachträglichen Anpassung an sich dynamisch entwickelnde Umgebungen.

4.1.4 Umgang mit Modularität

Oft sind Open Source Lösungen und auch OSS-Unternehmen spezialisiert auf eine bestimmte Herausforderung, die vielleicht nur einen Teil der anstehenden Aufgabe löst. In diesen Anforderungssituationen muss man Antworten auf die Integration unterschiedlicher Komponenten finden. Es gilt, verschiedene Module zu einer passenden Gesamtlösung zu integrieren, um so Unabhängigkeit und Flexibilität sicherzustellen, ohne große Einbußen in Bezug auf die Vorzüge monolithischer Systeme zu erleiden. Das fällt dank Open Source zwar leichter und sorgt am Ende auch für optimal angepasste Lösungen. Trotzdem entsteht so eine Aufgabe, die bei monolithischen Produkten nicht existiert. Hier muss man entweder einen passenden
Dienstleister identifizieren, der die Integration übernimmt oder das Know-how zur Integration selber aufbauen.

4.1.5 Skalierung unter Einbeziehung von Open Source Know-how

Bei der Zusammenarbeit mit den etablierten Suppliern sollte man diese zur Offenheit und Zusammenarbeit mit OSS Communities und dem gesamten OSS-Ökosystem auffordern. Nur so sind Nachhaltigkeit und Kontinuität in Bezug auf das Open Source Umfeld zu sichern und gleichzeitig wird so die notwendige Skalierung ermöglicht. Dieses Vorgehen ist wichtig, weil durch zentrale Vorgaben großer Bedarfsträger zum Kapazitätsbedarf das Ökosystem rund um ein bestimmtes OSS Projekt ohne Not an Grenzen stoßen kann. Eine Skalierung kann hier nicht über Mitarbeiterzahlen laufen, sondern nur über erprobte und belastbare Kooperationsmodelle. Hier sind Bedarfsträger, OSS Ökosystem und etablierte Service Anbieter gefordert, über „train the supplier“ Ansätze oder OSS Professionals als Multiplikatoren und Enabler die entsprechenden Ressourcen zu entwickeln.

4.2 Veränderungen im Betrieb und im Support

4.2.1 Wer nimmt, sollte auch geben – auch zu seinem eigenen Vorteil

Das Open Source System kann nur dann funktionieren, wenn der Nutzer selbst auch zum Kontributor wird. Sei es durch die Finanzierung von Weiterentwicklungen oder Fehlerbereinigungen über das Ökosystem (Subskription, Supportvertrag), die in die Software für alle eingehen oder auch durch eigene (selbst oder durch den Dienstleister) freiwillige Beteiligung in der Community. Nur so kann sichergestellt werden, dass sich das Open Source System weiterentwickeln kann und dass am Ende alle, auch der Nutzer der sich einbringt, kontinuierlich an den so geschaffenen Innovationen partizipieren können. Jede Weiterentwicklung durch Dritte kommt auch ihm zugute.

4.2.2 Community als Mehrwert sehen

Der Begriff der „Community“ in Zusammenhang mit Open Source Projekten wird oftmals als diffus und daher nicht greifbar wahrgenommen. Darüber hinaus gibt es auf Bedarfsträgerseite häufig wenig Erfahrung mit dieser „nicht greifbaren“ Gruppe an Beteiligten, die auch noch für sich reklamiert, nicht haftbar, völlig freiwillig und ohne klare Struktur und Planung zu sein. In Wahrheit trifft das aber nur einen Teil von Open Source Projekten, meist sehr „kleine“ und hochspezialisierte. Wenn man die „Community“ von größeren, relevanten Projekten analysiert, findet man im Wesentlichen drei ineinander übergehende Gruppen von Projektbeteiligten. Zum einen gibt es private, freiwillige Helfer, die meist recht anonym aber aus hohem  persönlichen Interesse und Motivation mitarbeiten. Daneben gibt es die businessorientierten Beteiligten. Dies sind Mitarbeiter oder gar deren Unternehmen selbst, die mit ihren Angeboten, meist für professionelle Anwender, ein wirtschaftliches Interesse an dem Projekt verfolgen. Sie tragen häufig einen großen Teil der Codeweiterentwicklungen als Spende an das Projekt bei, bieten aber natürlich auch den professionellen Anwendern die oben erwähnten Dienstleistungen wie Einführung, Bugfixing, Feature Entwicklung, Integration oder Support und  Schulungsdienstleistungen an.

Drittens stellen die Anwender der Software einen wesentlichen Bestandteil des Projekts und seiner „Community“ dar. Ein Open Source Projekt lebt sehr stark von Rückläufen und Beiträgen auch aus der Anwenderschaft.

Die Flexibilität und Souveränität, die durch die Vielfalt in diesen Communities erreicht wird, ist ein klarer Vorteil und Mehrwert einer communitybasierten Open Source Projektorganisation und fehlt annähernd vollständig im proprietären Produktgeschäft.

4.2.3 Schulungsaufwand richtig bewerten

Wie mehrfach betont, sollte der Bedarfsträger beim Einkauf und Betrieb einer Open Source Lösung auch eigenes Know-how bei sich und/oder seinem Dienstleister aufbauen. Auf Beschafferebene wird dies zunächst als zusätzlicher Mehraufwand gesehen. Dieser fällt zwar bei jeder neuen Lösung an, wird aber bei klassischen Produkten regelmäßig nicht eingepreist, obwohl selbst bei neuen Versionen von bereits eingesetzten Produkten ein Update oft mit dem Bedarf an zusätzlichem Know-how einhergeht. Unabhängig von der eingesetzten Lösung sollte man diesem Bedarf bei der Betrachtung Rechnung tragen.

5 Fazit

Digitale Souveränität gewinnt angesichts der zunehmenden Durchdringung aller Lebens- und Arbeitsbereiche mit digitalen Technologien immer mehr an Bedeutung. Informationstechnologie wird damit insbesondere für die öffentliche Verwaltung zu einem strategischen Thema. Open Source ist der Weg zu digitaler Souveränität. Dieser Weg bringt Veränderungen und auch Herausforderungen mit sich. Dieses Dokument soll dabei helfen, sich auf diese Veränderungen einzustellen. Die Beschäftigung mit diesen Themen und die Entscheidung für eine strategische IT-Beschaffung eröffnen das volle Potential einer digital souveränen Behörden-IT.

Anhang – Überblick möglicher Anbieter-Auftraggeber oder Projekt-Konstellationen

Subscription Open Source Produkt

Eine Vielzahl von Unternehmen treiben Open Source Projekte maßgeblich voran und bieten spezielle, laufend gewartete und supportete Versionen an. Als Auftraggeber kann man sogenannte Subskriptionen für den Einsatz des Produkts abschließen. Diese sichern u.a. den Zugriff auf stabile, gepflegte und getestete Releases einer Software und ermöglichen auch die Einbindung des Supports vom Hersteller oder Distributor einer Software oder eines Softwarepakets. Hinzu kommen oft weitere Leistungen, wie der Schutz vor Lizenzproblemen oder Produkthaftung. Dieser Ansatz ist in der Regel genauso einfach wie der Kauf proprietärer Software, sichert aber die Vorteile von Open Source Software.

Individueller Support-Vertrag

Der Open Source Ansatz ermöglicht es auch unabhängigen Dienstleistern auf Basis ihres Know-hows und ihrer Erfahrung mit einer OSS individuelle Support- und Wartungsvereinbarungen mit Auftraggebern abzuschließen. Entsprechende Vereinbarungen können sich auf standardisierte oder auch individualisierte Versionen einer OSS und deren Konfiguration erstrecken. Häufig bieten entsprechende Dienstleister auch Unterstützung bei Implementierung und Know-how-Transfer an. Dabei sind die Angebote meist nicht so universell, umfassend und generisch wie beispielsweise bei einem Distributions-Hersteller, können aber deutlich besser auf spezielle und individuelle Anforderungen eingehen.

Generalunternehmer

Insbesondere beim Aufbau von komplexeren Lösungen besteht oft der Bedarf, zahlreiche unterschiedliche Open Source Produkte zu kombinieren. Der Auftraggeber möchte aber vermeiden, eine Vielzahl unterschiedlicher Verträge abzuschließen oder eine entsprechende Anzahl an Suppliern zu koordinieren. In solchen Szenarien bietet sich der Weg über einen Generalunternehmer an. Dieser bündelt die unterschiedlichen Supplier und fungiert gegenüber dem Auftraggeber als zentraler Ansprechpartner. Im Gegensatz zum nachfolgend beschriebenen Modell, beschränkt sich die Rolle hier auf organisatorische und vertragliche Aspekte.

Bauherren-Vertreter-Modell (Architekt)

Wenn unterschiedliche Open Source Gewerke zu einer Gesamtlösung zusammengefügt werden, entstehen regelmäßig auch Aufgaben rund um die Integration unterschiedlicher Module. Diese Integrations-Aufgaben werden in diesem Modell sowohl bei der initialen Implementierung als auch im laufenden Betrieb von einem Dienstleister übernommen. Der Dienstleister entlastet somit den Auftraggeber. Der Integrator oder Architekt kann dabei auch die Rolle des Generalunternehmers übernehmen oder konzentriert sich auf die Aufgabe der Integration und Koordination der unterschiedlichen Gewerke. Hier wird sichergestellt, dass der Auftraggeber eine runde Gesamtlösung und den passenden Support für diese Gesamtlösung von einer
Stelle aus bekommt.

Train-the-Supplier-Modell

Am Markt gibt es eine Reihe von großen und etablierten Suppliern, die ihre Kompetenz im Bereich der konventionellen IT-Systeme in den vergangenen Jahren in einer Vielzahl von Projekten nachweisen konnten. Vor diesem Hintergrund bevorzugen viele Auftraggeber den Rückgriff auf diese erfahrenen Supplier, mit denen man in unterschiedlichen Auftragssituationen gute Ergebnisse erzielen konnte. Diese etablierten Supplier sind gefragt, das notwendige Open Source Know-how aufzubauen.

Hier greift das „Train the Supplier“ Modell. Etablierte Supplier greifen auf das spezielle Open Source Wissen zurück, indem sie einzelne oder mehrere erfahrene Unternehmen aus dem Open Source Ökosystem einbeziehen und sich von diesen das notwendige Wissen vermitteln lassen. In diesem Ansatz bietet sich das Potential einer breiten Skalierung, um den entstehenden Bedarf decken zu können. Die Supplier sind gefragt, das erforderliche Know-how mit Hilfe notwendiger Partnerschaften oder Beauftragungen an Experten aus dem direkten Open Source Umfeld aufzubauen.

Hilfe zur Selbsthilfe

Der Einsatz von Open Source ermöglicht die Unabhängigkeit von einzelnen Anbietern. Sollte der Wunsch oder die Notwendigkeit bestehen, kann ein Auftraggeber auch einen Weg einschlagen, der perspektivisch die Unabhängigkeit von Unternehmen noch erweitert. In diesem Szenario will der Auftraggeber mittel- und langfristig selbst die Verantwortung für den Betrieb und auch die Weiterentwicklung einer Open Source Lösung übernehmen oder zumindest selbst eine so enge Zusammenarbeit mit Open Source Communities aufbauen, um nicht auf weitere Unternehmen angewiesen zu sein.

Hier bindet man Dienstleister in den Aufbau einer Lösung ein, die explizit die Aufgabe haben, im Rahmen eines Projektes, Wissen an den Auftraggeber zu vermitteln. Dieses
Know-how soll den Auftraggeber in die Lage versetzen, selbst die Aufgaben eines Entwicklers oder Integrators zu übernehmen. Der Dienstleister bietet in diesem Fall Hilfe zur Selbsthilfe und macht sich mittel- oder langfristig überflüssig. Der Auftraggeber muss dann aber entsprechende Ressourcen bereitstellen und sich bewusst für die in diesem Kontext entstehenden vielfältigen Anforderungen entscheiden.

Das Positionspapier kann unter den Lizenzbedingungen der Creative Commons Lizenz „Namensnennung – Weitergabe unter gleichen Bedingungen 4.0 Deutschland (CC BY SA 4.0 International )“ wie folgt genutzt werden:

Herausgeber: © 2020 Open Source Business Alliance – Bundesverband für digitale Souveränität e.V.
Autoren: Dipl.-Wirt.Inform. Alfred Schröder, Dipl.-Inform. Lothar K. Becker, Karl Krüger
Titel: Nachhaltiger Open Source Einsatz für die digital souveräne Verwaltung
Lizenz: CC BY SA 4.0 International

Die pdf-Version können Sie hier herunterladen.