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ürmerForschungsstelle Digitale NachhaltigkeitInstitut für WirtschaftsinformatikUniversitä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 anUniversitä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ürmerDozentur undLeiter ForschungsstelleDigitale Nachhaltigkeit
Universität BernInstitut für WirtschaftsinformatikEngehaldenstrasse 8CH-3012 Bern
Telefon: +41 31 631 38 09Mobile: +41 76 368 81 65Tel: +41 31 631 38 79 (Sekretariat)
Twitter: @maemstmatthias.stuermer@iwi.unibe.chwww.digitale-nachhaltigkeit.unibe.ch
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
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.
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
4
Agenda
1. Abhängigkeit von Herstellern proprietärer Software2. SIK Checkliste «Beschaffung von Open Source»3. BBL-Merkblatt «Software-Ausschreibungen»4. Beschaffung von OSS mittels geeigneten EKs und ZKs5. Beschaffung von OSS mittels Rahmenverträgen6. Gemeinsame Weiterentwicklung von OSS
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
5
http://www.tagesspiegel.de/weltspiegel/it-in-der-oeffentlichen-verwaltung-europas-fatale-abhaengigkeit-von-microsoft/19628246.html
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
6
Quelle: Handelszeitung, 13. April 2017
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
7
https://www.tagesanzeiger.ch/schweiz/standard/freihaendige-itgrossauftraege-des-bundes-sorgen-fuer-unmut/story/29200791
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
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 Software3. 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,
Lizenzbedingungen2. Psychologische Abhängigkeiten: Marken-Produkte,
Bekanntheitsgrad, Verbreitung3. Knowhow-Abhängigkeiten: Mitarbeiter des Anbieters wissen wie
was zusammenhängt
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
9
Weniger Anbieter-Abhängigkeiten mit Open Source Software
Behörde
Open Source Software
AnbieterAnbieter
Anbieter
Wechsel möglich
abhängigBehörde
Proprietäre Software
Anbieter
abhängig
abhängigEigentum
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
10
Agenda
1. Abhängigkeit von Herstellern proprietärer Software2. SIK Checkliste «Beschaffung von Open Source»3. BBL-Merkblatt «Software-Ausschreibungen»4. Beschaffung von OSS mittels geeigneten EKs und ZKs5. Beschaffung von OSS mittels Rahmenverträgen6. Gemeinsame Weiterentwicklung von OSS
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
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/
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der 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
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
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
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
14
Agenda
1. Abhängigkeit von Herstellern proprietärer Software2. SIK Checkliste «Beschaffung von Open Source»3. BBL-Merkblatt «Software-Ausschreibungen»4. Beschaffung von OSS mittels geeigneten EKs und ZKs5. Beschaffung von OSS mittels Rahmenverträgen6. Gemeinsame Weiterentwicklung von OSS
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
15
BBL MerkblattSoftware-Ausschreibungen
Software-Ausschreibungen: Sicherstellung eines breiten Wettbewerbs
Quelle: https://www.beschaffung.admin.ch/bpl/de/home/beschaffung/merkblaetter.html
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
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
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
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.»
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
18
Agenda
1. Abhängigkeit von Herstellern proprietärer Software2. SIK Checkliste «Beschaffung von Open Source»3. BBL-Merkblatt «Software-Ausschreibungen»4. Beschaffung von OSS mittels geeigneten EKs und ZKs5. Beschaffung von OSS mittels Rahmenverträgen6. Gemeinsame Weiterentwicklung von OSS
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
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
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
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?
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
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: OpenHubStatistiken 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
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
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
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
24
Agenda
1. Abhängigkeit von Herstellern proprietärer Software2. SIK Checkliste «Beschaffung von Open Source»3. BBL-Merkblatt «Software-Ausschreibungen»4. Beschaffung von OSS mittels geeigneten EKs und ZKs5. Beschaffung von OSS mittels Rahmenverträgen6. Gemeinsame Weiterentwicklung von OSS
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
25
Rahmenverträge mit Open Source Anbietern in Schweden
Nutzen der Rahmenverträge: > Verwaltung erhält Support und Wartung von
mehreren kompetenten Ansprechspartnernfür Vielzahl von Open Source Produkten
> Verwaltung erhält Beschaffungssicherheitund Anleitung für Vorgehen bei Beschaffung von Open Source Support
> Rahmenvertrag deckt Urheberrecht, Haftung, Gewährleistung etc. ab
> Beschaffungen von Open Source durchMini-Tenders werden für die Verwaltung vereinfacht
Quelle: http://www.digitale-nachhaltigkeit.ch/2013/04/oss-rahmenvertraege/
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
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/
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
27
Open Source «Generalunternehmen»
Rahmenverträge mit OSS GU in den Software-Bereichen:1. Anwender-Software2. Geschäftsverwaltung3. Betriebssystem4. Security5. IT-Operations6. Asset Management7. Middleware8. Entwicklungs-Tools9. Datenbanken10. Datenanalyse-Software
OSS GU muss folgende Dienstleistungen erbringen:1. Fehlerbehebung2. Integration und Testing3. Installation4. Migration5. Support6. Wartung7. Ausbildung
Quelle: https://www.digitale-nachhaltigkeit.ch/wp-content/uploads/2013/04/anbudsinbjudan-ppna-programvaror-2010-ausschreibung-open-source-software-2010.pdf
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
28
Agenda
1. Abhängigkeit von Herstellern proprietärer Software2. SIK Checkliste «Beschaffung von Open Source»3. BBL-Merkblatt «Software-Ausschreibungen»4. Beschaffung von OSS mittels geeigneten EKs und ZKs5. Beschaffung von OSS mittels Rahmenverträgen6. Gemeinsame Weiterentwicklung von OSS
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
29
Gemeinsame Weiterentwicklung vonE-Government Anwendungen
Varianten:a) Erweiterung einer bestehenden Open Source Lösungb) 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
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
30
Einzelne Features erweitern auf www.bountysource.com
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
31
Institutionalisiertes Crowdfunding
Phase 1: Initialisierunga) Interesse und Wille von professionellen Open Source Nutzern weckenb) Anforderungen zusammentragen und mit Entwicklern diskutierenc) Resultat: Spezifikation zur gemeinsamen Weiterentwicklung verfassen
Phase 2: Finanzierunga) Spezifikation publizieren als RfP, Firmen für Offerten einladenb) Evaluieren der Angebote und Auswahl treffenc) Resultat: Finanzierung des notwendigen Betrags gemeinsam aufteilen
Phase 3: Umsetzunga) Projektmanagement festlegen, Verträge unterzeichnen, loslegenb) Tests bei den Nutzern durchführen, Entwicklung abschliessenc) Resultat: Neuen Source Code publizieren, in OSS Projekt integrieren
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
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 Interoperabilityhttp://www.osb-alliance.de/working-groups/wg-office-interoperability
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
33
Beispiel OpenLayers 3Co-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
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
34
Beispiel CAMAC für Baugesuchsverwaltung
Quelle: http://camac.ch/de
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
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
Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit
Lessons Learnt bei der Beschaffung von Open Source Software
36
GitHub and Government
Link: https://government.github.com