Präsentation openCode Connect März 2025 | OSBA
0 gefällt mir341 aufrufe
Slides zur openCode Connect Veranstaltung mit OSBA, März 2025.
Präsentation openCode Connect März 2025 | OSBA
- 1. Vergabekriterien für die erfolgreiche Beschaffung von Open Source Software Die Auswahl des passenden Anbieters Claus R. Wickinghoff Sprecher der OSBA Working Group Beschaffung Disclaimer: Dies ist keine Rechtsberatung. openCode Connect / 20. März 2025
- 2. Die Open Source Business Alliance
- 3. Aus der Praxis (1) ● Erfahrung eines Herstellers von Open Source Software: “Konkretes Beispiel: Ein Bundesland hat sich entschieden, für die Schüler aller Schulen unsere Software auszuschreiben. Das haben Unternehmen x und Unternehmen y gewonnen, beide haben vorher noch nie etwas mit unserer Software gemacht. Wir haben uns selbst auch an der Ausschreibung beteiligt, das Bundesland hatte sehr hohe Anforderungen mit harten Kriterien zu Performance und anderen Sachen. Hierzu haben wir uns intern sehr viele Gedanken gemacht, ob und wie man das erfüllen kann. Unternehmen x und Unternehmen y haben die Ausschreibung mit Dumpingpreisen gewonnen und sich im Nachhinein bei uns gemeldet, ob wir das Consulting für Skalierung & Performanceprobleme machen können. Wir haben das abgelehnt und auf unsere normale Subskription verwiesen, für die aber kein Budget mehr vorhanden war."
- 4. Aus der Praxis (2) ● Erfahrung eines anderen Anbieters von Open Source Software: “Vor anderthalb Jahren hat mir der CIO eines Bundeslandes zum Deal für die Videoarbeitsplätze mit unserer Software gratuliert und geschwärmt, dass er ein großer Open-Source-Verfechter sei. Ich wusste zuerst nicht, wovon er sprach und dann stellte sich heraus, das das Unternehmen z mit unserer Software eine Ausschreibung gewonnen hat. Letztlich haben sie damit einen Dritten beauftragt, unsere Software zu forken und mit entsprechendem Wissen um die Anforderungen in dem Bundesland Anpassungen zu Accessibility und anderem vorzunehmen. Der CIO hat gedacht, das wäre super für Open Source - aber das, was da für viel Geld für das Bundesland entwickelt wurde, ist nun alles Closed Source. Das Bizarre ist, dass ein Bundesministerium jetzt erneut viel Geld in Accessibility investiert, obwohl Unternehmen z diese gleichen Funktionen ja bereits mit Steuergeldern für das Bundesland entwickelt hat. Aber diese Weiterentwicklungen sind eben nicht Open Source.“
- 5. Was genau wird eigentlich beschafft ? ● Open Source Software ist lizenzkostenfrei. ● Nutzerlizenzen sind also üblicherweise nicht Teil einer Ausschreibung. ● Ausgeschrieben werden daher Service und Dienstleistung. ● Erinnerung: Bei proprietärer Software partizipiert der Hersteller an jeder verkauften Lizenz seiner Software.
- 6. Fazit ● Werden Leistungen der öffentlichen Hand allein oder in erster Linie nach Preis vergeben, benachteiligt dies Bewerber/Bieter, die in Pflege, Sicherheit und Aktualisierung der Software investieren und die Lieferkette mit Supportverträgen absichern. ● Eine schlechte Umsetzung sollte eigentlich auf den Anbieter zurückfallen, nicht auf das Projekt bzw. den Hersteller.
- 7. Möglichkeiten bei der Beschaffung ● Grundsätzlich sollte der Zuschlag für das wirtschaftlichste Angebot erfolgen. Das ist jedoch schwierig, wenn die Software (und deren Weiterentwicklung) nicht Teil der Ausschreibung ist. ● Die UfAB*) zeigt in Abschnitt 4.2.1 Möglichkeiten auf, nicht nur den Preis als Entscheidungskriterium heranzuziehen. Dazu nennt sie in 5.4 konkret auch die Nachhaltigkeit als Aspekt. *) UfAB = Unterlage für Ausschreibung und Bewertung von IT-Leistungen
- 8. 4 Kriterien zur Auswahl eines nachhaltigen Anbieters ● Beziehung zum Software-Hersteller / der Community ● Sicherstellung der Upstream-Veröffentlichung vorgenommener Anpassungen und Patches ● Sicherstellen einen qualifiziertes 3rd-Level-Supports ● Absicherung der Lieferkette durch Unterstützung von Basiskomponenten
- 9. Beziehung zu einem kommerziellen Hersteller Der Anbieter kann u.a. einen Vertrag mit dem Softwarehersteller nachweisen und darlegen, welche Leistungen durch diesen Vertrag abgedeckt werden. Eine enge Zusammenarbeit gewährleistet direkten Zugang zu technischem Support und den neuesten Software-Updates. Dies verbessert die Betriebssicherheit und hilft mit frühzeitigem Wissen über potenzielle Sicherheitslücken, um das Risiko von Sicherheitsverletzungen zu minimieren.
- 10. Beziehung zu einer Community Der Anbieter kann u.a. nachweisen, dass er ● bereits Contributions zu der entsprechenden Software (erfolgreiche Merges etc.) geleistet hat ● Core-Contributoren der entsprechenden Software im eigenen Unternehmen beschäftigt ● an Veröffentlichungen zu der entsprechenden Software mitgewirkt hat (zu Neuentwicklungen, Dokumentation, Schulungsmaterialien, Absicherung der Lieferkette o.ä.)
- 11. Sicherstellung der Upstream-Veröffentlichung ● Der Anbieter kann Commitrechte im Projekt nachweisen und/oder ist Certified Contributor. ● Der Anbieter beschäftigt einen oder mehrere Core- Entwickler des Projekts. ● Der Anbieter hat eine aktive Partnerschaft mit dem Hersteller der Software und maßgeblichen Einfluss auf die Entwicklung der Software (z.B. Einreichung von Feature- Requests, Beteiligung an der Priorisierung von Bugfixes, usw.).
- 12. Sicherstellen einen qualifiziertes 3rd-Level-Supports ● Der Anbieter kann vertraglich sicherstellen, dass Third-Level Support durch den entsprechenden Hersteller geleistet wird. ● Der Anbieter kann nachweisen, dass er Entwickler mit Commitrechten oder Core-Entwickler der entsprechenden Software beschäftigt. ● Der Anbieter kann nachweisen, dass er in den letzten Jahren regelmäßig Bugfixes an der entsprechenden Software durchgeführt hat (z.B. mit Link o.ä. auf die entsprechenden Fixes).
- 13. Sicherung der Lieferkette ● Der Anbieter beschäftigt Core-Entwickler eines externen Projekts oder einer Basiskomponente, die Teil der Lieferkette sind. ● Der Anbieter unterstützt mit seinen Beiträgen zu einer Basiskomponente oder einem externen Projekt beispielsweise bei der Umsetzung der im CRA geforderten Anforderungen und Dokumentationspflichten.
- 14. Beispiel: Upstream-Veröffentlichung als B-Kriterium Punkteskala: ● 0 Punkte: Keine Angaben oder keine qualifizierenden Angaben des Bieters ● 1 Punkt: Bieter kann generell eigenes Entwickler-Personal nachweisen ● 2 Punkte: Bieter legt konzeptionell dar, dass und wie Entwicklungen upstream einfließen ● 3 Punkte: Bieter legt dar, dass er bereits relevanten eigenen Code zum Projekt beigetragen hat ● 4 Punkte: Bieter kann Commitrechte im Projekt nachweisen und/oder ist Certified Contri butor ● 5 Punkte: Bieter beschäftigt einen oder mehrere Core-Entwickler des Projekts
- 15. Verwendung der Kriterien in einer Ausschreibung Gemäß UfAB können die Kritierien jeweils nach Bedarf als A- oder B-Kriterium formuliert werden: ● A-Kriterium ist ein Eignungskriterium ● B-Kriterium ist ein Wertungskriterium und liefert mit dem Preis eine Kennzahl Z = Leistung / Preis (UfAB 4.2.3) Festlegung der Kriterien kann/sollte auf die Ausschreibung angepasst werden. Rückmeldungen und weitere Vorschläge gerne erwünscht!