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ürmerForschungsstelle Digitale NachhaltigkeitInstitut für WirtschaftsinformatikUniversität Bern

Matthias Stürmer, Forschungsstelle Digitale Nachhaltigkeit


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

http://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 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



5

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

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

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 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



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



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/

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

http://www.openhub.net/



14

Agenda




15

BBL MerkblattSoftware-Ausschreibungen

Software-Ausschreibungen: Sicherstellung eines breiten Wettbewerbs

Quelle: https://www.beschaffung.admin.ch/bpl/de/home/beschaffung/merkblaetter.html

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?

http://www.qlack.com/fuse



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

http://www.ossdirectory.com/

https://www.openhub.net/



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

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 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/

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/

http://www.digitale-nachhaltigkeit.ch/2013/04/oss-rahmenvertraege/



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

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 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



30

Einzelne Features erweitern auf www.bountysource.com



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



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

http://www.osb-alliance.de/working-groups/wg-office-interoperability



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

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

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

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

https://government.github.com/

Lessons Learnt bei der Beschaffung von Open Source Software

Technology

Transcript of Lessons Learnt bei der Beschaffung von Open Source Software