Mit der Hinwendung professioneller Anwender insbesondere aus der öffentlichen Verwaltung zu Open-Source-Produkten verändert sich zurzeit die Wettbewerbssituation im Softwaremarkt. Vor allem die Waffen der neuen Konkurrenz sind ungewohnt: Nicht durch aufwändiges Marketing oder überragende Funktionalität werden Kunden gelockt, sondern durch frei verfügbare Softwarelizenzen und freie Anpassungsmöglichkeiten. Speziell in den Bereichen Betriebssystem-Software und Büroanwendungen entsteht so eine Situation, die den Behörden verlockende Möglichkeiten verspricht, Lizenzkosten zu sparen. Doch diesem Nutzen stehen auch Risiken gegenüber, wie eine genauere Betrachtung der Software aus Anwendersicht ergibt.

In dem Moment, wo eine Organisation eine Software erwirbt, geht es zumindest bei herkömmlichen Verträgen genau genommen um vier Teile des Kaufgegenstands:

- die lauffähigen Programmmodule (Datenträger, Download),

- das Recht, diese benutzen zu dürfen (Lizenzerwerb),

- eine Dokumentation, in welcher der Softwareentwickler Funktionen und ihre Nutzung beschreibt, sowie

- den Anspruch, dass die Programmmodule die beschriebenen Funktionen auch tatsächlich ausführen.

Besonders der letzte Punkt ist dabei hervorzuheben: Es ist nicht das verfügbare Programm, was der Anwender braucht, sondern seine Funktionen. Sie sind der eigentliche Gegenwert zum Kaufpreis. Je komplexer allerdings das Einsatzgebiet eines Programms ist, desto schwieriger wird es, die Funktionen zu beurteilen. Hier spielt dann die Dokumentation eine entscheidende Rolle: Sie muss nämlich Funktionen und Einsatzbedingungen so deklarieren, dass eine Prüfung ihrer Eignung für den Anwender überhaupt erst möglich ist (DIN-ISO 12119).

Im behördlichen Umfeld ergibt sich durch die oft hoheitlich wahrgenommenen Aufgaben eine besonders kritische Anwendungssituation: In dem Maße, wie Verwaltungsprozesse immer mehr elektronisch und automatisiert abgewickelt werden können, ist die Behörde nicht nur für die Handlungen ihrer Ämter und Mitarbeiter, sondern auch für die Funktionen der eingesetzten Software verantwortlich. Während bei ausreichend überschaubaren Softwarefunktionen noch eine eigenständige Kontrolle durch den jeweiligen Anwender technisch machbar scheint, ist dies bei modernen und technikintensiven E-Government-Anwendungen nicht mehr gegeben.

Der Softwareentwickler muss an dieser Stelle zumindest einen Teil der Verantwortung mit übernehmen. Denn gerade bei komplexen Programmen kann nur er überschauen, welche Funktionsrisiken sein Programm birgt, und nur er kann sie wirksam verringern. Damit diese Verantwortungsübertragung funktioniert, muss sich die Behörde bei der Vertragsgestaltung im Detail mit den notwendigen Funktionen der zu beschaffenden Lösung auseinander setzen und sie einklagbar formulieren.

Distributor trifft keine Schuld

Bei derartigen Verträgen entsteht ein über das an sich funktionierende Programm hinausgehender Anspruch, der im Open-Source-Umfeld nicht umsetzbar sein dürfte: Denn selbst wenn ein Distributor Supportaufgaben übernimmt, kann er doch nicht für Programmfehler einer Entwicklergemeinschaft haftbar gemacht werden, die nicht mit ihm im Vertrag steht. Nach Paragraph 521 BGB haftet derjenige, der etwas verschenkt, nur für Fehler aus Vorsatz und bei grober Fahrlässigkeit. Im Kontext eines belastbaren Verwaltungsprozesses ist dies meist eine zu schwache Grundlage.

Zu beachten ist dabei der Unterschied zwischen Garantie und Support: Softwaresupport beinhaltet zwar auch die Behebung von Fehlern, allerdings fehlen prinzipielle Funktionsansprüche durch den Anwender. Er kann also kaum verhindern, dass sein Büro ungewollt zum verlängerten Entwicklungsplatz der eingesetzten Software wird.

Bei sicherheitstechnisch oder funktional besonders kritischen Anwendungen genügt es nicht, sich allein auf die Funktionsgarantie eines Anbieters zu verlassen, um Risiken für den Anwender zu vermeiden. Hier ist in jedem Fall eine unabhängige Begutachtung notwendig, entweder seitens des Anwenders oder eines sachverständigen Dritten. Dabei stellt sich die Frage: Können qualifizierte Prüfungen die Risiken bei der Beschaffung von freier Software mindern?

Aspekte der Qualitätssicherung

Um dies zu beantworten, muss man sich vor Augen halten, dass es bei komplexen Prüfprozessen, die auf eine korrekte Funktion der Software und Investitionssicherheit zielen, nur zum Teil um die statische Feststellung einer Produktbeschaffenheit geht. Die Prüfung ist genau genommen nur ein Teilprozess in einer Reihe von Aktivitäten zur Qualitätssicherung. Erst in der Kombination dieser Teilprozesse entsteht eine nachhaltige Softwarequalität. Es ergibt sich, dass gerade bei Prüf- und Abnahmeverfahren ein Verantwortlicher (Lieferant, Entwickler) notwendig ist, der mehrere Funktionen übernimmt. Er muss

- sicherstellen, dass das Softwareprodukt vollständig und richtig in seiner Funktionalität betrachtet wird, denn nur so kann überhaupt erst eine qualifizierte Prüfung stattfinden,

- schriftlich bestätigen, dass die dokumentierte Funktionsweise auch unter Bedingungen gewährleistet ist, die von der Prüfumgebung abweichen,

- Produkteigenschaften, die nicht per Test ermittelt werden können, belastbar bestätigen,

- gewährleisten, dass in den geprüften Funktionen auch die erst im Nachhinein erkannten Fehler behoben werden,

- sicherstellen, dass Wiederholungsprüfungen erfolgreich absolviert werden, selbst dann, wenn sich die Prüfmaßstäbe weiterentwickeln.

Es liegt auf der Hand, dass hier jemand gebraucht wird, der ein langfristiges wirtschaftliches Interesse an dem Softwareprodukt hat, der für die Funktion Verantwortung übernimmt und nicht nur für die Behebung von Fehlern. Diese Interessenlage steht mit "offener" Software im Widerspruch.

In der Praxis entsteht daraus für den Softwareanwender ein spezieller Effekt: Ihm nützt eine Adresse für die Einklagbarkeit von Funktionen nur bedingt etwas. Viel wichtiger ist für ihn die grundsätzliche Tatsache, dass den teilweise erheblichen Aufwendungen für die entwicklerseitige Qualitätssicherung ein adäquates Drohpotenzial gegenübersteht.

Bei näherer Betrachtung wird hier auch ein Problem vieler verwaltungsinterner IT-Entwicklungsprojekte deutlich: Es fehlt an einer klaren Verantwortungsabgrenzung zwischen Entwicklern und Anwendern. Diese Grenzlinie, die letztlich durch das materielle Softwareprodukt notwendig ist, wird bei internen Projekten häufig genauso aufgeweicht wie bei der Quellcode-Weiterentwicklung durch eine weltweite Anwendergemeinschaft. Damit bestehen hier prinzipiell ähnliche Probleme wie bei Open-Source-Entwicklungen.

Bei dieser Abgrenzung geht es allerdings nicht nur darum, einen Schuldigen für schlecht programmierte Software zu finden. Je fachspezifischer eine Software ist, desto mehr Verantwortung trägt auch der für ihre Spezifikation zuständige Anwender.

Was spricht also für die Open-Source-Nutzung? Ein risikobewusster Verwaltungsleiter könnte leicht zu dem Schluss kommen, dass im Interesse eines sicheren Betriebs Open-Source-Software prinzipiell zu vermeiden ist. Doch genau genommen geht es hier um eine Abwägung (siehe Kasten "Checkliste: Wo ist Open Source verantwortbar?"). Denn die Nachteile der Open-Source-Beschaffung sind auch Vorteile: Durch den Nichtkauf der Funktionsgarantie wird das Produkt Software deutlich billiger. Auch die Möglichkeit der problemloseren eigenen Weiterentwicklung der Software ist nicht zu verachten.

In der Regel sind aber der technisch-fachlichen Komplexität des Einkaufsvorgangs einer Behörde Grenzen gesetzt (Ressourcen, Knowhow etc.). Gerade für neue Einsatzbereiche weiß der Anwender oft noch gar nicht genau, welche Funktionen er benötigt. Hier ist es dann schwer, per Vertrag einen Softwareanbieter in die Pflicht zu nehmen.

Fazit: Open-Source-Software darf nicht zum Sparpaket der Verwaltung auf Kosten der Sicherheit und Zuverlässigkeit von Verwaltungsprozessen werden! Allerdings kann sie eine sinnvolle Alternative sein, die in bestimmten Anwendungsfeldern kein unvertretbar hohes Risiko darstellt. (ue)

*Dr. Uwe Schwochert ist Leiter der Prüfstelle für Fachprogramme in der öffentlichen Verwaltung bei der TÜV Informationstechnik GmbH in Dresden (u.schwochert@tuvit.de).

Checkliste: Wo ist Open Source verantwortbar?

Im Entscheidungsprozess, ob ein Open-Source-Produkt beschafft werden kann beziehungsweise in die engere Wahl genommen wird, sollten sich die Verantwortlichen folgende Fragen beantworten.

1. Einsatzgebiet der Software

- Wie rechtsverbindlich und außenwirksam sind die Verwaltungsprozesse, die durch die Software automatisiert umgesetzt werden?

- Wie hoch ist das mit dem Softwareeinsatz verbundene Sicherheitsrisiko?

- Was droht der Anwenderorganisation beim Ausfall der Software im schlimmsten Fall?

- Wie komplex und dynamisch ist die technische Einsatzumgebung (Schnittstellen, Technologien etc.)?

- Wie komplex und dynamisch sind die rechtlichen Grundlagen (Gesetze und Regelungen) des Anwendungsumfelds?

2. Beschaffenheit des Softwareprodukts

- Wie komplex ist die Funktion, die die Software ausführt (Spezifikation)?

- Wie komplex sind Architektur und Modulstruktur der Lösung?

- Wie komplex ist die Bedienoberfläche?

- Wie hoch ist die Wartungsanfälligkeit des Produkts?

3. Kompetenz der Programmanwender

- Hat der Anwender Einblick und Verständnis für die im Programm intern ablaufenden Vorgänge und Strukturen?

- Ist der Anwender in der Lage, konsistente Änderungen am Code der eingesetzten Software vorzunehmen beziehungsweise nachzuvollziehen?

- Sind die technischen Voraussetzungen für Programmanpassungen gegeben?

Sofern wenigstens in einem dieser drei Bereiche ausreichend gute Bedingungen vorliegen, kann über einen verantwortbaren Einsatz von Open-Source-Software nachgedacht werden. Es sollte also wenigstens ein hinreichend unverbindliches Einsatzgebiet oder eine hinreichend überschaubare Funktionalität oder hinreichend kompetente Anwender geben.

Links

www.c-lab.de

www.ifross.de

Abb.1: Was man mit Software kauft

Besonders die Funktionen eines Programms bilden den Gegenwert zum Kaufpreis. Quelle: Schwochert

Abb.2: Drei Problembereiche

Um den Einsatz von Open-Source-Software rechtfertigen zu können, sollte wenigstens eines der drei genannten Kriterien unproblematisch sein. Quelle: Schwochert