Was bedeuten Open Source-Vorgaben für die Software-Beschaffung?

Mit dem Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG) wird die öffentliche IT in der Schweiz weiter «open». Artikel 9 und 10 machen Open Source Software (OSS) und Open Data bei den Schweizer Bundesbehörden zur Norm. Die freie Nutzung, Änderung und Weitergabe durch alle und für jeden Zweck ist also gestattet. Doch was bedeutet das für die Beschaffung von Software? Und wie müssen Sie dabei in Zukunft vorgehen?

Wir haben einige Herausforderungen und Lösungsansätze reflektiert:

1. Zu lösendes Problem beschreiben

Herausforderung

Die gesuchte Software-Lösung so zu beschreiben, dass verschiedene Angebote und Lizenzmodelle vergleichbar sind, ist eine Herausforderung. Denn schliesslich muss jeder Zuschlagsentscheid gut begründet sein.

Lösungsansatz

Eine Software-Ausschreibung verlangt viel Vorarbeit: Die erforderlichen Datenflüsse müssen fachlich beschrieben sein, wenn möglich unter Berücksichtigung von Standards wie jenen von eCH. Das erfordert professionelles Know-how in Prozessmodellierung und -optimierung, Business Analyse und Software-Architektur. Der fachliche Bedarf sollte bei Ausschreibungen im Vordergrund stehen, um Innovationen technologieoffen zu ermöglichen.

Herausforderung

Der Zweckartikel im EMBAG betont die Zusammenarbeit unter Behörden verschiedener Gemeinwesen. Die Integration von OSS-Lösungen in bestehende Architekturen ist vor allem bei Beschaffungsgemeinschaften und Produktmanagement im Verbund eine Herausforderung.

Lösungsansatz

Daher braucht es auch Transformationsbegleitung mit der Moderation von Ziel- und Strategiedebatten sowie der Unternehmensarchitekturgestaltung. Hier ist eine fach- und organisationsübergreifende Betrachtung gefragt.

2. Lieferketten kennen

Herausforderung

Die allgemein hohe Modularität von OSS hat Herausforderungen beim Lizenzmanagement zur Folge.

Lösungsansatz

Um diese Komplexität zu beherrschen, bedarf es Praktiken wie Software Composition Analysis (SCA), also die Analyse der Zusammensetzung der Software und Code Licence Reviews, in denen die einzelnen Lizenzbedingungen geprüft werden. Die Herstellung von Transparenz über verwendete Software ist weitgehend automatisierbar mit Software Bills of Materials (SBOM), sozusagen maschinellen Inventarlisten der Software-Bestandteile.

SBOMs machen die Software-Lieferkette nachvollziehbarer, was übrigens auch von Vorteil für die IT-Sicherheit ist. Es braucht also umfassende Untersuchungen der Software, Code Reviews. Neben dem Code selbst sollte auch sein Umfeld in den Fokus öffentlicher Auftraggeber rücken: Praktiken des Lieferantenmanagements wie Lieferanten-Audits und das systematisch erfasste Wissen über Lieferanten (Supplier Intelligence) sind Voraussetzungen für den Aufbau einer Warengruppenstrategie im IT-Bereich. Mit einer Warengruppenstrategie kann der Einkauf viel dynamischer auf Marktänderungen reagieren.

Die Qualität von Software und ihren Lieferketten wird bei Open Source oft unter dem Begriff der Community Health betrachtet. Die «Community» umfasst die Marktakteure rund um ein Software-Projekt. Das CHAOSS-Projekt («Community» Health Analytics in Open Source Software) der Linux Foundation hat umfassende Metriken zusammengetragen, um die Community Health verschiedener Projekte vergleichbar zu machen. Der Überblick dieser Metriken kann als Inspirationsquelle für Zuschlagskriterien bei Ausschreibungen von OSS dienen. Relevante, bedarfsgerechte Metriken und die nötige Analysetiefe in der Software-Lieferkette zu identifizieren und helfen, zugehörige Daten transparent zu machen, gehört zu einer gut durchdachten Software-Ausschreibung.

3. Markt mitgestalten

Herausforderung

Schon wegen der gesamtwirtschaftlichen Bedeutung öffentlicher Beschaffungen besteht immer auch eine Mitgestaltung des Marktes durch öffentliche Stellen. Gerade im Bereich der Softwareentwicklung ist die Trennung von produzierender und konsumierender Seite oft unscharf, da Rückschlüsse aus bewusstem und unbewusstem User-Feedback idealerweise kontinuierlich in die Lösung zurückfliessen.

Diese Unschärfe besteht verstärkt bei Software, die einer Copyleft-Lizenz unterliegt, wo die Weitergabe der Software (mit oder ohne Änderung) einhergeht mit der Weitergabe der Freiheit zur Nutzung, Änderung und Weitergabe, sich die Freiheit bzw. Pflicht somit perpetuiert. Auftraggeber, die einer gesetzlichen Open Source-Pflicht unterliegen, werden zwangsläufig selbst zu Produzenten auf einem offenen Markt.

Lösungsansatz

Diese mitgestaltende Rolle sollten Auftraggebende bewusst wahrnehmen. Zu Governance-Fragen gehören:

• die Wahl der geeigneten Open Source-Lizenz (eine kategorisierte Liste hat die Open Source Initiative zusammengestellt),
• finanzielle Beteiligungen (oder das Verlangen von Nachweisen über finanzielle Beteiligungen durch Bieter als Zuschlagskriterium bei Ausschreibungen),
• Mitwirkung in Projekten durch öffentliche Aufträge und In-House-Entwicklung (dies ist vor allem bei Komponenten wichtig, die viel genutzt werden, aber wenig Sichtbarkeit haben),
• methodische Mitgestaltung (zum Beispiel durch eine Code Stewardship-Rolle oder ein Open Source Program Office OSPO) und
• Community-Pflege (zum Beispiel durch Unterstützung mit der bei Behörden verfügbaren Infrastruktur).
   

Zum Modus der Beteiligung und Governance sollten Auftraggebende sich nicht erst anlässlich konkreter Ausschreibungen Gedanken machen, wenn in der Regel Zeitdruck besteht. Um gut vorbereitet zu sein, sollten auftraggebende Stellen eine projektübergreifende Open Source-Strategie haben.

Fazit

Open Source-Beschaffung ist hochgradig interdisziplinär und verlangt offenen Diskurs sowie kontinuierliche Weiterbildung. Es handelt sich um Daueraufgaben, die feste Verankerung in behördliche Strukturen erfordern. OSS ist eine Chance zum Ausbau strategischer Beschaffung von Software und zur Professionalisierung öffentlicher IT insgesamt. In Anbetracht der zunehmenden Digitalisierung ist der gesamtgesellschaftliche Nutzen enorm.