Lessons Learnt bei der Beschaffung von Open Source Software

Fachsession 2:
Abhängigkeiten von IT-Herstellern reduzieren
Lessons Learnt bei der Beschaffung von
Open Source Software
15. August 2017, IT-Beschaffungskonferenz 2017
Dr. Matthias Stürmer
Forschungsstelle Digitale Nachhaltigkeit
Institut für Wirtschaftsinformatik
Universität Bern

Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
2
Matthias Stürmer
> Seit 2013 Leiter der Forschungsstelle Digitale Nachhaltigkeit und Dozentur
am Institut für Wirtschaftsinformatik der Universität Bern
> 2010 bis 2013 bei EY (Ernst & Young) als Manager mit Beratung zu Open
Source Software, Open Data und Social Media
> 2009 bis 2010 Business Development und Projektleiter beim Liip AG
> 2006 bis 2009 Assistent an der ETH Zürich am Lehrstuhl für Strategisches
Management und Innovation doktoriert über Zusammenarbeit zwischen
Open Source Communities und Technologie-Unternehmen
> 2000 bis 2005 Studium Betriebswirtschaft und Informatik an
Universität Bern, Lizentiatsarbeit zu Open Source Community Building
> Geschäftsleiter Parlamentarischen Gruppe Digitale Nachhaltigkeit
> Präsident tcbe.ch – ICT Cluster Bern, Switzerland
> Vorstandsmitglied CH Open
> Mitgründer und Vorstandsmitglied Verein Opendata.ch
> Stadtrat von Bern (EVP)
Dr. Matthias Stürmer
Dozentur und
Leiter Forschungsstelle
Digitale Nachhaltigkeit
Universität Bern
Institut für Wirtschaftsinformatik
Engehaldenstrasse 8
CH-3012 Bern
Telefon: +41 31 631 38 09
Mobile: +41 76 368 81 65
Tel: +41 31 631 38 79 (Sekretariat)
Twitter: @maemst
matthias.stuermer@iwi.unibe.ch
www.digitale-nachhaltigkeit.unibe.ch

3
Forschungsstelle Digitale Nachhaltigkeit
Angesiedelt am Institut für Wirtschafsinformatik seit 2014,
Team von 14 Mitarbeitenden
Forschung, Lehre und Beratung zu
> Open Source Software: Community Governance, Business
Models, Maturitätsmodelle etc.
> Open Data: Open Data Apps, interaktive Visualisierungen etc.
> Linked Data: LINDAS Use Cases, Geoportal Bund etc.
> Open Government: Transparenz und Partizipation, Impact
Models, Participatory Apps, FixMyStreet.org etc.
> ICT-Beschaffungen: Agile Software-Entwicklung,
Requirements Engineering, Herstellerabhängigkeiten,
freihändige Vergaben, WTO-Regeln etc.
> Digitale Nachhaltigkeit: Theorie, Voraussetzungen,
Anwendungsbeispiele etc.

4
Agenda
1. Abhängigkeit von Herstellern proprietärer Software
2. SIK Checkliste «Beschaffung von Open Source»
3. BBL-Merkblatt «Software-Ausschreibungen»
4. Beschaffung von OSS mittels geeigneten EKs und ZKs
5. Beschaffung von OSS mittels Rahmenverträgen
6. Gemeinsame Weiterentwicklung von OSS

5
http://www.tagesspiegel.de/weltspiegel/it-in-der-oeffentlichen-verwaltung-europas-fatale-abhaengigkeit-von-microsoft/19628246.html

6
Quelle: Handelszeitung, 13. April 2017

7
https://www.tagesanzeiger.ch/schweiz/standard/freihaendige-itgrossauftraege-des-bundes-sorgen-fuer-unmut/story/29200791

8
Software- vs. Anbieter-Abhängigkeit
Behörde ist abhängig von der Software (Software Lock-In):
1. Technische Abhängigkeiten: Schnittstellen, Datenformate etc.
2. Organisatorische Abhängigkeiten: Gewohnheiten der
Mitarbeitenden, Prozesse angepasst auf Software
3. Produktestandard-Abhängigkeit: andere Instanz gibt vor, welches
Produkt eingesetzt werden muss
Behörde ist abhängig vom Anbieter (Vendor Lock-In):
1. Rechtliche Abhängigkeiten: Urheberrecht, Verträge,
Lizenzbedingungen
2. Psychologische Abhängigkeiten: Marken-Produkte,
Bekanntheitsgrad, Verbreitung
3. Knowhow-Abhängigkeiten: Mitarbeiter des Anbieters wissen wie
was zusammenhängt

9
Weniger Anbieter-Abhängigkeiten mit
Open Source Software
Behörde
Open Source
Software
Anbieter
Anbieter
Anbieter
Wechsel möglich
abhängig
Behörde
Proprietäre
Software
Anbieter
abhängig
abhängig
Eigentum

10
Agenda

11
SIK Checkliste
«Beschaffung von Open Source»
> Ziel ist die bessere Berücksichtigung
von Open Source Software bei der
Beschaffung von IT
> Erarbeitet durch die Arbeitsgruppe
Open Source Software der
Schweizerischen
Informatikkonferenz (SIK)
> Aktuelle Version:
18. August 2015, Version 1.0
> Mit Rückmeldungen von
Behördenstellen, Beschaffungsjuristen
und Open Source Experten
Quelle: http://www.ossdirectory.com/oss-knowhow/details/kbarticle/sik-checkliste-fuer-beschaffung-von-open-source-software/

12
Wichtige Fragen in der Checkliste
> Sind die Beschaffungsunterlagen funktional verfasst ohne Vorgabe
von proprietären Produkten?
— Vorgaben von proprietären Produkten (Microsoft Sharepoint, SAP etc.)
schliessen OSS Anbieter aus
— Folge davon sind verstärkte Abhängigkeiten, Förderung von Monopolstellungen,
Einschränkung von Wettbewerb und Innovation, langfristige Zunahme der
Informatikkosten
> Wird die Lieferung der Software unter einer Open Source Lizenz in der
technischen Spezifikation (TS) vorgegeben bzw. wird Open Source als
Zuschlagskriterium (ZK) bemessen?
— OSS erlaubt vollständigen Zugang zum Quellcode und das Recht diesen zu
verändern  Möglichkeit selber oder im Auftrag an Dritte Software zu
auditieren, korrigieren, anzupassen und weiterzuentwickeln
— Vorgabe als TS oder Bewertung als ZK ist sinnvoll und beschaffungsrechtlich
erlaubt

13
Wichtige Fragen in der Checkliste
> Werden auch Referenzinstallationen von Open Source Lösungen
berücksichtigt, die nicht vom Anbieter selber realisiert wurden?
— Verbreitungsgrad einer OSS Lösung an allen produktiv laufenden Installationen
bemessen macht Sinn (auch Behörden-interne Realisierung möglich)
> Wird Aktivität einer Open Source Community berücksichtigt?
— Möglichst aktive und heterogene Community wichtig für Nachhaltigkeit
— Aktivität von OSS Projekten auf Open HUB www.openhub.net gezeigt
> Wird Verfügbarkeit von Dienstleistern einer OSS Lösung geprüft?
— Für langfristige Weiterentwicklung und möglichen Anbieterwechsel ist breite
Dienstleister-Community wichtig
— Bspw. als ZK Anzahl kommerzielle Anbieter für OSS Lösung berücksichtigen

14
Agenda

15
BBL Merkblatt
Software-Ausschreibungen
Software-Ausschreibungen: Sicherstellung eines breiten Wettbewerbs
Quelle: https://www.beschaffung.admin.ch/bpl/de/home/beschaffung/merkblaetter.html

16
Wichtige Aussagen
Grundsätzliche Vorgaben gemäss BBL Merkblatt:
1. Anbieter von Open-Source und Closed-Source bzw.
proprietärer Software sowie von Mischformen sollen
gleiche Chancen haben, einen öffentlichen Auftrag
zu erhalten
2. Vergabestelle darf Technologien, Produkte und
Hersteller nur dann vorgeben bzw. ausschliessen,
wenn zwingende sachliche Gründe vorliegen und
schriftlich festgehalten sind
3. Vorgegebene Schnittstellen und Dateiformate
basieren soweit möglich sowie technisch und
wirtschaftlich sinnvoll auf offenen, frei
zugänglichen Spezifikationen und Standards

17
Wichtige Aussagen
Open Source Software ist per se nicht Beschaffungs-relevant:
> «Die OSS-Lizenz allein kostet die beschaffende Stelle in der Regel
nichts und ist für sich allein daher auch nicht
beschaffungsrelevant.»
> «Kosten und damit Beschaffungsrelevanz entstehen erst, wenn bei
einem Anbieter Dienstleistungen (bspw. Beratung, Integration,
Anpassungen, Schulungen, Weiterentwicklung, Betrieb, Wartung
etc.) für bestimmte OSS eingekauft werden oder OSS zusammen
mit andern, kostenpflichtigen Software-Komponenten und/oder
Dienstleistungen eingekauft wird.»

18
Agenda

20
Open Source Software als ZK:
Schulverwaltungslösung Kt. Bern
Investitionsschutz: Unabhängigkeit vom Entwickler (Gewichtung: 2%)
Die Maximalpunktzahl erhält, wer aufzeigt, dass der Kunde auch bei einem Konkurs des
Lieferanten, einer Einstellung des Produkts und in ähnlichen Situationen das Produkt
weiter warten und einsetzen kann, insbesondere infolge einem oder mehrerer der
folgenden Faktoren:
> das Produkt ist ganz oder teilweise Open Source Software (OSS),
> der Kunde erhält den aktuellen Source Code und ein Nutzungs- und
Veränderungsrecht an der Software im Umfang einer OSS-Lizenz,
> am Markt gibt es auch ausserhalb des Lieferanten Entwickler mit guten Kenntnissen
des Produktes.
Quelle: Ausschreibung «IT@KOS Beschaffung Schulverwaltungs-Lösung», 24.01.2017

21
Open Source Software als EK:
Submiss-Beschaffung der Stadt Bern
Analyse der Kriterien (B6_Kriterienkatalog)
> Auszug aus der Ausschreibung:
Eignungskriterium 3  Der Anbieter erklärt sich bereit, dass
der Source Code unter einer OS-Lizenz veröffentlicht wird.
Nachweis: Deklaration der Einwilligung, den Source Code unter
einer Open Source Lizenz zu entwickeln oder bereitzustellen.
> Problem: European Dynamics wird das unbekannte und von
keinem anderen Anbieter unterstützte Open Source Framework
"Qlack Fuse" verwenden.
> Wie könnten «Fake» Open Source Lösungen künftig verhindert
werden?

22
ZKs für fundierte Bewertung von
OSS-Beschaffungen
1. Werden bestehende Open Source Komponenten verwendet?  Nachweis: Etabliertes Open
Source Framework wird verwendet (versus eigenes Framework entwickeln)
2. Hat der Anbieter bereits Software-Projekte basierend auf diesem Open Source Framework
realisiert? Nachweis: eigene Projekt-Referenzen mit dem Open Source Framework
3. Wird das Open Source Framework auch von anderen Firmen verwendet? [relevant für
Reduktion der Anbieterabhängigkeit]  Nachweis: Anzahl Firmen, die das Open Source
Framework mit Wartung und Support unterstützen (siehe bspw. OSS Directory)
4. Wie aktiv wird das Open Source Framework weiterentwickelt?  Nachweis: OpenHub
Statistiken der Entwicklungs-Aktivität («12 Month Statistics»: «Contributors» & «Commits»)
5. Wird das Open Source Framework von unterschiedlichen Firmen weiterentwickelt? [Ziel ist
eine möglichst heterogene Open Source Community]  Nachweis: Entwickler («Contributors»)
arbeiten bei verschiedenen Firmen
6. Werden standardisierte Schnittstellen und offene Dateiformate verwendet?  Nachweis:
Spezifikationen von allen Schnittstellen sind öffentlich zugänglich
7. Ist das Framework gut dokumentiert?  Nachweis: Umfang und Qualität der Dokumentation
wird bewertet (API-Dokumentation, Tutorials, Handbuch, veröffentlichte Bücher etc.)
8. Ist die Open Source Lösung auch auf Linux lauffähig? [versus Microsoft Windows Server]
 Nachweis: Angabe ob Software auch auf Linux-Servern betrieben werden kann

23
Vergleich der Entwicklungs-Aktivität von
verschiedenen Open Source Framworks
Link: https://www.openhub.net/p/_compare?project_0=Qlack2-Fuse&project_1=Symfony&project_2=Ruby+on+Rails

24
Agenda

25
Rahmenverträge mit
Open Source Anbietern in Schweden
Nutzen der Rahmenverträge:
> Verwaltung erhält Support und Wartung von
mehreren kompetenten Ansprechspartnern
für Vielzahl von Open Source Produkten
> Verwaltung erhält Beschaffungssicherheit
und Anleitung für Vorgehen bei Beschaffung
von Open Source Support
> Rahmenvertrag deckt Urheberrecht, Haftung,
Gewährleistung etc. ab
> Beschaffungen von Open Source durch
Mini-Tenders werden für die Verwaltung
vereinfacht
Quelle: http://www.digitale-nachhaltigkeit.ch/2013/04/oss-rahmenvertraege/

26
Rahmenverträge mit
Open Source Anbietern in Schweden
Schwedische Verwaltung
OSS GU OSS GU OSS GU OSS GU OSS GU
OSS Rahmenvertrag
Subunternehmer-Verträge
72 OSS-Dienstleister
Quelle: http://www.digitale-nachhaltigkeit.ch/2013/04/oss-rahmenvertraege/

27
Open Source «Generalunternehmen»
Rahmenverträge mit OSS GU in
den Software-Bereichen:
1. Anwender-Software
2. Geschäftsverwaltung
3. Betriebssystem
4. Security
5. IT-Operations
6. Asset Management
7. Middleware
8. Entwicklungs-Tools
9. Datenbanken
10. Datenanalyse-Software
OSS GU muss folgende
Dienstleistungen erbringen:
1. Fehlerbehebung
2. Integration und Testing
3. Installation
4. Migration
5. Support
6. Wartung
7. Ausbildung
Quelle: https://www.digitale-nachhaltigkeit.ch/wp-content/uploads/2013/04/anbudsinbjudan-ppna-programvaror-2010-
ausschreibung-open-source-software-2010.pdf

28
Agenda

29
Gemeinsame Weiterentwicklung von
E-Government Anwendungen
Varianten:
a) Erweiterung einer bestehenden Open Source Lösung
b) Gemeinsame Entwicklung einer neuen Open Source Lösung
Vorteile:
> Kosten der Weiterentwicklung können aufgeteilt werden
> Alle haben uneingeschränktes Nutzungsrecht der Software
> Weiterentwicklung auf verschiedene Anbieter verteilt
> Wesentlich kleinere Abhängigkeiten von Anbietern
Nachteil:
> Höherer Koordinationsaufwand als beim Einkauf von Lizenzen

30
Einzelne Features erweitern auf
www.bountysource.com

31
Institutionalisiertes Crowdfunding
Phase 1: Initialisierung
a) Interesse und Wille von professionellen Open Source Nutzern wecken
b) Anforderungen zusammentragen und mit Entwicklern diskutieren
c) Resultat: Spezifikation zur gemeinsamen Weiterentwicklung verfassen
Phase 2: Finanzierung
a) Spezifikation publizieren als RfP, Firmen für Offerten einladen
b) Evaluieren der Angebote und Auswahl treffen
c) Resultat: Finanzierung des notwendigen Betrags gemeinsam aufteilen
Phase 3: Umsetzung
a) Projektmanagement festlegen, Verträge unterzeichnen, loslegen
b) Tests bei den Nutzern durchführen, Entwicklung abschliessen
c) Resultat: Neuen Source Code publizieren, in OSS Projekt integrieren

32
Beispiel Weiterentwicklung LibreOffice
> Ziel war bessere Interoperabilität von
LibreOffice mit Microsoft Word
> Städte München, Freiburg i.B., Leipzig,
Jena, Bundesgericht, ISB und Kt. Waadt
finanzierten total EUR 160’000
> Dazu 5 Use Cases ausgewählt und
Spezifikation verfasst, publiziert auf
Website und in entsprechenden News-
Kanälen
> 2 Angebote eingegangen (Lanedo und
SUSE), Use Cases auf beide Firmen
verteilt, im Sommer 2013 abgeschlossen
Quelle: Open Source Business Alliance Working Group Office Interoperability
http://www.osb-alliance.de/working-groups/wg-office-interoperability

33
Beispiel OpenLayers 3
Co-Finanzierung durch swisstopo
Quelle: http://www.digitale-nachhaltigkeit.unibe.ch/unibe/portal/fak_wiso/a_bwl/inst_wi/abt_digital/content/e90971/e562996/
e591574/e591600/files591612/12_CedricMoullet_CrowdfundingWeiterentwicklungGeoportal_ger.pdf

34
Beispiel CAMAC für
Baugesuchsverwaltung
Quelle: http://camac.ch/de

35
Open Source Freigaben durch Kt. Bern
Quelle: https://www.fin.be.ch/fin/de/index/direktion/ueber-die-direktion/aktuell.meldungNeu.onemeldungonly.
portalnavrrcsubeleme.html/portal/de/meldungen/mm/2016/08/20160826_1438_nachrichten_aus_derverwaltung

36
GitHub and Government
Link: https://government.github.com

Lessons Learnt bei der Beschaffung von Open Source Software

Weitere ähnliche Inhalte

Was ist angesagt?

Ähnlich wie Lessons Learnt bei der Beschaffung von Open Source Software

Mehr von Matthias Stürmer

Lessons Learnt bei der Beschaffung von Open Source Software