Standardisierung, Herstellerabhängigkeiten und Open Source Software

CAS ICT-Beschaffungen 2017 Block 2.1: Von der ICT-Strategie zum ICT-Projekt Standardisierung, Herstellerabhängigkeiten und Open Source Software

13. Mai 2017

Dr. Matthias Stürmer

Forschungsstelle Digitale Nachhaltigkeit Institut für Wirtschaftsinformatik Universität Bern

CAS ICT-Beschaffungen 2017

Block 2.1: Von der ICT-Strategie zum ICT-Projekt

2

Matthias Stürmer

> Seit 2013 Leiter der Forschungsstelle Digitale Nachhaltigkeit an der Universität Bern, Dozentur für Digitale Nachhaltigkeit

> 2010 bis 2013 bei EY (Ernst & Young) als Senior Consultant/Managermit 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, Lizenziatsarbeit 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 [email protected] www.digitale-nachhaltigkeit.unibe.ch

http://www.digitale-nachhaltigkeit.unibe.ch/





3

Forschungsstelle Digitale Nachhaltigkeit

Angesiedelt am Institut für Wirtschafsinformatik seit 2014, Team von 12 Mitarbeitenden

Forschung, Lehre und Beratung zu

> Open Source Software: Community Governance, Business Models, Maturitätsmodelle etc.

> Open Data: Open Data Apps, interaktive Visualisierungen, Open Aid, Linked Open Data etc.

> Open Government: Transparenz und Partizipation, Impact Models, Participatory Apps etc.

> ICT-Beschaffungen: Agile Software-Entwicklung, Requirements Engineering, Herstellerabhängigkeiten, freihändige Vergaben, WTO-Regeln etc.

> Digitale Nachhaltigkeit: Theorie, Kriterien etc.



4

Agenda

Standardisierung, Herstellerabhängigkeiten und Open Source Software

1. Standardsoftware vs. Individualentwicklungen

2. Freihändige Vergaben und Herstellerabhängigkeiten

3. Konzept der digitalen Nachhaltigkeit

4. Einführung Open Source Software

5. Total Cost of Ownership (TCO) und Open Source

6. BBL-Merkblatt «Software-Ausschreibungen»

7. SIK Checkliste «Beschaffung von Open Source»

8. Lessons Learnt bei Open Source Beschaffungen



5

Individual-Software

Individual-Software wird spezifisch für einen bestimmten Anwender und seine Bedürfnisse entwickelt.

> Vor- und Nachteile — Vorteil: Entspricht genau den Anforderungen der Anwender. — Nachteil: Entwicklungsaufwand wegen „Massarbeit“ relativ hoch.

> Warum Individual-Software? — Keine passende Standard-Software vorhanden — Anpassung der Standard-Software käme teurer als Neuentwicklung

von Individual-Software — Prozesse und Strukturen müssen nicht verändert werden — Wettbewerbsvorteil durch individuelle Entwicklung — Abhängigkeit reduzieren (wenn im Besitz vom Urheberrecht)



6

Standard-Software

Standard-Software wird zur Erfüllung funktionaler Anforderungen für einen breiten Kreis von Anwendern entwickelt.

> Vor- und Nachteile — Vorteil: Kosten für Erst-Entwicklung und Weiterentwicklung werden auf

mehrere Anwender verteilt. — Nachteil: Anforderungen der einzelnen Nutzer werden nicht genau

abgedeckt.

> Warum Standard-Software? — Ist günstiger falls Anforderungen ausreichend abgedeckt werden — Profitieren von Weiterentwicklungen für andere Anwender — Kann rascher eingeführt werden weil Software bereits besteht — Weniger Risiko und Fehler da bestehende Software getestet werden kann — Möglicherweise mehr Dokumentation und Schulungsunterlagen



7

Kontinuum von Standard-Software bis Individual-Software

Standard-Software Individual-Software

z.B. Office

Installieren

buy

Individual

Alles neu programmieren

make

z.B. SAP

Konfigurieren, parametrisieren

customize

Platform

Integration von bestehenden Komponenten

assemble

Framework

Verwendung bestehendes Programmier-Framework

build



8

Wann ist eine Software wirklich Standardsoftware?

1. Verbreitung: viele Nutzer verwenden die Software (de facto Standard) 2. Wiederverwendung: Software ist grössenteils bei allen Nutzern gleich 3. Funktionale Abdeckung: Anforderungen von allen Nutzern werden erfüllt 4. Parametrisierung: Individualisierung mittels Konfigurationen 5. Erweiterbarkeit: neue Funktionen (Plug-ins) über spezifizierte Schnittstellen 6. Verbesserungen: Software wird laufend weiterentwickelt 7. Release-Fähigkeit: neues Release kann bei allen Nutzern eingesetzt

werden, auch wenn sie Erweiterungen programmiert haben 8. Change Management: neue Releases berücksichtigen Anforderungen von

allen Nutzern 9. Kompatibilität: Daten können zwischen Nutzern transferiert werden, es

besteht Vorwärts- und Rückwärtskompatibilität 10. Support: mehrere Anbieter im Markt bieten Beratung, Implementierung,

Wartung, Erweiterungen, Bug Fixings etc. an



9

Varianten der Software-Nutzung

Quelle: SBB, 2010 – «Prinzip A9: Gesamtwirtschaftliche Open Source Entscheide»



10

Standardisierung in der Informatik

Was kann sonst noch alles in der Informatik standardisiert werden?

1. Datenformate (OOXML, ODF etc.) 2. Kommunikationsprotokolle (HTTP etc.) 3. Schnittstellen (Application Programming Interfaces APIs) 4. Software-Entwicklung (Programmiersprache, Patterns etc.) 5. Betriebssystem (Server, Client, Mobile etc.) 6. Middleware (Oracle Datenbank, IBM Application Server etc.) 7. Endbenutzer Software-Produkte (Microsoft Office etc.) 8. Benutzer-Identität (Identity and Access Management) 9. Benutzerkonzepte (Bedienungsoberfläche, Usability) 10. Begriffe, IT-Architektur, Prinzipien, Geschäftsprozesse (eCH-Standards) 11. Strategien, Vorgaben, Services (Sicherheitrichtlinien etc.)



11

eCH Standards

Quelle: http://www.ech.ch/vechweb/page?p=categoryList&site=/documents/Alle/A%20bis%20Z

http://www.ech.ch/vechweb/page?p=categoryList&site=/documents/Alle/A%20bis%20Z



12

Vor- und Nachteile von Produkt-Standardisierung

Gründe für Standardisierung: 1. Skaleneffekte (beim Hersteller!) 2. Weniger unterschiedliche

Plattformen müssen aktuell gehalten werden

3. Weniger Komplexität dank einheitlicher Technologie-Architektur

4. Einsparungen im Betrieb (Anwendung, Entwicklung, Support, Schulung etc.)

Gründe gegen Standardisierung: 1. Hoher Koordinierungsaufwand

zwischen Behördenstellen, unterschiedliche Interessen

2. Weniger rasche Anpassungsfähigkeit an technologische Entwicklungen

3. Abhängigkeit von einem Hersteller, Einschränkung des Wettbewerbs, freihändige Vergaben notwendig

Zielsetzung sollte sein: Vorteile von Standardisierung nutzen und deren Nachteile reduzieren.



13

Wann macht Standardisierung Sinn?

Standardisierung macht Sinn bei: > Nicht proprietäre Daten, Metadaten, Formaten, Protokollen,

Schnittstellen > Vorgaben, Begriffen, Strategien

Standardisierung ist kritisch bei: > Programmiersprachen und Betriebssystemen > Software-Produkten

Optimale Voraussetzungen: > Offene Standards > Implementierung des offenen Standards als Open Source Software > Mehrere Hersteller, welche den Standard einsetzen



14

Agenda












15

https://www.nzz.ch/fragwuerdige_auftragsvergabe_des_bundes_an_microsoft-1.2502044

https://www.nzz.ch/fragwuerdige_auftragsvergabe_des_bundes_an_microsoft-1.2502044



16

http://www.derbund.ch/schweiz/standard/freihaendige-itgrossauftraege-des-bundes-sorgen-fuer-unmut/story/29200791

















17



18



19

Quelle: http://www.computerworld.ch/news/it-branche/artikel/das-system-freihaender-viel-optimierungspotenzial-70184/

http://www.computerworld.ch/news/it-branche/artikel/das-system-freihaender-viel-optimierungspotenzial-70184/
















20

SRF Rundschau zu IT-Beschaffungen

Link: http://www.srf.ch/news/schweiz/it-projekte-milliarden-ohne-ausschreibung

http://www.srf.ch/news/schweiz/it-projekte-milliarden-ohne-ausschreibung












21

IT- und CT-Projekte auf simap.ch

Information Technology: > 48000000 Softwarepaket und Informationssysteme > 72000000 IT-Dienste: Beratung, Software-Entwicklung, Internet und Hilfestellung > 51600000 Installation von Computern und Büromaschinen > 30200000 Computeranlagen und Zubehör Communication Technology: (noch nicht ausgewertet) > 32000000: Rundfunk- und Fernsehgeräte, Kommunikations- und Fernmelde-anlagen und Zubehör > 35700000: Militärische elektronische Systeme > 45314000: Installation von Fernmeldeanlagen > 48219700: Kommunikationsserversoftwarepaket > 48500000: Kommunikations- und Multimedia-Softwarepaket > 50330000: Wartung von Fernmeldeeinrichtungen > 51300000: Installation von Kommunikationsgeräten > 64200000: Fernmeldedienste > 71316000: Beratung in der Fernmeldetechnik



22

Anzahl monatliche Zuschläge total

Quelle: Publikationen auf simap.ch

Durchschnitt: 455.75 Zuschläge / Monat seit 2015



23

Anzahl monatliche IT-Zuschläge

Durchschnitt: 50.56 IT-Zuschläge pro Monat seit 2015

Quelle: Publikationen auf simap.ch (IT: Filterung nach CPV Codes 48****, 72****, 516***, 302***)



24

Anzahl monatliche IT-Freihänder

Quelle: Publikationen auf simap.ch (IT: Filterung nach CPV Codes 48****, 72****, 516***, 302***)

Durchschnitt (seit 2015): 20.19 IT-Freihänder pro Monat



25

simap.ch Analyse: Freihänder-Anteil bei IT-Projekten und nicht-IT-Projekten

Quelle: Matthias Stuermer, Oliver Krancher, Thomas Myrach 2017 "When the exception becomes the norm: Direct awards to IT vendors by the Swiss public sector" 10th International Conference on Theory and Practice of Electronic Governance (ICEGOV 2017) in New Dehli, India

47.2%

14.6%



26

www.beschaffungsstatistik.ch



27

Noch nicht erfasst: «Offene» Produkte-Ausschreibungen



28

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



29

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



30

Marketing vs. R&D bei Microsoft

Sales and marketing FY 2014: 15.8 Mia. $ → 49% der Ausgaben Research and development FY 2014: 11.4 Mia. $ → 35% der Ausgaben

Quelle: MICROSOFT CORP. 2014 10-K, http://www.microsoft.com/investor/AnnualReports/default.aspx

http://www.microsoft.com/investor/AnnualReports/default.aspx

http://www.microsoft.com/investor/AnnualReports/default.aspx



31

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



32

Realität: Verhandlungsschwierigkeiten mit IT-Herstellern

> Vertragsprobleme mit Adobe wegen Adobe Cloud Produkten und Adobe Experience Manager (AEM)

> Schwierige Situation mit Microsoft wegen Enterprise Agreements > Unfriendly Partner Oracle wegen Lizenz-Audits und Volumenpreise > Was macht SAP so? Fazit: > Viele grosse IT-Hersteller bereiten (neben technischen Problemen)

auch vertragliche Schwierigkeiten > Behörden haben kaum Verhandlungsstärke weil keine Alternative

bekannt/vorhanden sind > Schon nur glaubhafte Prüfung von Open Source Alternativen kann

Lizenzpreise senken



33

Agenda












34

Nachhaltigkeit

> Ursprüngliche Idee: Nur so viele Bäume fällen wie nachwachsen können. (Hans Carl von Carlowitz, 1713)

> Definition im Brundtland Bericht, 1987: „Dauerhafte Entwicklung ist Entwicklung, die die Bedürfnisse der Gegenwart befriedigt, ohne zu riskieren, dass künftige Generationen ihre eigenen Bedürfnisse nicht befriedigen können.“



35

Schützenswerte Ressourcen in der nachhaltigen Entwicklung

Umwelt Menschen

Volkswirtschaft Wissen



36

Güterklassen

Quelle: N. Gregory Mankiw, Principles of Economics, Dryden 1998.

Privates Gut Klubgut

Allmendegut Öffentliches Gut

Rivalität

nicht-rivalisierend rivalisierend

ausschliessbar

nicht ausschliessbar

Ausschliessbarkeit z.B. proprietäre Software

digital nachhaltige Güter

Digitale Welt Physische Welt



37

Wissen, Information, Daten



38

Digitales Wissen wächst exponentiell (Big Data)



39

Zielsetzung digitale Nachhaltigkeit

Den Nutzen der Digitalisierung für die ganze Gesellschaft maximieren



40

10 Voraussetzungen für digitale Nachhaltigkeit

Ökosystem

Digitales Gut

1. Ausgereiftheit 2. Transparente Strukturen 3. Semantische Daten 4. Verteilte Standorte

schaffen nutzen

Welt

5. Freie Lizenz 6. Geteiltes Wissen 7. Partizipations-Kultur 8. Faire Führungsstrukturen 9. Breit abgestützte Finanzierung

10. Beitrag zur nachhaltigen Entwicklung

Quelle: Stuermer, M., Abu-Tayeh, G. and Myrach, T. (2017). Digital sustainability: basic conditions for sustainable digital artifacts and their ecosystems, Sustainability Science 12: 247-262. doi:10.1007/s11625-016-0412-2

http://link.springer.com/article/10.1007/s11625-016-0412-2









41

1. Ausgereiftheit

> Ausgereiftheit umfasst Verständlichkeit, Vollständigkeit, Korrektheit, Modularität, Integrität, Präzision, Sicherheit etc. von digitalen Gütern

> Hohe Qualität von digitalen Gütern schafft direkten Nutzen von deren Anwendern und erleichert künftige Verbesserungen



42

2. Transparente Strukturen

> Technische Offenheit des digitalen Guts: — Detaillierte Spezifikation der Datenstrukturen und Formate — Offen zugänglicher Software-Quellcode — Offen zugängliche Informations-Architektur und Dokumentation

> Transparenz ermöglicht Kontrolle und Verbesserungen durch die Öffentlichkeit was zu mehr Vertrauen und weniger Fehler führt



43

3. Semantische Daten

> Semantische Informationen (Meta-Daten, Ontologien) sind maschinenlesbare und/oder für Menschen verständliche Angaben über ein digitales Gut

> Mit semantischen Informationen kann Wissen besser absorbiert, weiterverarbeitet, interpretiert und weiterentwickelt werden



44

4. Verteilte Standorte

> Digitale Güter sind bspw. als redundate Server oder Peer-to-Peer mehrfach an physisch unterschiedlichen Orten gespeichert

> Abhängigkeit von einem einzigen Standort wird reduziert

> Langfristige Verfügbarkeit der digitalen Güter

Bild-Quelle: Paul Baran 1964 "On distributed communications networks." Communications Systems, IEEE Transactions



45

5. Freie Lizenz

> Allen ist erlaubt, digitales Gut zu nutzen und zu verändern

> Bereits erschaffenes Wissen kann beliebig wiederverwendet werden «Standing on the shoulders of giants»

> Gesellschaft profitiert durch freie Zugänglichkeit des digitalen Wissens und Vermeidung von «Rad neu erfinden»

> Offene Frage: mit oder ohne Copyleft?



46

6. Geteiltes Wissen

> Know-How, Kenntnisse und Erfahrungen über digitale Güter sind verteilt auf viele Personen aus unterschiedlichen Organisationen

> «Wissens-Abhängigkeit» von wenigen Personen, Firmen und anderen Organisationen wird reduziert

> Beiträge von vielen zu digitalen Gütern werden ermöglicht



47

7. Partizipations-Kultur

> Alle kompetenten Leute mit konstruktiven Beiträgen können an Weiterentwicklung des digitalen Guts partizipieren (Community)

> Peer-review Prozesse stellen Qualität sicher

> Ökosystem um digitales Gut stellt Partizipations-Kultur sicher



48

8. Faire Führungsstrukturen

> Kontrolle über digitales Gut liegt nicht bei einer Person oder Organisation sondern ist dezentral organisiert

> Governance-Prozesse (Wahlen etc.) regeln Verantwortlichkeiten

> Offene Frage: Je grösser der Beitrag, umso grösser die Kontrolle (Meritokratie)?



49

9. Breit abgestützte Finanzierung

> Finanzierung der technischen Infrastruktur, Personal etc. erfolgt durch verschiedene Akteure

> Breit abgestützte Finanzierung schafft Unabhängigkeit von einer einzelnen Organisation und reduziert Interessenskonflikte



50

10. Beitrag zur nachhaltigen Entwicklung

> Das digitale Gut und dessen Ökosystem leisten Beitrag zur nachhaltigen Entwicklung

> Schaffen und Nutzen von digitalen Gütern verbraucht natürliche und soziale Ressourcen. Sind diese nachhaltig? (bspw. erneuerbare Energiequellen)

> Herausforderung: Anwendung von digitalen Gütern kann nachhaltige Entwicklung fördern oder beeinträchtigen



51

Linux Kernel

Top 10 Firmen, die vom 02.09.2013 bis 07.12.2014 zur Linux Kernel Entwicklung beigetragen haben:

Quelle: Linux Foundation, February 2015 „Linux Kernel Development How Fast is it Going, Who is Doing It, What Are They Doing and Who is Sponsoring the Work“ http://www.linuxfoundation.org/publications/linux-foundation/who-writes-linux-2015

http://www.linuxfoundation.org/publications/linux-foundation/who-writes-linux-2015












52

Wikipedia



53

OpenStreetMap

Quelle: http://tools.geofabrik.de/mc/#18/46.9477/7.4254&num=2&mt0=mapnik&mt1=google-map

http://tools.geofabrik.de/mc/18/46.9477/7.4254&num=2&mt0=mapnik&mt1=google-map







54

Linked Open Data

Quelle: http://lod-cloud.net

http://lod-cloud.net/






55

Bitcoin und Blockchain-Technologien

Quelle: Reuters Graphics




56

Weitere spannende Beispiele



57

Agenda












58


> Anbieter entwickelt Software und verkauft Nutzungslizenz an Anwender

> Anbieter behält Urheberrecht an der Software

> Anwender kann die Software gemäss Lizenzbestimmungen nutzen

> Proprietäre Lizenz gibt vor, dass Software nur von bestimmter Anzahl Nutzer verwendet werden kann oder nur für bestimmte Prozessor-Art etc.

> Anwender kennt Software-Code nicht und darf Software nicht kopieren oder ändern


Anbieter

Anwender

Proprietäre Lizenz



59

Open Source Software

Ein Software-Produkt wird als Open Source Software bezeichnet, wenn es unter einer der rund 70 Lizenzen veröffentlicht ist, welche durch die Open Source Initiative (OSI, www.opensource.org) abgesegnet sind.

Alle Open Source Lizenzen geben vor: 1. Software darf beliebig eingesetzt werden 2. Quellcode der Software ist zugänglich 3. Software darf beliebig kopiert und

verbreitet werden 4. Software darf verändert und der

veränderter Form weitergegeben werden Quelle: http://www.opensource.ch/oss-knowhow/details/kbarticle/open-source-software-im-geschaeftskritischen-einsatz/

Anwender

Anbieter

Open Source Lizenz

Anwender

Anwender

Open Source Software mit

Quellcode

http://www.opensource.ch/oss-knowhow/details/kbarticle/open-source-software-im-geschaeftskritischen-einsatz/
















60

Open Source Beispiel Ubuntu

> Linux-basiertes Betriebssystem für Endanwender, Schulen, Behörden, Firmen etc.

> Freie Alternative zu Microsoft Windows

> Läuft auf Desktops (auch Mac), Tablets, Smartphones, Servers etc.

> Alle 6 Monate neue Version: 17.04 aktuelle Version

> Software wird als Debian-Packages übers Internet installiert

> Wird von vielen Millionen Anwendern genutzt

> Download unter www.ubuntu.com

http://www.ubuntu.com/



61



62

Open Source Beispiel LibreOffice

> Office-Suite mit Text, Tabellen, Folienpräsentation, Grafik etc.

> Freie Alternative zu Microsoft Office

> Läuft auf Windows, Mac und Linux

> Auch als Cloud verfügbar: Collabora LibreOffice Online

> Unterstützt das offene Dokumentenformat ODF

> Wird von vielen Firmen, Verwaltungen, Schulen, Privatpersonen etc. verwendet

> Download unter www.libreoffice.org

http://www.libreoffice.org/



63



64

Open Source Beispiel Zotero

> Literatur-Verwaltung und Zitieren > Freie Alternative zu Endnote > Läuft auf Windows, Mac und Linux > Firefox-Plugin für Download von Literatur > Gratis Cloud-Konto bis 300 MB Speicher > Kann in LibreOffice und Microsoft Word integriert werden > Unterstützt viele Export-Formate für Bachelorarbeit, Journals und

andere Publikationen > Wird von vielen Studierenden und Forschenden verwendet > Download unter www.zotero.org

http://www.zotero.org/



65



66

www.alternativeto.net

http://alternativeto.net/



67

Open Source Studie Schweiz 2015

> Alle 3 Jahre im Auftrag von swissICT und CH Open

> Ausgeführt durch Forschungsstelle Digitale Nachhaltigkeit

> Finanziert durch ISB, educa.ch, Kanton Bern und OSS Anbieter

> Genau 200 CEOs, CTOs, CIOs etc. haben alle Fragen beantwortet

> Rund 20 Fachartikel und Praxisbeispiele enthalten

Quelle: www.swissict.ch/oss2015/

http://www.swissict.ch/oss2015/

http://www.swissict.ch/oss2015/



68

Einsatzgrad nach Branchen



69

Einsatzgründe für Open Source Software



70

Hinderungsgründe beim Einsatz



71

Eigenschaft von Open Source Software: Hohe Modularität



72

Eigenschaft von Open Source Software: Niedrige Herstellerabhängigkeit

Top 10 Firmen, die vom 02.09.2013 bis 07.12.2014 zur Linux Kernel Entwicklung beigetragen haben:

Quelle: Linux Foundation, February 2015 „Linux Kernel Development How Fast is it Going, Who is Doing It, What Are They Doing and Who is Sponsoring the Work“ http://www.linuxfoundation.org/publications/linux-foundation/who-writes-linux-2015













73

Eigenschaft von Open Source Software: Nachhaltige Software-Entwicklung

Quelle: Björn Lundella, Brian Lings, Anna Syberfeldt 2011 “Practitioner perceptions of Open Source software in the embedded systems area” The Journal of Systems and Software 84, p. 1540– 1549

Bild: „Airbus A380“ von Dmitry A. Mottl - Eigenes Werk. Lizenziert unter Gemeinfrei über Wikimedia Commons

„There are many systems still being maintained after 30 years. In some parts of this sector life-cycles are even longer, with 70 years not being uncommon for avionics.“




74

Eigenschaft von Open Source Software: Niedrigere Entwicklungskosten

Link: https://www.genivi.org

https://www.genivi.org/

https://www.genivi.org/



75

Open Source Lizenzen

Drei Kategorien von Open Source Lizenzen: 1. Starkes Copyleft: GNU General Public

License (GPL), Affero GPL

2. Schwaches Copyleft: GNU Lesser General Public License (LGPL) und Mozilla Public License MPL

3. Permissive Lizenzen (kein Copyleft): Berkley Software Distribution BSD, MIT License, Apache Software License etc.



76

Copyleft

> Wortspiel: Copyright vs. Copyleft

> Enthalten in: GNU GPL

> Wahrung der Freiheit als grundlegende Idee: Freie Software bleibt für immer Freie Software

> Vorgabe: Veränderte Software muss unter gleichen Bedingungen freigegeben werden

> Viraler Effekt: alle abgeleiteten Werke werden von Copyleft «infiziert»

> Aber nicht alle Open Source Lizenzen haben Copyleft-Eigenschaft



77

Fortschritt der Open Source Alternativen

Zeit

Funktionalität

Kundenanforderungen z.B. für Büroautomation oder Datenbanken

Heute

Proprietäres Produkt z.B. Microsoft Office, Oracle Datenbank

Vor 10 Jahren

Open Source Produkt z.B. LibreOffice oder PostgreSQL

Quelle: Diagramm von Clayton M. Christensen „The Innovator's Dilemma“ (1997) angepasst an den Open Source Kontext



78

Einsatz von Open Source Software

> 1) Einsatz ohne professionellen Support — OSS gratis aus dem Internet runterladen und installieren — Vorteile: niedrige Kosten, rasche Umsetzung — Nachteile: kein garantierter Support, keine Haftungsansprüche

> 2) Einsatz mit internem Support — Internes Knowhow aufbauen und Ressourcen bestimmen — Vorteile: hohe Flexibilität, keine Anbieterabhängigkeiten — Nachteile: hohe Investitionen, interne Fixkosten für Mitarbeitende

> 3) Einsatz durch externen Anbieter — Subscriptions und Wartungs- und Supportverträge mit Externen — Vorteile: Verbindlichkeiten, Absicherung „gegen oben“ — Nachteile: externe Kosten, Abhängigkeiten zu Anbietern

Quelle: http://www.opensource.ch/oss-knowhow/details/kbarticle/open-source-software-im-geschaeftskritischen-einsatz/




79

Geschäftsmodelle mit Open Source

1. Software-Entwicklung als Auftrag oder Werkvertrag

2. Verkauf von Service Level Agreement (SLA) oder Subscriptions für Support, Haftung, Gewährleistung, Hardware-Kompatibilität etc. (Red Hat, SUSE etc.)

3. Ergänzung zu Software- und Hardware Produkten (IBM etc.)

4. Nutzung im Rahmen von Software as a Service (Cloud)

5. Multiple Licensing: Verkauf von Rechten über die OSS Lizenz hinaus (z.B. Verzicht auf Copyleft)

6. Verkauf von Werbung (Google, Facebook, Twitter etc.)



80

Quelle: http://www.zdnet.com/article/red-hat-becomes-first-2b-open-source-company/

http://www.zdnet.com/article/red-hat-becomes-first-2b-open-source-company/


















81

Informationsplattform zu Open Source



82

Verzeichnis von Open Source Anbietern www.ossdirectory.ch



83

OSS-Strategie der Bundesverwaltung

> Publikation: 15.03.2005 durch ISB > Geplante Massnahmen gemäss Aktionsplan:

— Standardisierung von Open Source Produkten — OSS-Referenzlösungen für E-Government Projekte — Erfahrungsaustausch und Kommunikation innerhalb der

Bundesverwaltung (inkl. jährliche Konferenz) — Überwachung der Umsetzung der OSS-Strategie — Web-Plattform innerhalb der Bundesverwaltung zum

Informations- und Erfahrungsaustausch — OSS-Ausbildungsangebote und –Zertifizierungen — TCO-Modell zur Analyse der Kosten von OSS vs.

proprietäre Software — OSS-Referenz-Client der Bundesverwaltung

> Erneuerung der OSS-Strategie bis Ende 2018

Quelle: http://www.isb.admin.ch/themen/strategien/00745/00750/

http://www.isb.admin.ch/themen/strategien/00745/00750/

http://www.isb.admin.ch/themen/strategien/00745/00750/



84

Ausländische Beschaffungsleitfäden zu Open Source Software

Quellen: https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/78962/ICT-Advice-Note-Procurement-of-Open-Source.pdf http://www.finance.gov.au/files/2012/04/AGuidetoOpenSourceSoftware.pdf https://joinup.ec.europa.eu/sites/default/files/24/ac/83/OSS-procurement-guideline%20-final.pdf

https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/78962/ICT-Advice-Note-Procurement-of-Open-Source.pdf

http://www.finance.gov.au/files/2012/04/AGuidetoOpenSourceSoftware.pdf

https://joinup.ec.europa.eu/sites/default/files/24/ac/83/OSS-procurement-guideline%20-final.pdf



85

Open Source by default in UK

> “Where appropriate, government will procure open source solutions. When used in conjunction with compulsory open standards, open source presents significant opportunities for the design and delivery of interoperable solutions.”

> “Ensure a level-playing field for open source software. Demonstrate an active and fair consideration of using open source software – taking account of the total lifetime cost of ownership of the solution, including exit and transition costs.”

Quelle: https://www.gov.uk/service-manual/making-software/open-source.html

https://www.gov.uk/service-manual/making-software/open-source.html










86

Rahmenverträge mit Open Source Anbietern in Schweden

> Verwaltung hat einen kompetenten Ansprechspartner für Vielzahl von Open Source Produkten

> Verwaltung erhält Beschaffungssicherheit und Anleitung für Vorgehen

> Rahmenvertrag deckt Urheberrecht, Haftung, Gewährleistung etc. ab

> Beschaffungen von Open Source durch Mini-Tenders werden für Verwaltung einfach

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

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








87

Weitere Informationsquellen zu Open Source Software

> Schweizer Open Source Plattform: www.opensource.ch

> Verzeichnis von Firmen, Referenzen, Produkten und Kunden: www.ossdirectory.ch

> Verein zur Förderung von Open Source in der Schweiz: www.ch-open.ch

> Informationen über Open Source Projekte: http://www.openhub.net

> Open Source Alternativen: www.alternativeto.net

> Auswahl von OSS Programmen für Windows (in deutsch): www.opensource-dvd.de

http://www.opensource.ch/

http://www.ossdirectory.ch/

http://www.ch-open.ch/

http://www.openhub.net/

http://www.alternativeto.net/

http://www.opensource-dvd.de/



88

Agenda












89

Einkaufspreis ist nur die Spitze des Eisbergs

Quelle: http://www.business.govt.nz/procurement/pdf-library/agencies/guides-and-tools/guide-total-cost-ownership.pdf

http://www.business.govt.nz/procurement/pdf-library/agencies/guides-and-tools/guide-total-cost-ownership.pdf
















90

Kostenbestandteile über die Lebensdauer





91

Beispiel einer TCO-Berechnung


















92

TCO bei Open Source Migrationen

Quelle: http://www.itmagazine.ch/Artikel/55166/Mehr_Geld__im_Portemonnaie__und_weniger__Sorgen_im_Gepaeck.html

http://www.itmagazine.ch/Artikel/55166/Mehr_Geld__im_Portemonnaie__und_weniger__Sorgen_im_Gepaeck.html

http://www.itmagazine.ch/Artikel/55166/Mehr_Geld__im_Portemonnaie__und_weniger__Sorgen_im_Gepaeck.html



93

Stadtrats-Entscheid, 11. November 2015

Quelle: http://www.derbund.ch/bern/stadt/stadt-bern-will-bei-it-weg-von-microsoftabhaengigkeit/story/26966635a

http://www.derbund.ch/bern/stadt/stadt-bern-will-bei-it-weg-von-microsoftabhaengigkeit/story/26966635a



















94

Kantonsinformatik, 7. November 2016

Quelle: http://www.derbund.ch/bern/kanton/kein-photoshop-mehr-fuer-den-kanton-bern/story/15491926

http://www.derbund.ch/bern/kanton/kein-photoshop-mehr-fuer-den-kanton-bern/story/15491926
















95

Oracle-Ablösung durch MariaDB bei der Post

Quelle: http://www.ossdirectory.com/oss-knowhow/details/kbarticle/mariadb-migration-der-kassenapllikation-v-max/

http://www.ossdirectory.com/oss-knowhow/details/kbarticle/mariadb-migration-der-kassenapllikation-v-max/
















96

Italienisches Militär spart 26-29 Mio. EUR mit LibreOffice Migration

Quelle: https://joinup.ec.europa.eu/community/osor/news/italian-military-save-26-29-million-euro-migrating-libreoffice

https://joinup.ec.europa.eu/community/osor/news/italian-military-save-26-29-million-euro-migrating-libreoffice




















97

Gemeinsam Open Source Software weiterentwickeln

Varianten: 1. Erweiterung einer bestehenden Open Source Lösung 2. Gemeinsame Entwicklung einer neuen Open Source Lösung

Vorteile: > Kosten der Weiterentwicklung können aufgeteilt werden > Alle haben uneingeschränktes Nutzungsrecht der Software > Weiterentwicklung kann auf verschiedene Firmen verteilt werden

Herausforderungen: > Grosser Koordinationsaufwand > Möglicherweise wenig Anbieter



98

Einzelne Features erweitern auf www.bountysource.com



99

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

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












100

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



101

CAMAC

> Open Source Baugesuchsverwaltung von 8 Schweizer Kantonen > www.camac.ch

http://www.camac.ch/



102

Agenda












103

BBL Merkblatt Software-Ausschreibungen

Software-Ausschreibungen: Sicherstellung eines breiten Wettbewerbs



104


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. Vorgegebenen Schnittstellen und Dateiformate basieren soweit möglich sowie technisch und wirtschaftlich sinnvoll auf offenen, frei zugänglichen Spezifikationen und Standards



105


Aussagen zu proprietärer Software:

> Bei proprietärer Software besitzt Hersteller alle Schutzrechte und gewährt Nutzungsrecht an seiner Software gegen Lizenzgebühr

> Proprietäre Software darf von Nutzern grundsätzlich nicht verändert oder weitergegeben werden

> Verbesserung und Funktionstüchtigkeit der Software stellt allein der Hersteller mittels periodischer Upgrades und Major-Releases sicher

> Hersteller arbeitet oft mit exklusiven Partnern für Lizenzeverkauf und/oder die Wartung zusammen



106

Agenda












107

SIK Checkliste «Beschaffung von Open Source»

> Ziel ist die bessere Berücksichtigung von Open Source Software bei der Beschaffung von IT

> Erabeitet durch die Arbeitgruppe Open Source Software der Schweizerischen Informatikkonferenz (SIK)

> Aktueller Stand: 18. August 2015, Version 1.0

> Mit Rückmeldungen von Behördenstellen, Beschaffungsjuristen und Open Source Experten

http://www.digitale-nachhaltigkeit.unibe.ch/e273593/e303697/e374606/e374617/SIKChecklisteOpenSourceSoftware26.05.2015_ger.pdf







108

1. Voranalyse/Konzeption

> Ist genügend Verständnis über das Open Source Entwicklungsmodell vorhanden? — Unterschiedliche Open Source Lizenzen — Geschäftsmodelle von Open Source Anbietern — Leistungen von Service Level Agreements etc.

> Sind bestehende Open Source Lösungen geprüft worden? — OSS kann ohne Ausschreibung genutzt werden (interne Realisierung) — OSS Directory: www.ossdirectory.com — AlternativeTo: www.alternativeto.net

> Welcher Funktionsumfang wird tatsächlich benötigt? — Tendenz zur Beschaffung von zu hohem Leistungsumfang — Open Source Alternativen sind meistens Ausreichend

http://www.ossdirectory.com/

http://www.alternativeto.net/



109

2. Kriterien die verhindern, dass Open Source ausgeschlossen wird

> 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 eingeschränkt, langfristig Zunahme der Informatikkosten

— Vorgabe von OSS Lösungen kann sinnvoll sein, denn sie kann von allen kompetenten Dienstleistern angeboten werden

> Besteht ein Hinweis, dass auch Open Source Software angeboten werden kann? — AGBs von Bund und SIK lassen Beschaffung von OSS zu — Hinweis sinnvoll, dass Lösungen basierend auf OSS zugelassen sind



110

2. Kriterien die verhindern, dass Open Source ausgeschlossen wird

> Sind Subunternehmer und Bietergemeinschaften zugelassen? — Viele der guten OSS Entwickler sind selbständig oder in kleinen Firmen — Ausschreibungen sollten Subunternehmer oder Konsortium zulassen

> Sind Firmengrösse und Referenzen nicht zu hoch vorgegeben? — OSS Anbieter sind tendenziell kleiner als proprietäre Hersteller — OSS Lösungen sind (wegen Abhängigkeiten) meist weniger verbreitet — Um OSS Anbieter nicht indirekt auszuschliessen sollten bei

Eignungskriterien nicht unnötig hohe Anforderungen an Firmengrösse, Mitarbeiterzahl, Referenzen, installierte Versionen etc. gestellt werden

— Auch bei Grossunternehmen sind nur wenige Mitarbeitende fürs Projekt zuständig

— Bei Grossunternehmen ist Mitarbeiterfluktuation meist höher und Identifikation oft niedriger als bei kleinen Firmen



111

3. Kriterien, welche die Eigenschaften von Open Source berücksichtigen

> Wird die Lieferung der Software unter einer Open Source Lizenz in der technischen Spezifikation vorgegeben bzw. wird Open Source als Zuschlagskriterium bemessen? — OSS darf uneingeschränkt und kostenlos verwendet und kopiert werden — 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 erlaubt — Z.B. OSS als ZK bei GEVER-Ausschreibung Kt. Bern:



112


> Werden „Open Source Kompetenzen“ des Anbieter als Eignungskriterium vorgegeben? — Wenn OSS beschafft werden soll machen Open Source Kompetenzen

des Anbieters als Eignungskriterium Sinn

> Besteht Zugang zum vollständigen Quellcode der offerierten Software-Lösung? — Zugang zum Quellcode aus Sicherheits- und Datenschutzsicht wichtig

um selber oder durch Dritte Sicherheitslücken oder Backdoors zu finden — Zugang zum Quellcode um Code-Qualität oder Dokumentation zu prüfen — Bei OSS ist vollständiger Zugang zum Quellcode immer gewährleistet,

bei proprietärer Software normalerweise nicht oder nicht vollständig



113


> Werden die Kosten der IT-Lösung über ihren gesamten Lebenszyklus bemessen? (TCO) — OSS in der Einführung oft teurer als Upgrade bisheriger proprietärer

Software wegen technischer und personeller Veränderungen (Migration, Anpassungen, Umschulungen etc.)

— Jedoch Betriebs- und Wartungskosten wesentlich höher als Beschaffungs- und Einführungskosten (Betrieb ca. 3x länger als Projekt)

— Ausschreibung sollte gesamte Lebensdauer der IT-Lösung berücksichtigen

> Wird Risiko des Konkurses bei proprietären Lösungen bemessen? — Geht Hersteller von proprietärer Software in Konkurs, fallen Rechte am

Quellcode in die Konkursmasse — Bei Open Source Software kann ein anderer Dienstleister mit

Weiterentwicklung des Systems beauftragt werden



114


> 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 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 — Als ZK Anzahl kommerzielle Anbieter für OSS Lösung berücksichtigen

http://www.openhub.net/



115

Agenda












116

Fehlerhafte Bezeichnung

Fehlerhafte Berücksichtigung von Open Source Software: > Die Open Source Initiative zertifiziert keine Software, sondern

bloss die Open Source Lizenzen

Quelle: Ausschreibung «IT@KOS Beschaffung Schulverwaltungs-Lösung», 24.01.2017



117

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



118

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 Open Source Framework "Qlack Fuse" verwenden.

> Wichtige Fragen bei Open Source Beschaffungen:

1. Welche Zuschlagskriterien wären bezüglich Open Source sinnvoll um die Abhängigkeit vom Hersteller zu reduzieren?

2. Wie lassen sich diese Zuschlagskriterien bemessen? (Nachweis)

http://www.qlack.com/fuse



119

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

http://www.ossdirectory.com/

https://www.openhub.net/



120

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







121

Abschluss