Leitfaden für Praktiker: Den Wert einer Organisation demonstrieren

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 an Open-Source-Teams und Open-Source-Programmbüros in Organisationen, in denen der Wert der Arbeit nachgewiesen und die für Open-Source-Initiativen eingesetzten Ressourcen gerechtfertigt werden müssen.

Einführung

Viele Menschen arbeiten im Rahmen ihrer Beschäftigung an Open-Source-Projekten mit. In einem Umfrage 2023 unter Open-Source-BetreuernDie Linux Foundation stellte fest, dass 62.5 % der Befragten Vollzeit an ihren Projekten arbeiteten und eine weitere Studie von Sophia Vargas (2023) bei Google fanden heraus, dass 30 % der Entwickler in ihrer Stichprobe ausschließlich beruflich und 52 % sowohl privat als auch beruflich beteiligt waren. Diese Beteiligung innerhalb von Organisationen kann dazu beitragen, Open-Source-Projekte langfristig zu erhalten, indem Mitarbeiter für die von ihnen genutzten Open-Source-Projekte eingestellt oder andere Ressourcen bereitgestellt werden (Egbahl 2016). Für viele Organisationen bleibt es jedoch eine Herausforderung, den Wert dieser Arbeit zu rechtfertigen, damit sie über die langen Zeiträume, die für die Aufrechterhaltung von Open-Source-Projekten erforderlich sind, fortgeführt werden kann.

Einige Anmerkungen zur Terminologie:

• In diesem Handbuch wird der Begriff „Organisation" bewusst, da der Nachweis des organisatorischen Werts für eine große Bandbreite unterschiedlicher Organisationstypen wichtig ist (z. B. OSPOs an Universitäten/Regierungen, Forschungsgruppen, Unternehmen).
• In diesem Handbuch wird der Begriff „Ziele„“ beschreibt, was die Organisation erreichen möchte. Je nach Organisation können die Ziele als Teil der Vision, Mission oder Strategie beschrieben werden. Im Kontext einer Geschäftseinheit können die Ziele Teil einer Produktlinienstrategie oder eines Produktplans sein. Diese Ziele sind ein Schlüsselelement zur Demonstration Wert für Ihr Unternehmen, da die Unternehmensleitung eher den Wert einer Arbeit erkennt, die klar auf die Ziele des Unternehmens ausgerichtet ist.

Probleme

Open-Source-Teams in vielen Unternehmen stehen unter dem Druck der Unternehmensleitung, ihre Open-Source-Beiträge zu reduzieren, um sich auf interne Initiativen zu konzentrieren, die dem Unternehmen mehr Mehrwert bieten. Dies zwingt Open-Source-Teams dazu, ihre Arbeit im Open-Source-Bereich zu rechtfertigen und nachzuweisen, dass sie mindestens genauso wertvoll ist wie andere Initiativen, an denen die Mitarbeiter arbeiten könnten. Es kann jedoch schwierig sein, diese Begründung so zu formulieren, dass sie bei der Unternehmensleitung Anklang findet und klar zum Ausdruck bringt, wie das Unternehmen von weiteren Beiträgen zu einem Open-Source-Projekt profitiert.

Open-Source-Teams rechtfertigen ihre Arbeit häufig auf eine Weise, die wie Wohltätigkeit klingt, indem sie über Beiträge zu Open Source sprechen, indem sie sagen, dass dies dem Wohl der Community dient. Dies kommt bei der Führung jedoch nicht gut an, da sich dadurch die Investition der Mitarbeiterzeit nicht auszahlt.

In anderen Fällen bieten Open-Source-Teams einen Überblick über ihre interne Nutzung mit Daten über die in einem Open-Source-Projekt geleistete Arbeit (z. B. Anzahl der Beiträge, Betreuer, Commits, Funktionen). Für die Unternehmensleitung ist dies jedoch ein Hinweis darauf, dass sich die von den Mitarbeitern in Open-Source-Projekte investierte Zeit zwar lohnt, es aber keinen nachweisbaren Nutzen gibt.

Eine weitere Herausforderung für viele Unternehmen besteht darin, dass sie keine übergreifende Open-Source-Strategie für ihre Beiträge haben. Mitarbeiter werden häufig dazu ermutigt, direkt oder indirekt zu Open Source beizutragen, ohne dass ihnen ausreichende Anleitungen gegeben werden, wie sie den Wert ihrer Bemühungen unter Beweis stellen können. Dies kann zu einer negativen Rückkopplungsschleife führen:

• Die Mitarbeiter werden ermutigt, sich einzubringen.
• Der Wert wird nicht verstanden, daher fragt die Führung: „Warum verschwenden wir unsere Zeit mit etwas, das uns nicht weiterhilft?“
• Den Mitarbeitern wird gesagt, sie sollten weniger Zeit mit Open Source verbringen, was bei ihnen das Gefühl erzeugt, nicht anerkannt und unterbewertet zu werden, was wiederum zu Burnout führt.
• Sowohl das Open-Source-Projekt als auch die Organisation beginnen darunter zu leiden.

Diese negative Rückkopplungsschleife kann in Organisationen ohne offizielles Open-Source-Team noch ausgeprägter sein. Der Nachweis des Werts dieser Arbeit obliegt inoffiziellen Teams, die aus einzelnen Mitarbeitern bestehen, die möglicherweise nicht in der Lage oder zeitlich sind, diese Arbeit zu rechtfertigen. In manchen Fällen leisten diese Personen möglicherweise Beiträge, weil ein Open-Source-Projekt Fehlerbehebungen oder Funktionen benötigt, die ihre Aufgaben erleichtern würden. Dies wird jedoch nicht als Teil ihrer offiziellen Rolle angesehen.

Lessons Learned

Die Führung möchte Antworten auf die folgenden Fragen:

• Welche Bedeutung haben die Open-Source-Projekte, die die Organisation betreut?
• Welchen Vorteil hat die Organisation durch die Beteiligung an Open-Source-Projekten?
• Wie viel Zeit wird in der Softwareentwicklung für die Wartung von Open-Source-Projekten aufgewendet?

Die Entwicklung einer Open-Source-Beitragsstrategie kann Unternehmen dabei helfen, ihre Gespräche mit der Führungsebene so zu gestalten, dass der Wert ihrer Open-Source-Bemühungen auf eine Weise verdeutlicht wird, die bei der Führungsebene Anklang findet. Die Open-Source-Strategie sollte mindestens Details zu den folgenden Bereichen enthalten, die jeweils im Abschnitt „Vorgehensweise“ unten behandelt werden:

• Unterstützung Ihrer Organisation Ziele
• Feststellen, welche Open-Source-Projekte am kritischem für Ihre Organisation
• Bewertung von Open-Source-Projekten Gesundheitsrisiken
• priorisieren innerhalb der begrenzten Ressourcen Ihrer Organisation
• Messen und Einrahmen Wert

Wie man Maßnahmen ergreift

Durch die Entwicklung einer robusten Open-Source-Strategie, die den Wert der Open-Source-Aktivitäten Ihres Unternehmens aufzeigt, können diese Aktivitäten und Ergebnisse so beschrieben werden, dass sie die Führungsebene überzeugen. Sie müssen klar darlegen, wie die Arbeit mit Open Source Ihrem Unternehmen hilft, seine Ziele zu erreichen. Dies hilft dabei, den weiteren Teil der Strategie zu gestalten, der den Einfluss des Open-Source-Projekterfolgs, die Nutzung der Ressourcen Ihres Unternehmens und schließlich die Messung des Nutzens beschreibt.

Unterstützung Ihrer Organisation Ziele

Wenn Sie sich die Zeit nehmen und die Mühe machen, sicherzustellen, dass Ihre Open-Source-Strategie die Ziele des gesamten Unternehmens unterstützt, können Sie die Fortsetzung organisationsrelevanter Open-Source-Projekte deutlich einfacher begründen. Wenn Sie erklären, wie Open-Source-Beiträge die Ziele des Unternehmens unterstützen, kann das der Geschäftsführung die strategische Bedeutung dieser Arbeit verdeutlichen.

Eine solide Open-Source-Strategie ist wichtig, da erfolgreiche Open-Source-Teilnahme langfristiges Engagement erfordert. Einzelpersonen und Organisationen investieren Monate und Jahre in den Aufbau von Vertrauen und Ansehen in bestimmten Open-Source-Communitys. All diese harte Arbeit ist vergeblich, wenn diese Personen immer wieder von Open-Source-Projekten abgezogen werden, um an internen Projekten mitzuarbeiten. Um Mitarbeiter an den für Ihr Unternehmen wichtigen Open-Source-Projekten zu halten, bedarf es Planung und strategischem Denken, um diese Open-Source-Aktivitäten zu priorisieren und sie an den Gesamtzielen Ihres Unternehmens auszurichten.

Allerdings verfügt jede Organisation über eine begrenzte Anzahl an Mitarbeitern und anderen begrenzten Ressourcen, so Priorisierung Ihre Open-Source-Aktivitäten helfen Ihnen, sich auf die Aktivitäten zu konzentrieren, die den größten Nutzen für Ihr Unternehmen haben und ihm am direktesten dabei helfen, seine Ziele zu erreichen. Diese Priorisierung trägt dazu bei, begrenzte Ressourcen effizient zu nutzen. In diesem Leitfaden wird die Priorität als Formel definiert, die sich aus Kritikalität multipliziert mit dem Gesundheitsrisiko zusammensetzt.

Kritisch Hier stimmen diese Bemühungen mit den Zielen Ihres Unternehmens überein. Indem Sie die Bedeutung bestimmter Open-Source-Projekte für Ihr Unternehmen hervorheben, können Sie diese kritischen Projekte nutzen, um die Strategien so zu gestalten, dass die Unternehmensleitung versteht, wie wichtig es ist, diese Arbeit langfristig fortzusetzen, um sicherzustellen, dass das Unternehmen seine Ziele erreichen kann.

Gesundheitsrisiko des Projekts ist in dieser Gleichung wichtig, da einige Open-Source-Projekte stabiler und nachhaltiger sind als andere. Manche Projekte sind daher riskanter und benötigen mehr Unterstützung. Ein stabiles Open-Source-Projekt, das für Ihr Unternehmen von entscheidender Bedeutung ist, hat wahrscheinlich eine niedrigere Priorität als ein ebenso wichtiges, aber risikoreicheres Projekt, das die Unterstützung Ihres Unternehmens benötigt, um stabil zu werden und das Risiko seiner Nutzung zu reduzieren.

Daher ist die Priorität für Investitionen (Zuweisung von Personal oder anderen Ressourcen) eine Kombination aus Kritikalität und Projektgesundheitsrisiko, die für Ihr Unternehmen einzigartig ist.

Feststellen, welche Open-Source-Projekte am kritischem für Ihre Organisation

Für alle wichtigen Open-Source-Projekte ist es wichtig, deren Kritikalität zu bestimmen. Dies bedeutet auch, dass ein Softwareinventar zur Identifizierung dieser Projekte erforderlich ist. Viele Unternehmen führen diese Inventuren bereits durch, um ihr Lieferkettenrisiko zu bewerten. Daher passt die Kritikalitätsbewertung gut zu bestehenden Initiativen zur Lieferkettenbewertung.

Um dieses Konzept besser zu veranschaulichen, finden Sie hier einige Beispielkategorien mit Beschreibungen und Fragen, die bei der Bestimmung der Kritikalität hilfreich sein können.

Abhängigkeit: Bestimmen Sie, inwieweit Ihre Organisation von diesem Open-Source-Projekt abhängig ist.

• Ist es ein Kernbestandteil der Funktion Ihrer Organisation?
• Wird es im gesamten Unternehmen häufig genutzt?
• Welche nachgelagerten Auswirkungen hat dies auf die Projekte, Produkte, Dienstleistungen oder Teams Ihres Unternehmens?
• Wie schwierig wäre es, auf etwas anderes umzusteigen? Oder die Software zu forken und intern zu pflegen? Und was würde das kosten?
• Welche Auswirkungen hätte ein ungeplantes Sicherheitsereignis?

Chancen: Es gibt Möglichkeiten, das Open-Source-Projekt voranzutreiben oder zu beeinflussen, damit es den Anforderungen Ihres Unternehmens besser entspricht.

• Sind derzeit Funktionen oder Initiativen auf der Roadmap, die von Nutzen wären? Wenn ja, welche?
• Wenn es in eine andere Richtung ginge, welche Auswirkungen hätte das auf Ihre Organisation?
• In welche Möglichkeiten lohnt es sich, Ressourcen zu investieren?
• Könnte Entwicklung einen Wettbewerbsvorteil schaffen?
• Möchte Ihr Unternehmen als führend in diesem Bereich angesehen werden? Oder stark damit in Verbindung gebracht werden?

Unterstützbarkeit: Bestimmen Sie die Fähigkeit Ihrer Organisation, die Verwendung des Open-Source-Projekts zu unterstützen.

• Wie einfach ist der Support? Ist es gut dokumentiert?
• Wie schwierig ist es, die Qualifikation der Mitarbeiter zu verbessern oder Fachkenntnisse aufzustocken?
• Hilft es, die Kosten zu senken oder zu kontrollieren (z. B. durch die richtige Größe der Kapseln)? Wenn ja, um welchen Faktor?
• Wäre die Nutzung und Bereitstellung von Ressourcen eine bessere Option als eine anbieterbasierte Option?
• Ermöglicht die Verwendung die Auswahl aus mehreren Lösungen und vermeidet man die Abhängigkeit von einem Anbieter?

Die Antworten auf diese Fragen helfen Ihnen dabei, jedes Open-Source-Projekt auf einer Kritikalitätsskala abzubilden. Hier sind einige Beispiele, die als Ausgangspunkt für die Zuordnung der Kritikalität auf einer Skala von 1 (niedrig) bis 10 (hoch) dienen können. Diese finden Sie später im Abschnitt zur Priorisierung in diesem Handbuch erneut:

Bewertung von Open-Source-Projekten Gesundheitsrisiken

Nachdem die Kritikalität ermittelt wurde, ist es an der Zeit, über den anderen Teil der Gleichung nachzudenken, nämlich das Gesundheitsrisiko des Open-Source-Projekts (Priorität = Kritikalität x Gesundheitsrisiko).

Es gibt viele Möglichkeiten, über die Gesundheitsrisiken von Open-Source-Projekten nachzudenken. Es kann jedoch hilfreich sein, mit ein paar Dingen zu beginnen:

• Hochwertige Codebasis: Solides Architekturdesign, statische Codeanalyse, ausreichende Tests
• Reaktionsschnell zu Problemen/PRs: Zeit bis zur ersten Antwort/Überprüfung
• Gesunde Organisatorische Beteiligung: Kein einzelner Anbieter treibt das gesamte Projekt voran
• Hat Zukunftspläne und eine Roadmap: Sie planen und haben einen Design-Review-Prozess
• Qualitätsdokumentation für sowohl Benutzer als auch Mitwirkende: Dokumente sind sowohl für die Einführung als auch für Nachhaltigkeit der Beitragenden und Wachstum
• Gut Sicherheitdienst und Freigabekontrollen: Haben sie eine Historie der Triage und Lösung von Sicherheitsproblemen, verwenden/untersuchen sie Best Practices für die Lieferkettensicherheit

Ähnlich wie die Kritikalität kann das Gesundheitsrisiko eines Projekts bewertet werden. Gleichzeitig können die für Ihr Unternehmen wichtigsten Kernbereiche genauer betrachtet werden. Wenn ein Projekt nicht in einem guten Zustand ist und gleichzeitig kritisch, lohnt es sich wahrscheinlich, Ressourcen für die Verbesserung des Projekts bereitzustellen, um es in einen gesünderen Zustand zu bringen.

Als beispielsweise beim CNCF Helm-Projekt aufgrund der Betreuerschaft mehrerer Projektbedenken festgestellt wurde, wurde das Risiko an die CNCF weitergeleitet. Jorge Castro, ein CNCF-Mitarbeiter, schaltete sich ein und half dem Projekt, sich auf ein Ziel auszurichten (der Start von Helm v4), als zentraler Punkt für das Wachstum der Mitwirkenden. Dies führte zum Aufbau einer besseren Mitwirkendenleiter und zur Zusammenarbeit mit anderen Projekten, Organisationen und Anbietern, um zu investieren und das Open-Source-Projekt nachhaltiger zu gestalten.

priorisieren innerhalb der begrenzten Ressourcen Ihrer Organisation

Das folgende Beispiel zeigt, wie Kritikalität und Integrität bewertet werden. Es kombiniert diese, um Prioritäten festzulegen. Es verwendet zwei Open-Source-Projekte, „Foo“ und „Bar“, mit Informationen zu ihrem Status, einer groben Bewertung und deren Auswirkungen auf die Priorisierung. Angenommen, jeder Abschnitt ist 10 Punkte wert, werden sie mit Kommentaren bewertet. Anschließend wird der Kritikalitätswert mit dem Integritätsrisikowert multipliziert. Wichtige Hinweise:

• Die drei Kritikalitätskomponenten (Abhängigkeit, Chance und Supportfähigkeit) werden gemittelt, um einen einzigen Kritikalitätswert zu ermitteln. Je nach den Anforderungen Ihres Unternehmens kann jedoch die Verwendung eines gewichteten Durchschnitts die bessere Lösung sein. Ein höherer Wert bedeutet, dass das Projekt kritischer ist.
• Gesundheit wird als Gesundheitsrisiko bewertet, was bedeutet, dass niedrigere Zahlen besser sind, da ein gesundes Projekt eine niedrige Risikobewertung hätte.

Ejemplo:

Der letzte Schritt zur Bestimmung der Priorität besteht darin, die Ressourcen Ihrer Organisation den Open-Source-Projekten zuzuordnen, deren Kritikalität gerade bewertet wurde. Das Beispiel in der obigen Tabelle zeigt, dass Foo eine Priorität von 50 hat und damit eine höhere Priorität als Bar mit 21. In diesem Fall sollten Foo mehr Ressourcen zugewiesen werden, es kann jedoch sinnvoll sein, beiden Projekten Ressourcen zuzuweisen.

Es kann hilfreich sein, dies im Hinblick auf Softwareentwickler und Softwareentwicklungsstunden zu betrachten. Wenn Ihre Organisation jedoch keine Mitarbeiter bereitstellen kann, kann es hilfreich sein, Geld zu spenden oder Auftragnehmer für die Unterstützung in diesen Bereichen zu engagieren.

Messen und Einrahmen der Wert

Nachdem die wichtigsten Open-Source-Projekte identifiziert wurden, können diese Informationen gemessen und so aufbereitet werden, dass sie die Führungsebene ansprechen. Eine der häufigsten Schwierigkeiten besteht darin, dass Unternehmen sich auf leicht messbare Kennzahlen wie den Gesamtbeitrag konzentrieren, die einer genaueren Prüfung jedoch nicht standhalten. Kennzahlen sollten die Ziele unterstützen und mit dem „Wert“ und den in das Open-Source-Projekt investierten Ressourcen verknüpft werden können:

• Sind die Funktionen, an deren Weiterentwicklung wir interessiert sind, relevant?
• Werden die Themen, die uns am Herzen liegen, angesprochen?
• Wird die Stabilität verbessert und werden Fehler behoben?
• Ist das Projekt selbst gesund?

Letztendlich muss Ihr Unternehmen entscheiden, ob sich die Ressourceninvestition lohnt, ob es die interne Wartung oder die Akzeptanz des Risikos vornimmt. Dabei kann es hilfreich sein, in drei Schwerpunktbereichen darüber nachzudenken:

• Klassifizierung von Funktionen und Initiativen: So bestimmen und priorisieren Sie, welche Funktionen und Initiativen verfolgt werden sollen
• Probleme und Änderungswünsche: Verfolgung des Werts von Beiträgen zu Unternehmenszielen
• Gesamtzustand des Projekts: Verfolgen Sie den Gesamtzustand von Open-Source-Projekten und erfahren Sie, wie Ihr Unternehmen davon profitieren kann

Klassifizierung von Funktionen und Initiativen

Wenn Sie in ein Open-Source-Projekt investieren oder daran mitwirken und für dieses eine Roadmap vorliegt, kann es hilfreich sein, zunächst die Funktionen des Projekts zu bewerten und deren Übereinstimmung mit den Anforderungen Ihres Unternehmens zu ermitteln. Diese Klassifizierungen sind hilfreich, um zu berichten, wo und warum Mitarbeiter eingesetzt werden.

• Investieren: Direkter Nutzen für Ihr Unternehmen, der die Bereitstellung von zusätzlichem Personal für die Umsetzung der Funktion oder Initiative rechtfertigt. Häufig handelt es sich dabei um wichtige Funktionen für die Unternehmensimplementierung oder um Initiativen, die für den Gesamterfolg des Open-Source-Projekts als wichtig erachtet werden.
• Ansehen:Funktion oder Initiative, die je nach Implementierung entweder störend oder nützlich sein kann.
• Ignore: Keine Funktionen oder Initiativen, die voraussichtlich einen Nutzen oder eine Auswirkung auf die Nutzung des Projekts durch Ihre Organisation haben.

Probleme und Änderungsanfragen

Bugs, Sicherheitsinformationen und Probleme sind nützlich, da sie für die meisten Menschen verständlich sind, ohne sich eingehend mit den Details des Open-Source-Projekts auskennen zu müssen. Dies sind einige Beispielmetriken, die sich problemlos von GitHub und anderen Code-Plattformen abrufen lassen. Beachten Sie, dass wir im CHAOSS-Projekt den Begriff „Change Request“ (CR) verwenden, um Pull Requests (GitHub), Merge Requests (GitLab), Patches und ähnliche Prozesse zum Mergen von Änderungen in ein Repository einzuschließen, da die verschiedenen Tools hierfür unterschiedliche Namen haben.

Gesamtzustand des Projekts

Die Verbesserung der Projektintegrität für die kritischen Open-Source-Projekte Ihres Unternehmens ist entscheidend, um das mit der Nutzung dieser Projekte verbundene Risiko zu reduzieren. Im Rahmen des CHAOSS-Projekts haben wir Leitfäden für Praktiker und Metriken Dies kann helfen, Bereiche innerhalb von Open-Source-Projekten zu identifizieren, die nicht optimal funktionieren, und Maßnahmen zur Verbesserung dieser Bereiche zu ergreifen. Diese Liste ist nicht vollständig, bietet aber einen guten Ausgangspunkt.

• Organisatorische Beteiligung
• Mitwirkender Nachhaltigkeit
• Reaktionsfähigkeit
• Sicherheit
• Adoption
• Benutzerfreundlichkeit der Dokumentation

Darüber hinaus gibt es in Open-Source-Projekten eine Reihe weiterer wichtiger Rollen, die Ihrem Unternehmen einen Mehrwert bieten und die Projektleistung verbessern können. Diese werden im Anhang ausführlicher behandelt und umfassen unter anderem:

• Triage und Programmmanagement
• Dokumentation
• Kommunikation und Marketing
• Events & Feiertage

Fazit

Um all dies zusammenzufassen, finden Sie hier einen Beispielbericht für die beiden zuvor beschriebenen Open-Source-Projekte Foo und Bar, der als Quartalsbericht bereitgestellt werden kann. Dieser Bericht zeigt den Prozentsatz der von anderen behobenen Fehler und Sicherheitsprobleme sowie die durchschnittliche Zeit für deren Behebung. Die Tabelle unten zeigt eine Aufschlüsselung der Investitionen in Softwareentwickler (SWE) sowie Hinweise zu den als wichtig eingestuften Kategorien.

Das Erzählen der Geschichte und die Kommunikation mit der Führung könnten Beispiele wie diese beinhalten:

• Für Bar haben wir 1 SWE pro Quartal zugeteilt und konnten eine gute Verbesserung der allgemeinen Sicherheit feststellen, da die Zahl der Fehler zurückgeht und alle von uns gemeldeten Fehler behoben werden.
• Für Foo ist die Veröffentlichung von Feature Baz für nächsten Monat geplant. Es sollte unsere Entwicklerproduktivität deutlich steigern. Wir rechnen mit einer Verzögerung von zwei Wochen ab Veröffentlichung, bevor wir es intern einführen können. Wir haben eine strategische Neueinstellung vorgenommen, die uns dabei hilft, dieses Feature voranzutreiben und gleichzeitig unser eigenes Team weiterzubilden, um das Projekt besser zu gestalten.

Ein Leitfaden kann unmöglich alle Aspekte abdecken, die den Wert der Open-Source-Aktivitäten Ihres Unternehmens demonstrieren. Dies ist daher nur ein kleiner Ausschnitt der Möglichkeiten, Open-Source-Investitionen zu verfolgen, mit Zielen zu verknüpfen und gleichzeitig den Wert der Beiträge effektiv zu beschreiben. Dies erfordert die richtige Struktur und die Sicherstellung, dass Ressourcen dort eingesetzt werden, wo sie den größten Nutzen bringen. Struktur und Ressourcenverteilung werden jedoch in fast jeder Situation unterschiedlich sein, da sie von den individuellen Anforderungen Ihres Unternehmens abhängen.

Vorsichtsmaßnahmen und Überlegungen

• Der Nachweis des organisatorischen Werts hängt stark von den Anforderungen Ihres Unternehmens ab. Daher sollten diese Aktivitäten im Lichte der Ziele Ihres Unternehmens interpretiert werden.
• Der Return on Investment (ROI) ist bekanntermaßen schwer zu messen, insbesondere bei Investitionen in Open-Source-Software. Es ist unwahrscheinlich, dass sich ein einheitlicher ROI-Wert ermitteln lässt. Daher ist es wichtig, Geschichten und Beispiele zu erzählen, um Ihrem Unternehmen den Wert Ihrer Open-Source-Bemühungen zu verdeutlichen.

Zusätzliche Lektüre

• Wir haben ein kurzes Video (6 Minuten) wurden diesem Leitfaden auf dem CHAOSS YouTube-Kanal gewidmet.
• CHAOSScast Episode 120: Leitfaden für Praktiker – Den Wert einer Organisation demonstrieren
• KubeCon-Vortrag von Bob Killen: Warum ist das so schwierig? Den Geschäftswert von Open Source vermitteln (Folien und Video) und die Weisser Wal Vortrag vom Linux Foundation Member Summit.
• CHAOSS-Praktikerhandbücher zu Themen wie Verbesserung der Reaktionsfähigkeit, Nachhaltigkeit der Mitwirkenden, organisatorische Beteiligung und Sicherheit.

Mitwirkende

Die folgenden Personen haben zu diesem Leitfaden beigetragen:

• Bob Killen
• Morgenröte
• Justin Gosses
• Ria Schalnat
• Matt Germonprez
• Mike Gif?raw=trueford

Referenzen

• Eghbal, N. (2016). Straßen und Brücken: Die unsichtbare Arbeit hinter unserer digitalen Infrastruktur. New York, NY: Ford Foundation.
• Foster, D. (2018). Zusammenarbeit in fluiden Organisationen verstehen, ein Proximity-Ansatz [Dissertation, University of Greenwich].
• Linåker, J., Link, G., & Lumbard, K. (Oktober 2024). Aufrechterhaltung der Wartungsarbeit für gesunde Open-Source-Softwareprojekte durch menschliche Infrastruktur: Eine Maintainer-Perspektive. In Proceedings des 18. internationalen ACM/IEEE-Symposiums für empirische Softwareentwicklung und -messung (S. 37-48).
• Linux Foundation (2023). Open Source-Betreuer: Erkundung der Menschen, Praktiken und Einschränkungen, mit denen die wichtigsten Open-Source-Softwareprojekte der Welt konfrontiert sind.
• Vargas, Sophia (2023). Was bringt Sie zu Open Source? Wie können Projekte eine nachhaltige Open-Source-Beteiligung fördern? Google Open Source.

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/demonstrating-org-value.md.

Anhang

Es gibt eine Reihe wichtiger Rollen in Open-Source-Projekten, die Ihrem Unternehmen einen Mehrwert bieten und den Erfolg eines Projekts verbessern können. Dazu gehören unter anderem:

• Triage und Programmmanagement
• Dokumentation
• Kommunikation und Marketing
• Events & Feiertage

Triage und Programmmanagement

Ein Produktmanager oder Programmmanager kann dazu beitragen, den Zeitaufwand für Aufgaben zu reduzieren, die eigentlich nicht zum Entwicklungsaufwand gehören und die Ingenieure möglicherweise nicht so effizient erledigen können wie jemand mit Erfahrung im Produkt- und Programmmanagement. Durch die Triage werden wichtige Open-Source-Projektaktivitäten und -Probleme für Ihr Unternehmen deutlich früher erkannt, als wenn Sie nicht beteiligt wären. Durch die Überprüfung eingehender Probleme, die Zuweisung von Labels und Prioritäten sowie die Unterstützung bei der Roadmap-Planung profitiert Ihr Unternehmen von zahlreichen Vorteilen:

• Priorisierte Triage von Problemen und Fehlern
• Verkürzung der Lösungszeit
• Frühzeitiges Bewusstsein für potenziell schwerwiegende Änderungen und Sicherheitsprobleme
• Reduzieren Sie das Risiko der Projektnutzung durch die Verbesserung der allgemeinen Projektintegrität
• Stellt bessere Daten zur Beantwortung von Fragen und zur Verfolgung von Trends bereit.

Wichtige Metriken:

• Verringert Zeit bis zur ersten Antwort bei Problemen und Änderungswünschen
• Verkürzung der Zuweisungszeit
• Verringert Dauer der Problemlösung / Dauer der Änderungsanforderung

Langfristige Gesundheitsmetriken:

• Erhöhtes Engagement und Nachhaltigkeit der Mitwirkenden anhand einer Vielzahl von Kennzahlen (z. B. Anzahl der Mitwirkenden, Projektgeschwindigkeit, Beitragshäufigkeit, Einbehaltung)
• Positive Stimmung zu Problemen/Änderungsanfragen und anderen Kommunikationskanälen

Dokumentation

Viele Menschen verlassen sich beim Einstieg in ein Open-Source-Projekt auf die Dokumentation. Eine gute Dokumentation kann dazu beitragen, Supportanfragen für häufige Fragen oder Probleme zu reduzieren, die durch eine gute Dokumentation vermieden werden können. Insbesondere ein gut dokumentierter Leitfaden für Mitwirkende kann die Einarbeitung neuer Mitarbeiter erleichtern und einen guten Start für einen neuen Mitarbeiterkreis schaffen. Er kann die Akzeptanz und die allgemeine positive Stimmung durch verbesserten Website-Traffic, bessere Auffindbarkeit in Suchmaschinen und andere Webstatistiken steigern. Mitwirkende möchten selten die große anfängliche, aufwändige Arbeit leisten, die Dokumentation von Grund auf neu zu erstellen. Wenn ein Projekt jedoch von Anfang an über eine gute Dokumentation verfügt, sind die Leute viel eher bereit, diese auf dem neuesten Stand zu halten. „Gute Dokumente führen zu besseren Dokumenten.“ Gut dokumentierte Open-Source-Projekte sind für Benutzer leichter zu verstehen und zu nutzen, was die Nachhaltigkeit der Mitwirkenden fördert und Ihrem Unternehmen die folgenden Vorteile bietet:

• Bessere Entwicklererfahrung
• Erhöht die Fähigkeit zur Selbstbedienung / verkürzt die Entwicklungszeit
• Reduzieren Sie das Risiko der Projektnutzung durch die Verbesserung der allgemeinen Projektintegrität

Metriken:

• Weniger Supportanfragen
• Erhöhter Site-Verkehr und zugehörige Site-Metriken

Langfristige Gesundheitsmetriken:

• Vergrößerte neuer Mitwirkender Engagement und Bindung
• Positive Stimmung zu Problemen und Änderungswünschen

Kommunikation und Marketing

Open-Source-Projekten mangelt es oft an Wissen und Fähigkeiten in Bezug auf bewährte Kommunikations- und Marketingpraktiken. Betreuer und Entwickler verfügen nicht immer über die erforderlichen Fähigkeiten, um die richtige Botschaft zu formulieren und Aufmerksamkeit zu erregen. Sie schätzen oft Unterstützung bei Marketing und Öffentlichkeitsarbeit, da sie sich so auf die technischen Aspekte konzentrieren können, die ihnen am besten liegen (Linåker et al., 2024). Ein Beispiel für unklare und überkomplizierte Nachrichtenübermittlung: Die Beschreibung eines Verbesserungsvorschlags lautete ursprünglich: „Dieser KEP schlägt vor, die Mutation von spec.completions für indizierte Jobs zu ermöglichen, wenn spec.completions vor und nach dem Update spec.parallelism entspricht. Das bedeutet, dass spec.completions nur zusammen mit spec.parallelism veränderbar ist.“ Die Beschreibung wurde umformuliert in: „Ermöglicht die automatische Skalierung für indizierte Jobs.“ Durch die Bereitstellung von Ressourcen für Kommunikation und Marketing kann Ihr Unternehmen die folgenden Vorteile erzielen:

• Verbesserte Markenbekanntheit und -assoziation
• Reduzieren Sie das Risiko bei der Projektnutzung, indem Sie die Akzeptanz und Konvertierung zu Mitwirkenden erhöhen
• Frühzeitiges Erkennen potenzieller Breaking Changes

Metrik

• Erhöhter Verkehr auf der Website und zugehörige Site-Metriken
• Erhöhtes soziales Engagement
• Erhöhter Anteil der Stimme

Langfristige Gesundheitsmetriken

• Abzumagern Annahme (z. B. Downloads, Sterne/Forks, Share of Voice)
• Positive Stimmung auf den Kommunikationskanälen

Events & Feiertage

Veranstaltungen dienen vielen Zwecken, von Workshops für neue Mitwirkende zur Unterstützung des Onboardings bis hin zu Gipfeltreffen mit vielen Gesprächen mit hoher Bandbreite, die Entwicklungsblockaden lösen können. Viele Open-Source-Projekte lösen Blockaden und größere Probleme auf Veranstaltungen (Foster, 2018). Die Anwesenheit im Raum kann ein großer Vorteil sein, um sicherzustellen, dass die Bedürfnisse Ihres Unternehmens berücksichtigt werden. Sie eignen sich auch für Workshops und die Schulung neuer Mitwirkender. Veranstaltungen werden oft unterschätzt, tragen aber zum Aufbau eines erfolgreichen Projekts bei und sind wichtig. Ihr Unternehmen profitiert in mehrfacher Hinsicht:

• Workshops können als Onboarding oder zusätzliche Möglichkeiten zur Weiterbildung dienen
• Durch die Anwesenheit im Raum können organisatorische Bedürfnisse berücksichtigt werden
• Reduzieren Sie das Risiko der Projektnutzung durch die Verbesserung der allgemeinen Projektintegrität

Metriken:

• Nachverfolgung der Beiträge der Teilnehmer
• Konvertierungen von Teilnehmern/Mitwirkenden zu Betreuern
• Nicht blockierte Probleme/Funktionen

Langfristige Gesundheitsmetriken:

• Erhöhtes Engagement und Nachhaltigkeit der Mitwirkenden anhand einer Vielzahl von Kennzahlen (z. B. Anzahl der Mitwirkenden, Projektgeschwindigkeit, Beitragshäufigkeit, Einbehaltung)
• Zunahme der Umwandlung von Mitwirkenden in Betreuer. Die CHAOSS Practitioner Guides sind MIT-lizenzierte, dynamische Dokumente, und wir freuen uns über Ihr Feedback und Ihre Anregungen. Sie können Änderungen an diesem Dokument vorschlagen unter: https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/demonstrating-org-value.md.