Themen: Beschaffungen, Open Source

SIK_Checkliste_fuer_Beschaffung_von_Open_Source_Software_V10_de (PDF, 63kB)

SIK Arbeitsgruppe OSS, 18. August 2015, Version 1.0

Die vorliegende Checkliste ist ein Hilfsinstrument für Beschaffungsstellen, welche die rechtskonforme Beschaffung von Open Source Software sicherstellen und Angebote von Open Source Dienstleistern ermöglichen wollen. Die Checkliste enthält Fragen mit entsprechenden Erläuterungen, die bei der Vorbereitung einer ICT-Ausschreibung berücksichtigt werden können.

1. Voranalyse/Konzeption

Ist genügend Verständnis über das Open Source Entwicklungsmodell vorhanden?

Anders als bei proprietärer Software werden bei Open Source Software nicht Lizenzen beschafft, sondern Dienstleistungen und/oder Subskriptionen für bestimmte Open Source Lösungen. Dementsprechend sind auch die Geschäftsmodelle von Open Source Herstellern und Dienstleistern ausgelegt, dass sie konkrete Leistungen wie Support (Service Level Agreements), Wartung, Gewährleistung/Garantien, Anpassungen, Integration, Betrieb, Schulung etc. für die Open Source Lösungen anbieten. Diesem Umstand sollte bereits bei der Vorbereitung der Ausschreibung Rechnung getragen werden.

Sind bestehende Open Source Lösungen geprüft worden?

Der Einsatz von Open Source Software ohne Leistungen einer Firma ist aus beschaffungsrechtlicher Sicht nicht relevant und kann somit ohne öffentliche Ausschreibung stattfinden. In Verzeichnissen wie dem OSS Directory oder alternativeTo kann recherchiert werden, welche Open Source Lösungen für welchen Anwendungsbereich (CMS, DMS, Application Server, Fachapplikation etc.) verfügbar ist.

Welcher Funktionsumfang wird tatsächlich benötigt?

Es besteht eine Tendenz zur Beschaffung von einem zu hohen Leistungsumfang, der in der Realität nicht benötigt wird. Beispielsweise könnte anstelle von einer bestimmten proprietären Datenbank auch MariaDB oder PostgreSQL eingesetzt werden. Wird eine Software-Lösung mit zu hohen Leistungen beschafft, werden Kosten von Funktionalitäten bezahlt, die gar nie benötigt werden.

2. Kriterien die verhindern, dass Open Source ausgeschlossen wird

Sind die Beschaffungsunterlagen funktional verfasst, ohne Vorgabe von proprietären Produkten?

Die Vorgabe von bestimmten proprietären Produkten (z.B. Microsoft Sharepoint), Plattformen (SAP), Internet-Browsern oder Schnittstellen von bestimmten Herstellern kann dazu führen, dass Anbieter von Open Source Lösungen von vornherein ausgeschlossen sind. Damit werden bestehende Abhängigkeiten verstärkt, Monopolstellungen gefördert und letztlich Wettbewerb und Innovation eingeschränkt und damit Informatikkosten langfristig erhöht. Umgekehrt kann es gute Gründe geben, eine Ausschreibung auf eine bestimmte öffentlich verfügbare Open Source Lösung einzugrenzen. Gemäss Definition können beliebige Hersteller für solche Open Source Systeme ihre Dienstleistungen anbieten was den Wettbewerb nicht behindert, sondern im Gegenteil fördert. Wichtig ist, diese Eingrenzung auf eine vorgegebene Open Source Lösung stichhaltig begründen zu können.

Besteht ein Hinweis, dass auch Open Source Software angeboten werden kann?

Die AGBs von Bund und SIK behindern die Beschaffung von Open Source nicht. Damit dies auch allen Open Source Anbietern klar ist, ist ein Hinweis in den Ausschreibungsunterlagen empfohlen, dass auch Open Source Lösungen angeboten werden können.

Sind Subunternehmer und Bietergemeinschaften zugelassen?

Viele der guten Open Source Entwickler sind selbständig oder in kleinen Firmen tätig. Deshalb sollten Ausschreibungen ermöglichen, dass sich Open Source Anbieter zusammenschliessen und als Subunternehmer eines grösseren Anbieters (der z.B. als Generalunternehmer) oder als Konsortium gemeinsam anbieten. Die einheitliche Koordination kann bspw. über einen Single Point of Contact definiert werden, der bei einem der Anbieter liegt.

Sind Firmengrösse und Referenzen nicht unnötig hoch vorgegeben?

Open Source Anbieter sind tendenziell kleiner als Hersteller von proprietärer Software. Auch sind Open Source Lösungen aus Gründen der Abhängigkeiten zu proprietären Produkten oftmals noch wenig verbreitet. Um Open Source Anbieter nicht von indirekt auszuschliessen sollten deshalb bei den Eignungskriterien nicht unnötig hohe Anforderungen an Firmengrösse, Mitarbeiterzahl, Referenzen, installierte Versionen etc. gestellt werden. Letztlich ist auch bei grossen Unternehmen immer nur ein kleiner Kreis von Mitarbeitenden für ein Projekt zuständig. Zudem ist bei Grossunternehmen die Mitarbeiterfluktuation meist höher und die Identifikation mit der Arbeit und den Kunden oftmals niedriger als bei kleineren Firmen. Diese Gründe sprechen generell für kleinere Anbieter, weshalb es Sinn macht, diese nicht auszuschliessen.

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

Wird die Lieferung der Software unter einer Open Source Lizenz in der technischen Spezifikation (TS) vorgegeben bzw. wird Open Source als Zuschlagskriterium (ZK) bemessen?

Open Source Software gewährt durch ihre Lizenzbestimmungen wesentliche Nutzungs- und Entwicklungsmöglichkeiten, die bei proprietärer Software ausgeschlossen sind. Einerseits dürfen Open Source Lösungen uneingeschränkt und kostenlos verwendet und vervielfältigt werden. Der Einsatz von Open Source Software skaliert rechtlich gesehen beliebig ohne finanzielle Folgen, unabhängig davon, wie viele Arbeitsplätze oder Server die Software nutzen. Andererseits erlauben Open Source Lizenzen den vollständigen Zugang zum Quellcode und das Recht diesen zu verändern. Damit erhält der Nutzer die Möglichkeit selber oder im Auftrag an Dritte die Software zu auditieren, korrigieren, anzupassen und weiterzuentwickeln. Aus diesen Gründen macht es Sinn und ist erlaubt, die positiven Eigenschaften von Open Source Software als ZK zu bewerten oder Nutzungseigenschaften unter einer Open Source Lizenz gar als TS vorzuschreiben.

Werden „Open Source Kompetenzen“ des Anbieters als Eignungskriterium vorgegeben?

Wenn ein Leistungsbezüger bewusst eine Open Source Lösung beschaffen will oder bereits eine solche besitzt und Dienstleistungen dazu sucht, kann es Sinn machen, dass „Open Source Kompetenzen“ des Anbieters als Eignungskriterium vorgegeben – oder im Fall eines selektiven Verfahrens bewertet – werden.

Besteht Zugang zum vollständigen Quellcode der offerierten Software-Lösung?

Es ist einerseits aus Sicherheits- und Datenschutzsicht wichtig, dass die Anbieter den vollständigen Quellcode für Audit-Möglichkeiten dem Leistungsbezüger zur Ansicht zur Verfügung stellen. Dadurch besteht die Möglichkeit, dass Software-Entwickler der Quellcode nach möglichen Backdoors zur NSA etc. untersuchen können. Andererseits macht es auch aus Software-Qualitätsgründen Sinn, Zugang zum Quellcode sicherzustellen um bspw. die Code-Qualität oder die Dokumentation des Quellcodes prüfen zu können. Bei Open Source Software ist der voll- ständige Zugang zum Quellcode per Definition gewährleistet, bei proprietärer Software normalerweise nicht oder nicht vollständig.

Werden in der Ausschreibung die Kosten der IT-Lösung über ihren gesamten Lebenszyklus bemessen? (Total Cost of Ownership – TCO)

Oftmals ist Open Source Software teurer in der Einführung als das Upgrade der bisherigen proprietären Software, da technische und personelle Veränderungen (Migration, Anpassungen, Umschulungen etc.) nötig sind. Wird jedoch der gesamte Lebenszyklus einer IT-Lösung betrachtet, sind Betriebs- und Wartungskosten wesentlich höher als Beschaffungs- und Einführungskosten. Die Betriebsdauer von IT-Lösungen ist durchschnittlich rund 3x höher ist als die Projektdauer. Da bei Open Source Software keine wiederkehrenden Lizenzkosten anfallen, der Anbieter relativ rasch gewechselt werden kann und dank offenen Standards kaum Exit-Kosten entstehen, sind Open Source basierte Lösungen langfristig meistens günstiger. In der Ausschreibung sollte deshalb immer die gesamte Lebensdauer einer IT-Lösung berücksichtigt werden.

Wird das Risiko eines Konkurses bei proprietären Lösungen bemessen?

Geht der Hersteller von proprietärer Software Konkurs, fallen die Rechte am Quellcode in die Konkursmasse. Die Nutzer der proprietären Software sind einer ungewissen Zukunft ausgesetzt. Bei Open Source Software kann ein anderer Dienstleister mit der Weiterentwicklung des Systems beauftragt werden, da der Leistungsbezüger umfassende Nutzungsrechte besitzt.

Werden auch Referenzinstallationen von Open Source Lösungen berücksichtigt, die nicht vom Anbieter selber realisiert wurden?

Es kann als Zuschlagskriterium vorgegeben werden auszuweisen, wie viele Instanzen der angebotenen Open Source Lösungen bereits öffentlich bekannt im Einsatz stehen. Dies bemisst zwar nicht die Kompetenz des Anbieters, aber gibt dennoch einen Verbreitungsgrad der angebotenen Open Source Lösung an, denn diese könnte auch intern realisiert worden sein.

Wird die Aktivität einer Open Source Community berücksichtigt?

Eine Open Source Lösung kann eine mehr oder weniger aktive Community von Entwicklern und Dienstleistern haben. Für die nachhaltige Weiterentwicklung eines Open Source Projekts ist es deshalb entscheidend, dass eine möglichst aktive und heterogene Community vorhanden ist. Die Informationsplattform Open HUB (www.openhub.net) gibt die Aktivität von rund 700‘000 Open Source Projekten tagesaktuell und sehr feingranular bekannt.

Wird die Verfügbarkeit von Dienstleistern einer Open Source Lösung geprüft?

Für die langfristige Weiterentwicklung und einen möglichen Anbieterwechsel ist eine breite Dienstleister-Community wichtig. Es sollte deshalb als Zuschlagskriterium berücksichtigt werden, wie viele kommerzielle Dienstleister für eine bestimmte Open Source Lösung vorhanden sind.