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)
Oberassistent,
Leiter Forschungsstelle
Digitale Nachhaltigkeit
Universität Bern
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
matthias.stuermer@iwi.unibe.ch
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.

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.

14
Lose und Teilangebote
Los 1
Los 2Los 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.

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

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.

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.

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 3: 50’000Fr. -> 1000 Punkte (tiefster Preis)
Preis Anbieter 4: 200’000Fr. -> 0 Punkte (höchster Preis)
> 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

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

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

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

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

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

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

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/

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

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

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/

68
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: www.openhub.net
> Open Source Alternativen: www.alternativeto.net
> Auswahl von OSS Programmen für Windows (in deutsch):
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

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

73
PostgreSQL vs. Oracle
Quelle: 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

78
Nantes migriert zu LibreOffice und zahlt
EUR 200’000 für Weiterentwicklung
Quelle: 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
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

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

85
E-Government Lösung CAMAC
> Open Source Baugesuchsverwaltung von 8 Schweizer Kantonen
> 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_Pfli
chtenheftbeilage.pdf.download.pdf/13_Merkblatt_Software_Ausschreibungen_inkl_%20IT_ABG_und_Pflichtenheftbeilage.pdf

89
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

90
BBL Merkblatt
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/

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

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

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

100
Ausblick
Quelle: 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.:
Oberassistent, Leiter Forschungsstelle Digitale Nachhaltigkeit
Universität Bern
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
matthias.stuermer@iwi.unibe.ch

IT-Beschaffung und Open Source Software

Weitere ähnliche Inhalte

Was ist angesagt? (20)

Andere mochten auch (20)

Ähnlich wie IT-Beschaffung und Open Source Software (20)

Mehr von Matthias Stürmer (19)

IT-Beschaffung und Open Source Software