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
121
Embed
Standardisierung, Herstellerabhängigkeiten und Open Source Software
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
> Digitale Nachhaltigkeit: Theorie, Kriterien etc.
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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)
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
9
Varianten der Software-Nutzung
Quelle: SBB, 2010 – «Prinzip A9: Gesamtwirtschaftliche Open Source Entscheide»
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
10
Standardisierung in der Informatik
Was kann sonst noch alles in der Informatik standardisiert werden?
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.
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
14
Agenda
Standardisierung, Herstellerabhängigkeiten und Open Source Software
1. Standardsoftware vs. Individualentwicklungen
2. Freihändige Vergaben und Herstellerabhängigkeiten
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
22
Anzahl monatliche Zuschläge total
Quelle: Publikationen auf simap.ch
Durchschnitt: 455.75 Zuschläge / Monat seit 2015
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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***)
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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%
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
26
www.beschaffungsstatistik.ch
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
27
Noch nicht erfasst: «Offene» Produkte-Ausschreibungen
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,
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
33
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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.“
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
35
Schützenswerte Ressourcen in der nachhaltigen Entwicklung
Umwelt Menschen
Volkswirtschaft Wissen
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
37
Wissen, Information, Daten
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
38
Digitales Wissen wächst exponentiell (Big Data)
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
39
Zielsetzung digitale Nachhaltigkeit
Den Nutzen der Digitalisierung für die ganze Gesellschaft maximieren
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
> Offene Frage: Je grösser der Beitrag, umso grösser die Kontrolle (Meritokratie)?
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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/
> 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
Eigenschaft von Open Source Software: Hohe Modularität
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
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.“
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.
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
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.)
> “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.”
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
98
Einzelne Features erweitern auf www.bountysource.com
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
101
CAMAC
> Open Source Baugesuchsverwaltung von 8 Schweizer Kantonen > www.camac.ch
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
103
BBL Merkblatt Software-Ausschreibungen
Software-Ausschreibungen: Sicherstellung eines breiten Wettbewerbs
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
104
BBL Merkblatt Software-Ausschreibungen
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
105
BBL Merkblatt Software-Ausschreibungen
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
106
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
> 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
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
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:
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
112
3. Kriterien, welche die Eigenschaften von Open Source berücksichtigen
> 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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
113
3. Kriterien, welche die Eigenschaften von Open Source berücksichtigen
> 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
CAS ICT-Beschaffungen 2017
Block 2.1: Von der ICT-Strategie zum ICT-Projekt
114
3. Kriterien, welche die Eigenschaften von Open Source berücksichtigen
> 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
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
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)
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