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

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
matthias.stuermer@iwi.unibe.ch
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

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

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

20
SRF Rundschau zu IT-Beschaffungen
Link: 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

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

31
Weniger Anbieter-Abhängigkeiten mit
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-rivalisierendrivalisierend
ausschliessbar
nicht ausschliessbar
Ausschliessbarkeit
z.B. proprietäre Software
digital nachhaltige Güter
Digitale WeltPhysische 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

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

52
Wikipedia

53
OpenStreetMap
Quelle: 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

55
Bitcoin und Blockchain-Technologien
Quelle: Reuters Graphics

56
Weitere spannende Beispiele

57
Agenda

58
Proprietäre Software
> 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
Proprietäre
Software
Anbieter
Anwender
Proprietäre
Lizenz

59
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

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

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

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

65

66
www.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/

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
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
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
Niedrigere Entwicklungskosten
Link: 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.)

80Quelle: 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/

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

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

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/

87
Weitere Informationsquellen zu
> 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

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

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

93
Stadtrats-Entscheid, 11. November 2015
Quelle: 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

95
Oracle-Ablösung durch MariaDB
bei der Post
Quelle: 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

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

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

102
Agenda

103
BBL Merkblatt
Software-Ausschreibungen
Software-Ausschreibungen: Sicherstellung eines breiten Wettbewerbs

104
BBL Merkblatt
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
BBL Merkblatt
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

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

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)

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

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

121
Abschluss

Standardisierung, Herstellerabhängigkeiten und Open Source Software

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Standardisierung, Herstellerabhängigkeiten und Open Source Software

Similaire à Standardisierung, Herstellerabhängigkeiten und Open Source Software (20)

Plus de Matthias Stürmer

Plus de Matthias Stürmer (18)

Standardisierung, Herstellerabhängigkeiten und Open Source Software