Leitfaden für Praktiker: Beurteilung der Realisierbarkeit

Falls Sie das noch nicht gelesen haben Leitfaden für Praktiker: Einführung – Woran Sie bei der Interpretation von Kennzahlen denken solltenBitte halten Sie jetzt inne und lesen Sie diesen Leitfaden.

Zielgruppe / Umfang

Dieser Leitfaden richtet sich in erster Linie an Open Source Program Offices (OSPOs) und andere Teams innerhalb von Organisationen, die die Realisierbarkeit und die Risiken der von ihnen genutzten Open-Source-Software verstehen müssen.

Einführung

Open-Source-Software findet sich in 97 % aller Codebasen (Black Duck 2025), doch wie bei den meisten Programmen variiert die Qualität stark und manche Open-Source-Projekte sind langfristig rentabler als andere. Die Bewertung der Rentabilität und der Risiken, die mit der Teilnahme an bestimmten Open-Source-Projekten einhergehen, ist wichtig, um Unterbrechungen Ihrer Arbeit zu vermeiden, die die Bereitstellung von Produkten und Dienstleistungen für Kunden beeinträchtigen, insbesondere wenn eine wichtige Abhängigkeit plötzlich unrentabel wird. Es ist wichtig, Rentabilität und Risiko als Kontinuum zu betrachten, da Projekte in vielen Kategorien mehr oder weniger rentabel sind. Ob Sie ein Projekt annehmen und die damit verbundenen Risiken akzeptieren sollten, ist eine strategische Entscheidung, die von den Anforderungen Ihres Unternehmens und Ihren Anwendungsfällen für die zugehörigen Technologien abhängt. Die Bewertung der Rentabilität von Open-Source-Projekten, insbesondere solcher, die sich möglicherweise auf Ihr Geschäft auswirken, ist ein guter erster Schritt zum Risikomanagement und zur Verringerung der Wahrscheinlichkeit potenzieller Geschäftsunterbrechungen.

Unternehmen, die Open-Source-Software verwenden (d. h. alle von ihnen) haben sich immer mehr mit Stücklisten, Schwachstellen und Lizenzrisiken auseinandergesetzt. Dies wurde insbesondere durch die jüngsten Bemühungen der Vereinigten Staaten und der Cyber ​​Resilience Act (CRA) der EU bezüglich Software Bills of Material (SBOMs). Dieser Vorstoß ist eine gute Gelegenheit, Software-Lieferketten zu beobachten und darüber zu berichten. Wir alle können lernen, wenn wir wissen, was in unseren Software-Abhängigkeiten steckt! Verbreitung von SBOMs, SAST (Statisches Testen der Anwendungssicherheit) und SCA Scan-Tools (Software Composition Analysis) ermöglichen es Benutzern und Entwicklern von Software, ihr Risikoportfolio besser zu verstehen. Die meisten Anwender nutzen diese Berichte sehr gerne, um kritische Schwachstellen, Lizenzinformationen und andere Probleme aufzudecken, die die Rentabilität eines Open-Source-Projekts beeinträchtigen könnten.

Sicherheit kann ein wichtiger Faktor für die Realisierbarkeit eines Open-Source-Projekts sein. Die Sicherheit einer Softwarekomponente ist jedoch nur so gut wie die Sicherheit ihrer Abhängigkeiten. Daher muss die Beurteilung der Realisierbarkeit über das einzelne Projekt hinausgehen. Es ist wichtig zu beachten, dass beliebte Pakete gute Sicherheitspraktiken nicht mehr oder weniger wahrscheinlich befolgen (Imtiaz 2022). Dies geht über die bloße Auswahl der Abhängigkeiten hinaus und umfasst auch die Planung der Aktualisierung dieser Abhängigkeiten, da die Wahrscheinlichkeit von Sicherheitsproblemen bei Verwendung veralteter Abhängigkeiten viermal höher ist (Cox et al. 2015).

Sicherheit steht bei der Realisierbarkeit von Open-Source-Projekten zwar im Vordergrund, es gibt jedoch auch andere Faktoren, die berücksichtigt werden müssen. Die Projektsteuerung und die Zusammenarbeit der Community bei der Entwicklung der Software sind ebenfalls wichtig. Wir verfügen außerdem über einige Strategiekennzahlen zur Beurteilung der Realisierbarkeit eines Projekts. Dieser Leitfaden bietet Ratschläge zur Beurteilung der Realisierbarkeit in allen vier Kategorien: Compliance und Sicherheit, Governance, Community und Strategie.

Probleme

In vielen Unternehmen gibt es keinen strengen Prozess zur Auswahl langfristig tragfähiger Abhängigkeiten. Produktteams oder sogar einzelne Softwareentwickler entscheiden sich oft für Open-Source-Projekte, weil sie einen bestimmten technischen Bedarf decken, ohne die Realisierbarkeit des Projekts oder die damit verbundenen Risiken zu prüfen. Zu den herausfordernden Fragen zählen:

  • Worauf sollten wir bei der Auswahl unserer Open-Source-Software noch achten?
  • Welche Hinweise können wir geben, um gute Entscheidungen nicht nur bei der Softwarewartung zu fördern?
  • Sollten diese Leitlinien anders sein als bei der Entscheidung der Benutzer, welche Software sie verwenden?
  • Könnten wir Tools und Messgrößen zur Entscheidungsfindung bereitstellen?
  • Wie können wir bei unseren Entscheidungen weniger Risiken eingehen und eine nachhaltigere Software-Infrastruktur bereitstellen?

Teams, die technische Diskussionen steuern möchten, müssen sich oft auf bestehende Strukturen zur Sicherheits- oder Lizenzkonformität verlassen. Die größte Herausforderung für Fachexperten, die sich mit diesen Frameworks auseinandersetzen, ist der Mangel an Metriken und Systemen, um zu vermitteln, was bei der Auswahl einer Open-Source-Abhängigkeit sonst noch wichtig ist. Mithilfe von Viability können wir Messungen erstellen, die eine gründlichere Analyse von Softwareabhängigkeiten ermöglichen.

Lessons Learned

Wir haben in letzter Zeit eine Welle von Open-Source-Projekten einzelner Anbieter mit Contributor License Agreements (CLAs) erlebt, die auf restriktivere Lizenzen umlizenziert wurden. In einigen Fällen führte die Umlizenzierung zu einem Hard Fork des ursprünglichen Projekts. Beispiele hierfür sind Elasticsearch / OpenSearch, Terraform / OpenTofu und Redis / Valkey. Diese Umlizenzierungen und die daraus resultierenden Forks können für Unternehmen und Einzelpersonen, die die ursprünglichen Open-Source-Projekte nutzen, störend sein (Foster 2024). In diesem Fall stehen Unternehmen oft vor der Entscheidung, ob sie das Projekt unter der neuen Lizenz weiter nutzen können, eine Lizenzgebühr zahlen müssen oder ob sie auf eine andere Technologie (möglicherweise den Fork) umsteigen sollten.

Neben der Neulizenzierung können Unternehmen auch andere Geschäftsentscheidungen treffen, die dazu führen können, dass Mitarbeiter, die an einem Open-Source-Projekt arbeiten, nicht mehr finanziell unterstützt werden. Dies kann dazu führen, dass Projekte gleichzeitig eine große Anzahl von Betreuern verlieren (Egbahl 2016) und somit weniger rentabel werden. Avelino et al. (2019) stellten fest, dass selbst beliebte Projekte dauerhaft aufgegeben werden können. Wenn der Großteil der Arbeit von einer einzelnen Person oder wenigen Personen geleistet wird, erhöht sich das Risiko, dass ein Projekt unhaltbar wird, wenn diese Person(en) nicht mehr daran arbeiten.

In den letzten Jahren gab es mehrere spektakuläre Sicherheitslücken, die zeigten, wie fragwürdig die Zukunftsfähigkeit weit verbreiteter Projekte sein kann. Im Fall von OpenSSL erfuhren viele zum Zeitpunkt der Heartbleed-Sicherheitslücke, dass dieses weit verbreitete Projekt von zwei überarbeiteten und unterbezahlten Mitarbeitern betreut wurde, die mit der für OpenSSL erforderlichen Arbeit kaum Schritt halten konnten. Ein ähnliches Beispiel einige Jahre später mit dem XZ-Projekt zeigte, was passieren kann, wenn sich jemand in das Projekt einbringt und genügend wertvolle Beiträge leistet, um einen überarbeiteten Betreuer davon zu überzeugen, ihn an der Projektpflege mitarbeiten zu lassen, bevor er schließlich Schadcode einführt. Diese beiden Beispiele unterstreichen, wie wichtig es ist, die Zukunftsfähigkeit der von uns genutzten Open-Source-Projekte zu bewerten. Daher ermitteln wir den Contributor-Absence-Faktor, um zu verstehen, wie viele Betreuer – wie im Fall von XZ – die meisten Projektcode-Beiträge leisten. Wir können auch das Änderungsvolumen und dessen zeitliche Entwicklung analysieren, um zu erkennen, wann Projekte unter Komplexität und mangelnder Mitwirkung leiden – wie im Fall von OpenSSL.

Dies sind nur einige Beispiele dafür, wie Projekte mit der Zeit riskanter und weniger rentabel werden können. Durch eine vorherige Bewertung der Rentabilität kann sich ein Unternehmen möglicherweise gegen die Nutzung eines bestimmten Open-Source-Projekts entscheiden. In anderen Fällen kann sich ein Unternehmen für ein weniger rentables Projekt entscheiden, aber innerhalb des Projekts an der Verbesserung der Rentabilität arbeiten und so einige der bei der Bewertung identifizierten Risiken mindern.

Wie man Maßnahmen ergreift

Bei der Bewertung der Risiken eines Open-Source-Softwareprojekts liegt der Fokus häufig auf Sicherheitslücken und Lizenzierung. Es gibt jedoch viele weitere Bereiche, die ebenfalls berücksichtigt werden sollten. Die Viability Metrics Models von CHAOSS unterteilen die Machbarkeit in vier Hauptkategorien, wobei jede Kategorie zahlreiche Metriken enthält, sich jedoch teilweise überschneidet: Compliance und Sicherheit, Governance, Community, und Strategie.

Der Rest dieses Abschnitts behandelt die von uns verwendeten Kennzahlen und ihre Zusammenhänge. Wir haben zusammengefasst, welche Kennzahlen zu den einzelnen Kategorien gehören und geben einen Überblick über ihre Zusammenhänge. Wir gehen auch auf den Nutzen kategorienübergreifender Kennzahlen ein und geben Vorschläge für Maßnahmen und Abhilfemaßnahmen.

Compliance und Sicherheit

Die Abteilung für Compliance und Sicherheit bewertet die Lizenzierung, das Schwachstellenrisiko und die Wartungsaktivitäten eines Projekts. Es ist wichtig, dass Benutzer alle ihre Verpflichtungen gegenüber einer Organisation oder den Entwicklern eines Open-Source-Softwareprojekts erfüllen.

CHAOSS-Metriken:

Best Practices für OpenSSF

  • Dies ist eine Proxy-Metrik, die sicherstellt, dass ein Projekt auf Sicherheitsvorfälle reagiert und über ausreichende Schutzmaßnahmen verfügt, um eine zuverlässige Compliance- und Sicherheitsstrategie zu entwickeln. Außerdem wird dadurch die Verwendung kostspieliger SCA-/SAST-Scans bei jedem Open-Source-Projekt vermieden.

Lizenzabdeckung

  • Der Lizenzumfang wird verwendet, um Entscheidungen über das Risiko der Verwendung nicht lizenzierter Software zu treffen.

Lizenzen deklariert

  • Angegebene Lizenzen bieten Transparenz hinsichtlich potenzieller Lizenzkonflikte in Softwarepaketen und können verwendet werden, um festzustellen, ob der Anwendungsfall der Software mit der bereitgestellten Lizenz kompatibel ist und den Lizenzrichtlinien des Unternehmens entspricht.

OSI-genehmigte Lizenzen

  • Die dem OSI-Standard entsprechenden Lizenzen geben Vertrauen in die lizenzkonforme Nutzung der Software.

Dauer der Fehlerbeseitigung

  • Diese Metrik bietet eine Möglichkeit, unterschiedliche Reaktionsraten auf Fehler zu berücksichtigen, wenn diese zwischen Projekten auftreten.

Upstream-Code-Abhängigkeiten

  • Dadurch wird sichergestellt, dass auch die Abhängigkeiten eines Projekts in jede Machbarkeitsbewertung einbezogen werden, indem sowohl das zu bewertende Projekt als auch seine Abhängigkeiten berücksichtigt werden.

Libyears

  • Diese Metrik bietet ein Maß für die Aktualität von Softwareabhängigkeiten und verdeutlicht das Risiko, das mit der Verwendung von Projekten verbunden ist, die möglicherweise versteckte Wartungskosten oder Sicherheitslücken aufweisen, weil die Abhängigkeiten nicht regelmäßig aktualisiert werden.

Weitere Überlegungen:

Dokumentation der Sicherheitsrichtlinien

  • Dadurch können wir berücksichtigen, wie das Projekt auf Sicherheitslücken reagiert.
  • Die Sicherheitsrichtlinien des Projekts sollten ein Verfahren enthalten, das es jedem ermöglicht, Schwachstellen vertraulich zu melden und diese Meldungen schnell und effizient zu bearbeiten. Sie sollten auch ein Embargoverfahren enthalten, um die Organisationen, die das Projekt nutzen, vertraulich zu benachrichtigen und ihnen Zeit zu geben, Sicherheitsupdates zu installieren, bevor eine Schwachstelle öffentlich wird.

Was Compliance und Sicherheit für die Rentabilität bedeuten

Dieses Metrikmodell hilft zu beurteilen, wie sehr sowohl die Community als auch die Betreuer der Anwendung die Sicherheit und Compliance ihrer Anwendung berücksichtigen. Wir erwarten, diese Indikatoren zur Risikobewertung zu nutzen. Wir haben verschiedene Herausforderungen wie die Lizenzierung, die mit unserem beabsichtigten Anwendungsfall inkompatibel sein kann, über sicherheitsorientierte Badges und Metriken bis hin zur Geschwindigkeit und Regelmäßigkeit, mit der ein Team die Abhängigkeiten und gemeldeten Fehler seiner Anwendung beachtet.

Darüber hinaus sind, wie in anderen Modellen auch, einige Metriken schwer nachzuvollziehen oder zu visualisieren. Wir lassen Flexibilität bei der Bewertung von Anwendungen anhand schwer zu erfassender Metriken. Beispiel: Ähnlich wie bei der Dauer der Fehlerbehebung liegt die Auswahl der für ein Projekt angemessenen Libyears immer bei den Betreuern. Je nachdem, wie oder wo eine Anwendung ausgeführt wird und wie häufig sie aktualisiert wird, ist eine kritische Betrachtung der Libyears erforderlich.

Unternehmensführung

Die Kategorie Governance konzentriert sich stark auf die Projektbetreuer und ihre Bemühungen, da die Governance von Open-Source-Projekten dazu beiträgt, Entscheidungsprozesse zu definieren. Das Verständnis der Projektbetreuer ist ein wichtiger Teil der allgemeinen Projektdurchführbarkeit, da die Projektbetreuer die Torwächter für eingehende Änderungen, neue Releases und die zukünftige Projektausrichtung sind.

Nur in dieser Kategorie enthaltene Metriken:

Issue Label Inklusivität

  • Die Inklusivität der Problembezeichnung misst die Zugänglichkeit und Inklusivität von Projektproblemen für Mitwirkende mit unterschiedlichen Qualifikationsstufen und Hintergründen.

Benutzerfreundlichkeit der Dokumentation

  • Die Dokumentnutzbarkeit bewertet, wie gut die Dokumentation eines Open-Source-Projekts den Mitwirkenden dient, indem sie Klarheit, Lesbarkeit, Inklusivität und Zugänglichkeit gewährleistet.

Zeit zum Schließen

  • Hiermit wird gemessen, wie lange es dauert, bis ein Beitrag in das Projekt gelangt

Ausgabealter

  • Das Problemalter gibt an, wie lange Fragen, Vorschläge und andere Probleme im Allgemeinen in einem Projekt verbleiben, ohne gelöst oder geschlossen zu werden.

Schließungsverhältnis von Änderungsanforderungen

  • Dies hilft zu verstehen, ob ein Projekt über genügend Betreuer verfügt, um mit den Beiträgen zum Projekt Schritt zu halten.

Popularität des Projekts

  • Diese Metrik ist eine Zusammenfassung anderer kleinerer Metriken (z. B. „Gefällt mir“-Angaben, Sterne, Abzeichen, Forks, Klone), die Indikatoren für Nutzung und Akzeptanz liefern (Vargas et al., 2024).

Release-Frequenz

  • Mithilfe der Veröffentlichungshäufigkeit lässt sich ermitteln, wie lange es dauert, bis ein Projekt Änderungen und Sicherheitsfixes in eine Veröffentlichung integriert und wann mit Sicherheitspatches, Fehlerbehebungen und neuen Funktionen zu rechnen ist.

Libyears

  • Diese Metrik bietet ein Maß für die Aktualität von Softwareabhängigkeiten und verdeutlicht das Risiko, das mit der Verwendung von Projekten verbunden ist, die möglicherweise versteckte Wartungskosten oder Sicherheitslücken aufweisen, weil die Abhängigkeiten nicht regelmäßig aktualisiert werden.

Weitere Überlegungen:

Governance-Dokumentation:

  • Zu wissen, wie die Zusammenarbeit abläuft und Entscheidungen getroffen werden, ist für die Realisierbarkeit wichtig, da es Klarheit darüber schafft, wie das Projekt gesteuert wird und bedeutet, dass die Leute Beiträge leisten können, die mit größerer Wahrscheinlichkeit akzeptiert werden.
  • Die Prozesse der Zusammenarbeit und Entscheidungsfindung sollten im Rahmen der Projekt-Governance klar dokumentiert werden.
  • Die Projektleitung sollte dokumentiert sein, einschließlich der Namen der Führungskräfte und ihrer Auswahl. Idealerweise sollte ein fairer und transparenter Auswahlprozess stattfinden, bei dem die Führungspositionen mit Personen besetzt werden, die über die entsprechende Expertise und ausreichend Zeit für die Projektleitung verfügen.

Stiftungs-, Firmen- oder Einzeleigentum:

  • Die allgemeine Eigentümerstruktur hat oft Auswirkungen darauf, wie das Projekt im Alltag verwaltet wird und wie es von anderen wahrgenommen wird.
  • Neutrale Stiftungen bieten gleiche Wettbewerbsbedingungen, in denen einzelne Mitwirkende als Gleichberechtigte Beiträge leisten können. Dies ermöglicht es Unternehmen, in einem neutralen Umfeld zusammenzuarbeiten, in dem kein einzelnes Unternehmen die Kontrolle über das Projekt hat.
  • Projekte im Besitz eines Unternehmens oder einer Einzelperson sind möglicherweise weniger rentabel, da diese einseitige Entscheidungen treffen können, die sich auf die Benutzer des Projekts auswirken (z. B. Lizenzänderung) oder die Weiterentwicklung und Wartung einstellen können (z. B. bei größeren Lebensveränderungen oder Geschäftsaufgabe).

Was Governance für die Lebensfähigkeit bedeutet

Diese Kennzahlen sind nützlich, um die Absicht oder Unabsichtlichkeit der Projektsteuerung aufzuzeigen. Fehlen beispielsweise inklusive Beschriftungen für Probleme, deutet dies auf eine Lücke bei der Aufnahme neuer Mitwirkender und der Auswahl bestehender Mitwirkender in den Arbeitsabläufen hin. Die Fähigkeit, zu einem Projekt beizutragen, es zu verstehen oder sich darauf zu verlassen, hängt stark vom Aufwand hinter der Steuerung ab.

Das heißt nicht, dass schlechte Governance-Kennzahlen darauf hindeuten, dass ein Projekt von Idioten geleitet wird. Eine niedrige Abschlussquote von Änderungsanfragen kann beispielsweise lediglich darauf hinweisen, dass es nicht genügend Betreuer gibt, um eine beitragende Community zu unterstützen. Ein Mangel an neuen Problemen könnte das Ergebnis einer kürzlich erfolgten großen Veröffentlichung sein, die viele wiederkehrende Probleme behebt. Diese Kennzahlen sind wichtig, um diese Gründe zusammenzufassen; nicht, um Zweifel an den Projektbetreuern zu wecken. Sie helfen dabei, die Governance-Kapazität und den Aufwand für alle Projekte eines Softwareportfolios zu ermitteln.

Wenn einige dieser Kennzahlen als aussagekräftige Community-Kennzahlen erscheinen, ist das auch möglich. Viele der hier verwendeten Kennzahlen sind eine Kombination aus dem Aufwand, den die Community für ein Projekt aufbringt, und dem Aufwand des Projektträgers. Die Überschneidung der Kennzahlen spiegelt diesen Zusammenhang gut wider, wenn man die gemeinsame Verantwortung von Mitwirkenden und Betreuern bei der Erstellung von Open-Source-Software berücksichtigt.

Gemeinschaft

Ein wichtiger Aspekt der Realisierbarkeit ist die Aktivität und Akzeptanz der Community, denn ohne eine aktive Community wird sich ein Open-Source-Projekt wahrscheinlich nicht weiterentwickeln und wachsen. Die Idee dahinter ist, dass eine aktive Community rund um ein Projekt eher zu besserer Leistung, Schwachstellenmanagement und Funktionsvollständigkeit beiträgt und so die weitere Entwicklung erleichtert.

CHAOSS-Metriken:

Klone

  • Die Anzahl der Klone misst, wie oft ein Projekt aus einem Repository auf einen lokalen Computer gezogen wurde, und dient als Indikator für die Übernahme.

Technische Gabeln

  • Die Anzahl der Forks zeigt das Interesse an einer Mitwirkung am Projekt an.

Arten von Beiträgen

  • Open-Source-Projekte bestehen aus mehr als nur Code, und andere Arten von Beiträgen (z. B. Strategie, Probleme, Überprüfungen, Ereignisse, Schreiben von Artikeln) weisen auf die Fähigkeit hin, ein Projekt aufrechtzuerhalten.

Änderungsanträge

  • Die Anzahl regelmäßiger Anfragen kann dabei helfen, die Stärke, Muster und Nachhaltigkeit der Community eines Projekts zu verstehen.

Beauftragte

  • Die mit der Anzahl der Committer verbundenen Trends können Einblicke in den Lebenszyklus eines Projekts geben und Aufschluss darüber geben, ob die Anzahl der Mitwirkenden steigt, stabil bleibt oder sinkt.

Schließungsverhältnis von Änderungsanforderungen

  • Dies hilft zu verstehen, ob ein Projekt über genügend Betreuer verfügt, um mit den Beiträgen zum Projekt Schritt zu halten.

Popularität des Projekts

  • Diese Metrik ist eine Zusammenfassung anderer kleinerer Metriken (z. B. „Gefällt mir“-Angaben, Sterne, Abzeichen, Forks, Klone), die Indikatoren für Nutzung und Akzeptanz liefern (Vargas et al., 2024).

Libyears

  • Diese Metrik bietet ein Maß für die Aktualität von Softwareabhängigkeiten und verdeutlicht das Risiko, das mit der Verwendung von Projekten verbunden ist, die möglicherweise versteckte Wartungskosten oder Sicherheitslücken aufweisen, weil die Abhängigkeiten nicht regelmäßig aktualisiert werden.

Weitere Überlegungen:

Kommunikationsinklusivität:

  • Projekte, in denen gegenseitiger Respekt und Freundlichkeit gelebt werden, sind erfolgversprechender, da die Mitarbeiter weiterhin Beiträge leisten möchten. Achten Sie daher genau darauf, wie die Mitarbeiter in Diskussionen, Code-Reviews, Slack und anderen Kommunikationskanälen miteinander umgehen. Projekte mit einer toxischen Kultur hingegen gefährden die Community-Mitglieder (einschließlich der Mitarbeiter einer Organisation).

Was Gemeinschaft für die Lebensfähigkeit bedeutet

Mit der Community wollen wir die „Tüftelei“ an einem Projekt verstehen und die geleisteten Beiträge messen. Klone und Forks zeigen an, wie viele Nutzer eine Software genutzt haben, um sie aus dem Quellcode zu entwickeln, den Quellcode zu prüfen, einen Beitrag zu leisten oder das Projekt in eine neue Richtung zu lenken. Diese Popularität ist wichtig, um das Engagement der Community für ein Projekt zu verfolgen. Das Risiko, ein Open-Source-Projekt zu übernehmen, kann sinken, wenn es von vielen anderen Organisationen übernommen wird, da aktive Projekte mit vielen Nutzern seltener aufgegeben werden. Eine starke Nutzerbasis verringert das Risiko, dass ein Projekt aufgegeben wird.

Anhand von Committer-Trends, Beitragsarten und Änderungsanfragen können wir erkennen, wie eine Community interagiert. Möglicherweise werden mehr Markdown-RFCs als Features erstellt, vielleicht auch umgekehrt. Wenn wir verstehen, welche Arten von Beiträgen geleistet werden und wie regelmäßig sie erfolgen, können wir die Projektrealisierbarkeit besser beurteilen. Beispielsweise ist es vernünftig anzunehmen, dass ein Projekt, das innerhalb von drei Monaten 90 % seiner Committer verloren hat, weniger rentabel ist als ein Projekt mit einem stabilen (flachen) Committer-Trend. Umgekehrt könnte ein wachsendes oder stabiles Projekt im Kontext eines bestimmten Technologietrends an Popularität gewinnen. Während manche „Basteln“-Kennzahlen mikro-orientiert wirken, sind andere Kennzahlen makro-orientiert.

Durch die Messung einiger gemeinsamer Kennzahlen ermöglichen wir es, dieses Modell aus der Perspektive der Community-Pflege und des allgemeinen Interesses zu betrachten. Wir stellen fest, dass sich dies vom Governance-Aspekt unterscheidet, selbst bei erheblichen Überschneidungen, da Trends in diesen Kennzahlen fast nie ausschließlich auf die Community oder die Projektbetreuer zurückzuführen sind. Die Zahlen könnten für beide Bereiche von Bedeutung sein und sind daher in beiden Modellen vorhanden.

Strategie

Die Strategie eines Projekts lässt sich zahlenmäßig möglicherweise weniger eindeutig definieren als viele andere Realisierbarkeitskategorien. Die Strategie wird anhand von beobachtbaren Faktoren und dem Einfluss gemessen, den Einzelpersonen und Organisationen auf ein Projekt haben können.

CHAOSS-Metriken:

Verbreitung von Programmiersprachen

  • Die in einem Projekt verwendeten Programmiersprachen können Einfluss darauf haben, ob eine Organisation über die erforderlichen Fähigkeiten verfügt, um im Upstream-Bereich Beiträge zu leisten. Dies kann sich auf die Rentabilität auswirken, wenn Fehlerbehebungen nicht integriert werden können.

Mitarbeiterabwesenheitsfaktor (manchmal auch Bus-Faktor oder Lotterie-Faktor genannt)

  • Eine Zählung der geringsten Anzahl von Committern, die 50 % der Aktivität über einen bestimmten Zeitraum ausmachen, um das Risiko der Verwendung eines bestimmten Projekts oder einer Reihe von Projekten im Hinblick darauf, wie viel Unterstützung das Projekt erhalten würde, wenn die Top-Mitwirkenden es verlassen würden, besser zu verstehen.

Elefantenfaktor

  • Der Elephant-Faktor zählt die wenigsten Organisationen, die 50 % der Aktivitäten eines Projekts ausmachen, und wird verwendet, um den Einfluss bestimmter Organisationen auf ein Projekt abzuschätzen und um zu ermitteln, wie schädlich es wäre, wenn das jeweilige Unternehmen seine Prioritäten ändern und seinen Beitrag einstellen würde.

Organisatorischer Einfluss

  • Der organisatorische Einfluss misst den Grad der Kontrolle, den eine Organisation in einem Projekt haben kann. Dies ist eine Schätzung und eine Aggregation mehrerer anderer Kennzahlen, darunter organisatorische Vielfalt.

Release-Frequenz

  • Mithilfe der Veröffentlichungshäufigkeit lässt sich ermitteln, wie lange es dauert, bis ein Projekt Änderungen und Sicherheitsfixes in eine Veröffentlichung integriert und wann mit Sicherheitspatches, Fehlerbehebungen und neuen Funktionen zu rechnen ist.

Weitere Überlegungen:

Lizenzvereinbarungen für Mitwirkende (CLAs)

  • Eine vor dem Beitrag erforderliche Unterschrift unter einem Contributor License Agreement (CLA) kann die Rentabilität verringern, da das CLA der kontrollierenden Organisation oft die Möglichkeit gibt, die Lizenz zu erneuern oder andere Teppich zieht.

Was Strategie für die Rentabilität bedeutet

Die in diesem Modell erfassten Kennzahlen bilden die Strategie bzw. den erwarteten Einfluss von Einzelpersonen und Organisationen ab. Beispielsweise ist es bei einem Abwesenheitsfaktor von 1 sehr wahrscheinlich, dass Burnout oder andere Faktoren dazu führen, dass der einzige Mitarbeiter die Projektpflege einstellt. Bei einer stabileren Anzahl an Mitarbeitern ist eine stabilere und tragfähigere Pflegestrategie wahrscheinlicher.

Wir teilen die Release-Häufigkeit zwischen Strategie und Governance auf. Dies kategorisiert die Überschneidung, wie die Betreuer eines Projekts sowohl einen Governance-Plan als auch eine Wartungsstrategie bereitstellen.

Maßnahmen und Schadensbegrenzung

In den vorherigen vier Abschnitten wurden Kategorien mit Kennzahlen behandelt, die zum besseren Verständnis vieler verschiedener Aspekte der Rentabilität verwendet werden können. Organisationen müssen jedoch über das bloße Verstehen hinausgehen und Maßnahmen ergreifen.

Beitrag als Strategie zur Risikominderung

Einer der Vorteile von Open-Source-Projekten besteht darin, dass wir alle zusammenarbeiten können, um ihre Rentabilität zu verbessern und das mit ihrer Nutzung verbundene Risiko zu reduzieren. Die Entscheidung für ein Open-Source-Projekt ist oft eine Abwägung zwischen Risiken und Nutzen, da Organisationen entscheiden, ob ein Projekt für ihren Anwendungsfall rentabel genug ist.

Der beste Weg, die Zukunftsfähigkeit eines Projekts zu verstehen, zu beeinflussen und zu verbessern, besteht darin, den Mitarbeitern Zeit für die Mitarbeit an Projekten zuzuweisen. Die Einbindung Ihrer Mitarbeiter in ein Projekt hilft Ihnen, dessen Stärken und Schwächen zu verstehen und gleichzeitig die zukünftige Ausrichtung des Projekts von innen heraus zu beeinflussen.

Organisationen können außerdem finanzielle Mittel und andere Ressourcen bereitstellen, um Open-Source-Projekte aufrechtzuerhalten und ihre Rentabilität zu verbessern.

Abhängigkeitsmanagement

Die Anwendung dieser Metriken operationalisiert Aufgaben bei der Auswahl und Wartung von Software. Durch die Bewertung von Abhängigkeiten erhalten Ingenieure ein besseres Verständnis dafür, welche Teile eines Open-Source-Projekts herausragend sind und welche möglicherweise nicht. Je nach geplanter Anwendung können OSPOs, Anwendungsteams und Betriebsteams entscheiden, ob sich das Risiko eines gemeinsamen Projekts lohnt.

Die Bewertung der Realisierbarkeit gibt Hinweise darauf, welche Abhängigkeiten aktualisiert werden sollten. Anstatt alte Abhängigkeiten zu einem vagen „technischen Schuldenkomplex“ zusammenzufassen, können wir die Eignung von Compliance und Lizenzierung, Community, Strategie und Governance für ein bestimmtes Projekt abschätzen. Wir können auch das Risiko abschätzen, das entsteht, wenn Projekte nicht angegangen werden, und zwar auf eine Weise, die für die Stakeholder und bei der Überprüfung der Prioritäten quantifizierbar ist.

Neubewertung als Praxis

Entwicklungsteams arbeiten regelmäßig unter Bedingungen, die keine Zeit lassen, Codebasen auf Optimierungsmöglichkeiten zu prüfen. Es ist entscheidend, Aufgaben zu priorisieren, die einen messbaren Mehrwert für die jeweilige Organisation bieten. Dieses Machbarkeitskonzept ermöglicht es, technische Schulden als Risikominderung zu betrachten. So wie wir Sicherheitslücken oder Lizenzprobleme vermeiden, vermeiden wir auch unrentable Open-Source-Projekte.

Ein Tool und ein Framework zur praktischen Bewertung und Neubewertung über die gesamte Projektlaufzeit ermöglichen eine kennzahlenbasierte Diskussion über die manchmal hochgesteckten Ziele eines Entwicklers. Wir empfehlen, diese Kennzahlen einmal im Quartal im Rahmen der Priorisierung von Open-Source-Projekten zu besprechen. So lassen sich Beiträge zu Open Source und die Aktualisierung wichtiger Abhängigkeitsversionen (und das damit verbundene Erlernen aktualisierter Programmierpraktiken) als Risikominimierung besser begründen. Die Bewertung der Machbarkeit ist eine Möglichkeit, regelmäßig einen produktiven Austausch mit nicht-technischen Stakeholdern zu führen.

Fazit

Je nach Anwendungsfall ergeben sich unterschiedliche Einsatzmöglichkeiten für dieses Framework zur Machbarkeitsbewertung. Es wurde ursprünglich für die Bewertung der Nutzung von Open-Source-Produkten innerhalb eines bestimmten Unternehmens entwickelt. Daher variieren die Schwellenwerte für jede Modellkategorie je nach der Risikobereitschaft Ihres Unternehmens.

Beispielsweise:

  • Organisationen, die mit der Entwicklung formellerer Open-Source-Softwareprozesse beginnen, beginnen normalerweise mit Compliance und Sicherheit und verwenden Lizenzierungs- und Schwachstelleninformationen, um ihre Software auszuwählen.
  • Governance ist entscheidend für Organisationen, die die Open-Source-Community einbinden oder zu einem Projekt beitragen möchten, um neue Funktionen zu entwickeln. Wenn eine Organisation bereit ist, Zeit und Ressourcen für die Pflege eines Projekts zu investieren, ist die Governance dieses Projekts ein wichtiger Aspekt.
  • Die Community ist wichtig für hochmoderne oder neuere Technologieimplementierungen. Während ältere Technologien wahrscheinlich eine weniger volatile Community haben, in der die Betreuer und der Zustrom neuer Beiträge im Laufe der Zeit beurteilt werden können, benötigt ein neues Projekt möglicherweise eine stärkere Community mit mehr Wachsamkeit gegenüber seinen Konkurrenten, um sicherzustellen, dass ein Software-Stack nicht aufgegeben wird.

Die meisten Geschäftsentscheidungen laufen auf eine Risikobewertung und das Abwägen von Kompromissen hinaus. Unternehmen sollten Projektrisiken strategisch im Hinblick auf die jeweilige Projektnutzung einschätzen. Handelt es sich um einen kritischen Teil eines Technologie-Stacks, sollte das Risiko so gering wie möglich sein. Wird ein Open-Source-Projekt hingegen nur als kleiner Teil einer nicht kritischen Infrastruktur genutzt, kann ein Unternehmen ein höheres Risiko eingehen. Die Bewertung der Realisierbarkeit und die Betrachtung aus der Risikoperspektive sowie die Frage, welche Risiken in Kauf genommen werden können, sind ein wichtiger erster Schritt. Es ist jedoch auch wichtig zu überlegen, welche Risiken gemindert werden können, um die Realisierbarkeit zu verbessern. Viele dieser Risiken lassen sich am besten mindern, indem Mitarbeiter dafür bezahlt werden, an den für Ihr Unternehmen wichtigsten Projekten mitzuwirken. Dies bietet nicht nur die Möglichkeit, die Realisierbarkeit und Nachhaltigkeit zu verbessern, sondern gibt auch Aufschluss darüber, wohin das Projekt steuert und wie es läuft. So können etwaige Änderungen im Projekt, die das Risiko weiter erhöhen, leichter antizipiert werden.

Vorsichtsmaßnahmen und Überlegungen

  • Wie Sie die Realisierbarkeit und Ihre Risikotoleranz beurteilen, hängt stark von den Anforderungen Ihres Unternehmens und Ihrem Anwendungsfall ab. Es gibt daher keinen einheitlichen Ansatz. Ein akzeptables Risiko für ein Technologie-Startup ist möglicherweise nicht dasselbe wie für ein Finanzdienstleistungsunternehmen. Ebenso ist die Risikotoleranz und Realisierbarkeit eines Open-Source-Infrastrukturprojekts als Grundlage für umsatzgenerierende Produkte eines Unternehmens wahrscheinlich geringer als bei einem Projekt, das von einem kleinen Entwicklerteam durchgeführt wird.
  • Während einige der in diesem Handbuch beschriebenen Punkte automatisiert und im großen Maßstab bewertet werden können, erfordern andere Kennzahlen und zusätzliche Überlegungen eine eher manuelle Bewertung. Daher sollten diese besser nur für Projekte verwendet werden, bei denen die Realisierbarkeit für ein Unternehmen von entscheidender Bedeutung ist.
  • Nicht jedes Risiko lässt sich vorhersehen, und ein Projekt kann unerwartet und auf unvorhersehbare Weise unrentabel werden. Dieser Leitfaden behandelt viele Aspekte der Rentabilität, die bewertet werden können. Tatsächlich werden Open-Source-Projekte jedoch von Menschen betrieben, und manchmal ergreifen diese unvorhersehbare Maßnahmen, die sich auf andere auswirken.
  • Dieser Leitfaden kann für Organisationen, die neu in der Bewertung der Machbarkeit sind, etwas überwältigend sein. Daher ist es für viele Organisationen sinnvoll, sich zunächst auf einige Bereiche zu konzentrieren und später darauf aufzubauen. Wir empfehlen, mit ein oder zwei Modellen zu beginnen oder sogar mit dem allgemeinen Startermodell als erster Schritt.

Zusätzliche Lektüre

Mitwirkende

Die folgenden Personen haben zu diesem Leitfaden beigetragen:

  • Gary White
  • Morgenröte
  • Matt Germonprez

Referenzen

CHAOSS Practitioner Guides sind MIT-lizenzierte, lebendige Dokumente und wir freuen uns über Ihr Feedback und Ihren Input. Sie können Änderungen an diesem Dokument vorschlagen unter https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/viability.md