IT-Beschaffung und Open Source Software

Executive MPA des KPM IT-Beschaffung und Open Source Software

Samstag, 2. Juli 2016

Dr. Matthias Stürmer Forschungsstelle Digitale Nachhaltigkeit Institut für Wirtschaftsinformatik Universität Bern

Executive MPA, 2. Juli 2016

E-Government in der Schweiz

2

Matthias Stürmer

> Seit 2013 Oberassistent an der Universität Bern und Leiter der Forschungsstelle 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 Swiss Open Systems User Group /ch/open

> Mitgründer und Vorstandsmitglied Verein Opendata.ch

> Stadtrat von Bern (EVP)

Dr. Matthias Stürmer Oberassistent, Leiter Forschungsstelle Digitale Nachhaltigkeit Universität Bern Institut für Wirtschaftsinformatik Raum 309 (3. Stock) 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

Team von 8 Mitarbeitenden und 3 Doktoranden

Forschung, Lehre und Beratung zu > Open Source Software: Community Governance,

Business Models, Maturitätsmodelle etc. > Open Data: Open Data Apps, Interaktive

Visualisierung, 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.

www.digitale-nachhaltigkeit.unibe.ch




4

Agenda

1. Einführung öffentliche Beschaffung 2. Freihänder bei IT-Beschaffungen 3. Einführung Open Source Software 4. Nachhaltig IT-Kosten sparen mit Open Source 5. BBL-Merkblatt und SIK Checkliste



5

Beschaffungen bei der öffentlichen Hand vs. in der Privatwirtschaft

vs.



6

Ziele des öffentlichen Beschaffungsrechts

1. Wirtschaftlichkeit ist das Hauptziel jeder Beschaffung.

2. Die Gleichbehandlung der Anbieter verbietet die Bevorzugung von „Lieb-lingsanbietern“ oder Ortsansässigen.

3. Um Wirtschaftlichkeit und Gleich-behandlung zu erreichen, soll in Beschaffungen der Wettbewerb spielen.

4. Transparenz bedeutet: Die Spielregeln sind im Voraus bekannt, und jeder Beschaffungsentscheid ist dokumentiert und nachvollziehbar. Das Verfahren, insbesondere die Angebote, sind vertraulich.

1

2

3

4



7

Ziele der Beschaffung in der Privatwirtschaft

1. Wirtschaftlichkeit ist das Hauptziel jeder Beschaffung.

2. Die Gleichbehandlung der Anbieter verbietet die Bevorzugung von „Lieb-lingsanbietern“ oder Ortsansässigen.

3. Um Wirtschaftlichkeit und Gleich-behandlung zu erreichen, soll in Beschaffungen der Wettbewerb spielen.

4. Transparenz bedeutet: Die Spielregeln sind im Voraus bekannt, und jeder Beschaffungsentscheid ist dokumentiert und nachvollziehbar. Das Verfahren, insbesondere die Angebote, sind vertraulich.

1

2

3

4



8

Rechtsgrundlagen

*BöB = Bundesgesetz über das öffentliche Beschaffungswesen; VöB = Verordnung über das öffentliche Beschaffungswesen

Quelle: Schulungsunterlagen Bundesamt für Bauten und Logistik BBL



9

Verfahrensarten

Die Vergabestelle muss eine von vier Verfahrensarten wählen: 1. Das freihändige Verfahren ist nur bei geringen Auftragswerten, bei

fehlendem Wettbewerb oder anderen Ausnahmen möglich. Die Vergabe erfolgt frei und ohne formelles Verfahren.

2. Das Einladungsverfahren ist nur bei mittleren Auftragswerten möglich. Mindestens 3 Anbieter werden anhand eines Pflichtenhefts zur Offertenabgabe eingeladen. Zuschlag erhält das Angebot, das die Kriterien am besten erfüllt.

3. Das offene Verfahren ist bei jedem Auftragswert möglich. Es verläuft wie das Einladungsverfahren, aber der Auftrag wird öffentlich ausgeschrieben und jedermann kann ein Angebot einreichen.

4. Das selektive Verfahren (zweistufiges Verfahren) ist auch bei jedem Auftragswert möglich. Wie das offene Verfahren, aber Vergabestelle wählt in einem Zwischenschritt die geeignetsten Anbieter aus und lässt nur diese zur Angebotsabgabe zu. Quelle: Skript Thomas Fischer KAIO



10

Kriterien zur Bestimmung der Verfahrensart > Zeitbedarf

> Bearbeitungsaufwand intern / extern

> Einschränkbarkeit der Anzahl zu prüfender Angebote

> Beschwerderisiken

> Akzeptanz bei Nichtberücksichtigung

> Kenntnisse des Marktes bzw. der potenziellen Anbietenden

> Aufwand für die Anbietenden

> Planbarkeit, Führbarkeit

Quelle: Leitfaden Beschaffung Kanton Bern



11

Schwellenwerte beim Bund

Bau

WTO

WTO (nur gewisse DL)

WTO (ohne Militär)

Dienstleistungen Güter

Ausschreibung / Rechtsschutz

Einladung

Freihändig

Ausschreibung 8.7 Mio*

2 Mio

230’000** 230’000**

150’000 150’000

50’000

*SBB: 8 Mio **SBB: 640’000




12

Schwellenwerte im Kanton Bern

> Kanton, kantonale Anstalten, öffentlich-rechtliche Körperschaften mit kantonaler Beteiligung > Wasser-, Energie- und Verkehrsversorgung, Abwasser- und Abfallentsorgung, Telekommunikation +

kantonale Beherrschung und/oder Konzessionierung > Private, die mit mehr als 50% vom Kanton und/oder Bund subventioniert werden

(Ausnahme: überwiegende kommunale Subventionen)

Quelle: Leitfaden für die Vergabe von öffentlichen Aufträgen im Kanton Bern, August 2013



13

Grundauftrag und Option

…. wird grundsätzlich wie vereinbart bezogen

… wird nur bei Bedarf bezogen (keine Bezugs-pflicht!)

Grundauftrag Option

2‘000 Stunden bis Ende 2017 500 Stunden bis Mitte 2018

> Massgebend für den Beschaffungswert sind Grundauftrag + Option. > Grundauftrag + Option sind in den Ausschreibungsunterlagen

abzubilden. > Optionen können in inhaltlicher und/oder in zeitlicher Hinsicht

vorgesehen werden. Quelle: Schulungsunterlagen Bundesamt für Bauten und Logistik BBL



14

Lose und Teilangebote

Los 1

Los 2 Los 3

Los 4

Lose Teilangebote

Teil-angebot

> Die einzelnen Lose und die jeweiligen Vergabebedingungen sind in der Ausschreibung bekannt zu geben.

> Lose können zum Beispiel nach Art oder Fachgebiet sowie räumlich oder mengenmässig aufgeteilten Leistungen gebildet werden. Quelle: Schulungsunterlagen Bundesamt für Bauten und Logistik BBL



15

Beschwerdeverfahren




16

Nicht der Billigste gewinnt, sondern das wirtschaftlich günstigste Angebot

Evaluation erfolgt durch die > Bewertung der einzelnen Zuschlags-/Qualitätskriterien:

— Punkte für jedes Zuschlags-/Qualitätskriterium — Gewichtung der einzelnen Kriterien untereinander

> Bewertung der Preiselemente: — Bewertung der einzelnen Preiselemente oder des Gesamt-

preises (Kauf, Wartung, Dienstleistungen, Optionen, etc.)

> sowie die Gewichtung des Preises im Verhältnis zu den Zuschlags- / Qualitätskriterien

⇒ Zuschlag erhält das Angebot, das die meisten Punkte (Qualität und Preis) erreicht = wirtschaftlich günstigstes Angebot Quelle: Schulungsunterlagen Bundesamt für Bauten und Logistik BBL



17

Eignungs- vs. Zuschlagskriterien

> Eignungskriterien (EK) messen die Eignung des Anbieters, den Auftrag auszuführen. Beispiele: — Erfahrung im fraglichen Tätigkeitsbereich, Referenzen — Verfügbarkeit von genügend ausgebildetem Supportpersonal — Finanzielle Stabilität (gemäss den Kennzahlen im Geschäftsbericht)

> Technische Spezifikation (TS) sind MUSS-Anforderungen an das Angebot

> Zuschlagskriterien (ZK) messen das Mass, in dem die angebotene Leistung das Bedürfnis der Vergabestelle befriedigt.

Quelle: Skript Thomas Fischer KAIO



18

Eigenschaften der Kriterien

EK, TS und ZK müssen…

> sachbezogen sein. — D.h. in einem rationalen Zusammenhang zum Beschaffungsgegen-

stand stehen: Unsinnige oder sachfremde Kriterien (z. B. „nur Unternehmen mit weniger als 100 Angestellten“) sind unzulässig.

> die Grundsätze des Beschaffungsrechts nicht verletzen. — Z.B. diskriminierende Kriterien („nur Schweizer Anbieter“) sind

verboten.

> einigermassen klar und objektiv beurteilbar sein. — Zu vage Kriterien („Gesamteindruck“, „Qualität“) sind willkürlich.

Akzeptabel sind eher subjektive Kriterien allenfalls bei Leistungen mit künstlerischem oder ästhetischem Charakter.

Quelle: Skript Thomas Fischer KAIO



19

Bewertung des Preises: Linear-ungekürztes Preismodell

> Der Anbieter mit dem tiefsten Preis erhält die Maximalpunktzahl. Der Anbieter mit dem höchsten Preis erhält 0 Punkte. Die Punktevergabe erfolgt linear.

> Beispiel: Maximalpunktezahl 1000 Punkte für den Preis Preis Anbieter 1: 100’000Fr. -> 667 Punkte Preis Anbieter 2: 75’000Fr. -> 833 Punkte Preis Anbieter 3: 50’000Fr. -> 1000 Punkte (tiefster Preis) Preis Anbieter 4: 200’000Fr. -> 0 Punkte (höchster Preis) Preis Anbieter 5: 150’000Fr. -> 333 Punkte

> Dieses Bewertungsmodell ist nicht zu empfehlen!




20

Problematik linear-ungekürztes Preismodell

Maximal 5000 Punkte für den Preis

— Lieferant A CHF 500‘000 5000 Punkte — Lieferant B CHF 510’000 2500 Punkte — Lieferant C CHF 520‘000 0 Punkte




21

Bewertung des Preises: Linear-gekürztes Preismodell

Bewertung der Kriterien mit Wertebereich: > Grundsätzlich erhält der jeweils beste Wert pro

Bewertungskriterium aller eingereichten Offerten die höchste Punktzahl (100%).

> Alle Werte, die in der Brandbreite von z.B. 50% liegen, erhalten Punkte (lineare Interpolation zwischen 100% und 150%).

> Alle Werte, die den besten Wert um mehr als 50% überschreiten, erhalten 0 Punkte (keine Minuspunkte für Überschreitung des Wertes von 50%).

( Pmax – P ) Punkte = M * ––––––––––– ( Pmax – Pmin )

M = Maximale Punktezahl P = Preis des zu bewertenden Angebots Pmin = Preis des tiefsten zulässigen Angebots Pmax = Preis, bei welchem die Preiskurve den Nullpunkt schneidet




22

Beispiel linear-gekürztes Preismodell

Maximal 5000 Punkte für den Preis Schnittpunkt CHF 750‘000 (150% des günstigsten Angebots)

— Lieferant A CHF 500‘000.00 5000 Punkte — Lieferant B CHF 510’000.00 4800 Punkte — Lieferant C CHF 520‘000.00 4600 Punkte




23

Unterschiedliche Preis-Bewertungsmodelle




24

Agenda




25

Ausschreibungsplattform simap.ch

http://www.simap.ch/



26



27

Auswahl der Voraussetzungen für das freihändige Verfahren (Art 13, Abs 1, VöB)

a) Im offenen oder selektiven Verfahren ging kein Angebot ein oder niemand erfüllt Eignungskriterien

b) Untereinander abgestimmte Angebote

c) Technische oder künstlerische Besonderheiten des Auftrages, Schutz des geistigen Eigentums, oder es gibt keine angemessene Alternative

d) Unvorhersehbare Ereignisse erfordern äusserste Dringlichkeit

e) […]

f) Zusätzliche Leistungen (Ergänzung, Erweiterung)

g) […]

Quelle: VöB http://www.admin.ch/opc/de/classified-compilation/19950538/index.html#a13

http://www.admin.ch/opc/de/classified-compilation/19950538/index.html#a13



28

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



29

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/



30

www.beschaffungsstatistik.ch



31

IT- und CT-Projekte auf simap.ch

Common Procurement Vocabulary (CPV) 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: > 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



32

Anzahl monatliche Zuschläge total

Quelle: Publikationen auf simap.ch

Durchschnitt: 455.75 Zuschläge / Monat seit 2015



33

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



34

Anzahl monatliche IT-Freihänder


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



35

Anteil monatliche Anzahl Freihänder zu Zuschläge insgesamt

Quelle: Publikationen auf simap.ch

Durchschnitt (seit 2015): 12.96% aller Zuschläge sind Freihänder



36

Anteil Anzahl IT-Freihänder zu IT-Vergaben


Durchschnitt (seit 2015): 40.45% aller IT-Zuschläge sind Freihänder



37

Fazit simap.ch Analyse

1. Steigende Anzahl Zuschläge 2. Anteil von nicht-IT-Freihändern beträgt durchschnittlich 12.96% 3. Anteil der nicht-IT-Freihänder ist tendenziell sinkend 4. 2/5 der IT-Zuschläge erfolgt freihändig (40.45%) 5. Tendenz der IT-Freihänder bei IT-Zuschläge weitgehend konstant Methodische Hinweise: > Zur Zeit auf Basis der Zuschläge, eigentlich sollte auf Basis Projekte berechnet werden > Zahlen umfassen Bundesverwaltung, Kantone, Gemeinden, öffentliche Betriebe etc. > Zahlen auf simap.ch sind nur die Spitze des Eisbergs > Wegen Optionen und fehlenden Preisangaben sind Beträge der Zuschläge ungenau

(deshalb ist Transparenz bei Verträgen entscheidend)



38

Noch nicht erfasst: «Offene» Produkte-Ausschreibungen



39

Hersteller- vs. Produkte-Abhängigkeit

Welche Abhängigkeiten gibt es in der Informatik? 1. Rechtliche Abhängigkeiten: Urheberrecht, Verträge,

Lizenzbedingungen 2. Knowhow-Abhängigkeiten: Wissen wie was zusammenhängt 3. Technische Abhängigkeiten: Schnittstellen, Datenformate etc. 4. Organisatorische Abhängigkeiten: Gewohnheiten der

Mitarbeitenden

Von wem/was ist die Behörde tatsächlich abhängig? > Software-Produkt: Knowhow-Abhängigkeiten,

technische Abhängigkeiten, organisatorische Abhängigkeiten > Hersteller: rechtliche Abhängigkeiten, psychologische Abhängigkeiten



40

Ein Löungsansatz: Einsatz von Open Source Software

Open Source Software Proprietäre Software

Kunde

Produkt

Kunde

Produkt

Anbieter Anbieter Anbieter

Anbieter

Abhängigkeit Abhängigkeit

Abhängigkeit Wechsel möglich



41

Agenda




42

Historische Entwicklung

> 1983 gründet Richard Stallman das GNU (GNU’s Not Unix) Projekt: Entwicklung eines freien, UNIX-ähnlichen Betriebssystem

> 1985 Gründung der gemeinnützigen Stiftung Free Software Foundation (FSF)

> 1989 die GNU General Public License (GNU GPL)

> 1991 zweite Version der GNU GPL (GPLv2)

> 1991 GNU Library General Public License (GNU LGPL)

> 2007 Veröffentlichung GPLv3

Richard Stallman, Gründer der Free Software Foundation und Hauptautor der GNU GPL



43

Free Software

Definition von Freier Software:

> Freiheit 0: Das Programm zu jedem Zweck auszuführen. > Freiheit 1: Das Programm zu untersuchen und zu verändern. > Freiheit 2: Das Programm zu verbreiten. > Freiheit 3: Das Programm zu verbessern und diese

Verbesserungen zu verbreiten, um damit einen Nutzen für die Gemeinschaft zu erzeugen.



44

Open Source Software

Was ist 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. Eine Open Source Lizenz beinhaltet immer folgendes: 1. Die Software darf beliebig eingesetzt werden. 2. Der Quelltext der Software ist zugänglich. 3. Die Software darf beliebig kopiert und verbreitet werden. 4. Die 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/

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
















45

Häufige Missverständnisse

> „Open Source ist gratis.“ Ja im Sinne des Lizenzpreises, Nein beim professionellen Betrieb.

> „Für Open Source Software gibt es keinen Support.“ Falsch, weltweit gibt es tausende von Open Source Dienstleistern und in der Schweiz listet www.ossdirectory.ch aktuell 159 Firmen.

> „Niemand haftet für Fehler in Open Source Software.“ Falsch, mit Service Level Agreement (SLA) oder Subscription von einem Open Source Anbieter kann Haftung und Gewährleistung von Open Source Produkten sichergestellt werden.

> „Meine Entwicklungen muss ich immer allen freigeben.“ Nein, nur bei AGPL, GPL und LGPL Code und auch dann nur an denjenigen, der das Binary erhält.



46

Open Source Lizenzen

Drei Kategorien von Open Source Lizenzen > Starkes Copyleft: Affero GPL, GNU General Public License GPL > Schwaches Copyleft: GNU Lesser General Public License und

Mozilla Public License MPL > Permissive Lizenzen: Berkley Software Distribution BSD, MIT

License, Apache Software License Dual Licensing > Urheber kann Software beliebig lizenzieren > Veröffentlichung identischer Software unter zwei unterschiedlichen

Lizenzen, typischerweise GPL und eine proprietäre Lizenz > Z.B. MySQL, Magnolia, Asterisk, Qt, Berkley DB



47

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»



48

Open Source Lizenzen





49

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


















50

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



51

Hohe Modularität



52

Weniger 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

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



53

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

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



54

Forking von Open Source Projekten

> Versagen der Communitiy Governance > Abspaltung eines Teils der Community in neuen Entwicklungszweig > Damoklesschwert des Open Source Entwicklungsmodells

Forking-Beispiele:



55

Fork-Beispiel Apache OpenOffice/LibreOffice

Jonas Gamalielsson, Björn Lundell: Sustainability of Open Source software communities beyond a fork: How and why has the LibreOffice project evolved? Journal of Systems and Software 2014 Figure: Number of committers (number in area) and commits per committer (color of area) for different project combinations



56

Informationsplattform zu Open Source



57

OSS Directory



58

OSS Firma



59

OSS Referenz



60

OSS Produkt



61

Open Source Studie Schweiz 2015

> Alle 3 Jahre im Auftrag von swissICT und CH Open

> Ausgeführt durch Forschungsstelle Digitale Nachhaltigkeit Universität Bern

> 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: http://www.ch-open.ch/oss2015

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



62

Einsatzgründe für Open Source Software



63

Hinderungsgründe beim Einsatz



64

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

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/



65

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

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










66

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










67

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/



68

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



69

Agenda




70

Total Cost of Ownership (TCO)

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
















71

Beispiel einer TCO-Berechnung

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




72

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



73

PostgreSQL vs. Oracle

Quelle: http://www.enterprisedb.com/products-services-training/products/postgres-plus-advanced-server/advanced-server-tco

http://www.enterprisedb.com/products-services-training/products/postgres-plus-advanced-server/advanced-server-tco


















74

alternativeTo www.alternativeto.net



75

LibreOffice www.libreoffice.org



76

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



77

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



78

Nantes migriert zu LibreOffice und zahlt EUR 200’000 für Weiterentwicklung

Quelle: https://joinup.ec.europa.eu/node/150244

https://joinup.ec.europa.eu/node/150244



79

Kleine Features erweitern auf www.bountysource.com



80

Collective Action Problem lösen

> Übliche Probleme bei OSS:

— Wichtige Features fehlen

— Benutzerfreundlichkeit ungenügend

— Schulungs- und Marketingmaterial nicht professionell

> Alle brauchen das, aber kein Anwender ist bereit, alleine grosse Investitionen in ein OSS Produkt zu tätigen

> Bündelung der Ressourcen ermöglicht grössere Programmierungen und andere Arbeiten

> Kritische Masse durch Zusammenschluss von wichtigen institutionellen Anwendern schaffen



81

Gemeinsame Weiterentwicklung von Open Source Software

Varianten: > Erweiterung einer bestehenden Open Source Lösung > 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 Firmen die Dienstleistungen dafür anbieten



82

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 140’000 exkl. MWSt.

> 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












83

Finanzierung



84

OpenLayers 3 Co-Finanzierung durch swisstopo

Quelle: https://www.ch-open.ch/fileadmin/user_upload/events/sikossforum2014/06-C-Moullet-OpenLayers.pdf

https://www.ch-open.ch/fileadmin/user_upload/events/sikossforum2014/06-C-Moullet-OpenLayers.pdf



85

E-Government Lösung CAMAC

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

http://www.camac.ch/



86

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



87

Agenda




88

BBL Merkblatt «Software-Ausschreibungen»

«Software-Ausschreibungen: Sicherstellung eines breiten Wettbewerbs»

Quelle: https://www.bkb.admin.ch/dam/bkb/de/dokumente/Hilfsmittel/Merkblaetter/13_Merkblatt_Software_Ausschreibungen_inkl_%20IT_ABG_und_Pflichtenheftbeilage.pdf.download.pdf/13_Merkblatt_Software_Ausschreibungen_inkl_%20IT_ABG_und_Pflichtenheftbeilage.pdf

https://www.bkb.admin.ch/dam/bkb/de/dokumente/Hilfsmittel/Merkblaetter/13_Merkblatt_Software_Ausschreibungen_inkl_%20IT_ABG_und_Pflichtenheftbeilage.pdf.download.pdf/13_Merkblatt_Software_Ausschreibungen_inkl_%20IT_ABG_und_Pflichtenheftbeilage.pdf







89


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



90


Aussagen zu Open Source Software:

> Die OSS-Lizenz allein kostet die beschaffende Stelle in der Regel nichts und ist für sich allein daher auch nicht beschaffungsrelevant.

> Kosten und damit Beschaffungsrelevanz entstehen erst, wenn bei einem Anbieter Dienstleistungen (bspw. Beratung, Integration, Anpassungen, Schulungen, Weiterentwicklung, Betrieb, Wartung etc.) für bestimmte OSS eingekauft werden oder OSS zusammen mit andern, kostenpflichtigen Software- Komponenten und/oder Dienstleistungen eingekauft wird.



91

«SIK Checkliste für Beschaffung von Open Source»

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

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

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

Quelle: http://www.ossdirectory.com/oss-knowhow/details/kbarticle/sik-checkliste-fuer-beschaffung-von-open-source-software/

http://www.ossdirectory.com/oss-knowhow/details/kbarticle/sik-checkliste-fuer-beschaffung-von-open-source-software/




















92

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/



93

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



94

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



95

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:



96


> 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



97


> 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



98


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



99

Ausblick

Quelle: http://www.itbeschaffungskonferenz.unibe.ch

http://www.itbeschaffungskonferenz.unibe.ch/



100

Ausblick

Quelle: http://cas-ictbeschaffungen.unibe.ch

http://cas-ictbeschaffungen.unibe.ch/






101

Danke für Ihre Aufmerksamkeit!

> Für weitere Anliegen rund um E-Government, ICT-Beschaffungen, Open Source Software, Open Government Data, Linked Data etc.:

Dr. Matthias Stürmer Oberassistent, Leiter Forschungsstelle Digitale Nachhaltigkeit Universität Bern Institut für Wirtschaftsinformatik Raum 309 (3. Stock) 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


