Ein jüngst erschienenes Paper von HBS sorgt in der OSS-Community für Aufsehen, weil es erneut versucht, den tatsächlichen finanziellen Wert von Open-Source-Software zu beziffern. Kurz gesagt: OSS ist mehrere Billionen Dollar wert. Gewinn!
Unabhängig davon, ob Sie die in diesem Paper vorgeschlagene Methodik für richtig halten (und wir haben diesen Punkt in der FOSS Funders-Diskussionsgruppe ausführlich diskutiert), steht fest, dass OSS ein unglaublich wertvolles Wirtschaftsgut ist. Die Frage ist, wie wir diese Tatsache in unseren Organisationen praktisch anwenden. Viele der Unternehmen, mit denen (und für die) wir arbeiten, nehmen den Wert von OSS ernst. Dennoch ist es schwierig, daraus konkrete Ausgaben für OSS selbst abzuleiten.
Eine Stelle, an der sich diese Herausforderung zeigt, ist die Finanzierung für den Aufbau eines Open Source Program Office (OSPO). Oft wird ein OSPO vor allem als Instrument für Philanthropie, Marketing oder Policy-Arbeit positioniert. Auch wenn Unternehmen erkennen, dass die Unterstützung des breiteren Open-Source-Ökosystems wichtig ist, werden solche OSPOs meist als Kostenstellen betrachtet und sind den finanziellen Schwankungen des Geschäfts ausgeliefert. Diese Einordnung macht es leicht, Open-Source-Programme in schwierigen Zeiten zu kürzen.
Um dem entgegenzuwirken, muss das OSPO aus unserer Sicht anders positioniert werden: als Werttreiber statt als Kostenstelle. Aus dieser Perspektive besteht eine der Hauptaufgaben des OSPO darin, zu zeigen, dass seine Arbeit nicht nur geschäftskritisch ist, sondern auch Umsatz fördert und auf das finanzielle Ergebnis der größeren Organisation einzahlt.
Sobald dieses grundlegende Wertverständnis in der gesamten Organisation verankert ist, lässt sich fast paradoxerweise deutlich mehr Förderarbeit leisten. Wie lässt sich also der tatsächliche Dollarwert des OSPO für die Organisation zeigen? In dieser Blogserie erläutern wir, wie wir ein OSPO mit 40 Personen aufgebaut haben. Zunächst sprechen wir darüber, wie wir den Wert des OSS-Teams berechnen. In Teil 2 geht es darum, wie wir diesen Wert kommunizieren, und in Teil 3 skizzieren wir die nichtfinanziellen Vorteile von Beiträgen zu OSS.
Das Spektrum der Greifbarkeit
Wie die Autoren des HBS-Papers räumen wir vorab ein, dass wir nicht wissen, ob dies die richtige Methodik ist oder wie die korrekte Methodik aussieht. Wir wissen jedoch, dass wir irgendeine Methodik brauchen, um den Wert von OSS für unser Unternehmen greifbar zu machen.
Hier ist ein Diagramm, das wir erstellt haben, um das „Spektrum der Greifbarkeit“ zu zeigen, das wir in diesem Artikel beschreiben:
Greifbarer
Eine einfache Möglichkeit, harte Zahlen zu zeigen, ist zu veranschaulichen, wie das OSPO Ausgaben senken kann. Beispiel: Das Unternehmen gab zuvor viel Geld für eine proprietäre Softwarelizenz aus und damit auch für teure Supportverträge. Das OSPO hat diese Gemeinkosten jedoch eliminiert, indem es auf ein gleichwertiges Open-Source-Projekt umgestiegen ist. Das allgemeine Konzept lautet:
- Kosten der früheren proprietären Softwarelizenz = W Dollar/Jahr
- Für die Migration zu OSS erforderlicher Engineering-Aufwand = Y Migrationskosten
- W Dollar Kosteneinsparungen über X Jahre - Y Migrationskosten = Z Dollar Gesamtersparnis
Ein praktisches Beispiel: Wir nutzten ein proprietäres Kompilierungswerkzeug, das uns $500k/Jahr kostete. Es wurde jedoch nicht aktualisiert, obwohl wir diese stattliche Summe zahlten. Stattdessen identifizierten wir ein OSS-Projekt, das im Vergleich zur proprietären Software nahezu funktionsgleich war.
Um die Funktionslücke zu schließen, kontaktierten wir den Entwickler des OSS-Tools und boten ihm einen Vertrag an, um die fehlenden Funktionen zu ergänzen. Wir zahlten zwischen $200-300k, um das OSS-Tool auf Funktionsgleichheit zu bringen (zusätzlich zu den $500k, die wir weiterhin für das proprietäre Tool zahlten).
Als diese Arbeit abgeschlossen war, fiel zusätzlich interner Engineering-Aufwand für die Migration auf das OSS-Tool an. Grob sahen die Gesamtkosten des Projekts im ersten Jahr so aus:
$500k (letztes Jahr der proprietären Lizenz zur Abdeckung der Überschneidung) +
$250k (Funktionsgleichheit des OSS-Tools) +
$400k (interner Migrationsaufwand)
$1.15M (Gesamtkosten im ersten Jahr)
Obwohl die Kosten dieses Prozesses deutlich höher waren als ein Jahrespreis des proprietären Tools selbst, lagen die Kosten im zweiten Jahr im Grunde bei null. Und am Ende des dritten Jahres waren wir im Plus: Wir hatten weniger ausgegeben als die $1.5M, die angefallen wären, wenn wir bei dem proprietären Tool geblieben wären, das keinen Support leisten wollte.
Gewinn, Verlust, Gemeinkosten und Einsparungen sind sehr greifbare Zahlen. In diesem Fall waren die Haupttreiber des Erfolgs die realen Kosteneinsparungen, die wir bereits im zweiten Jahr erzielen konnten, sowie die höheren Gewinne im dritten Jahr. Wenn wir einen solchen Erfolg erzielen, machen wir ihn ganz bewusst sichtbar, denn solche Erfolge lassen sich am einfachsten kommunizieren.
Weniger greifbar / unschärfer
Erschlossene Fähigkeiten und verbesserte Funktionen
Jetzt kommen wir in Bereiche, die etwas unschärfere Berechnungen erfordern.
Nehmen wir unser Beispiel von oben. Obwohl dieses Projekt sehr direkte, greifbare Zahlen lieferte, brachte es uns auch indirekte Vorteile:
- Das OSS-Tool ermöglichte uns die Nutzung unserer neuen (und sehr teuren) Farm aus A100-GPUs. Weil das proprietäre Tool nicht aktualisiert wurde, hatte es die Nutzung unserer eigenen Hardware im Wert von Millionen von Dollar blockiert.
- Noch besser: Wir konnten dem OSS-Tool weiter Funktionen hinzufügen, die es noch schneller und effektiver machten als das ursprüngliche proprietäre Tool.
Beides sind Bonuspunkte in der Kategorie „unscharfe Berechnung“. Sie sind zwar nicht so leicht zu messen, doch der relative Wert dieser beiden Beiträge liegt potenziell bei Millionen oder Dutzenden Millionen Dollar. Wie bewertet man die Möglichkeit, Equipment im Wert von Millionen von Dollar erstmals effektiv zu nutzen? Die genaue Antwort kennen wir nicht, aber wir wissen, dass sie erheblich ist.
Um uns dieser Zahl zu nähern, arbeiteten wir mit der Finanzabteilung zusammen, maßen den relativen Wert der Workloads, die auf diesen A100-GPUs liefen, und setzten einen kleinen Prozentsatz davon als finanziellen Nutzen an. In der Regel sieht diese Zahl, selbst wenn der Prozentsatz klein ist, im Vergleich zu unserer Investition groß aus (vor allem, weil diese Kosten durch das greifbarere Beispiel oben bereits gedeckt wurden!).
Entwicklerproduktivität
Entwicklerproduktivität ist ein weiterer immaterieller, aber wichtiger Vorteil von OSS-Programmen.
Angenommen, wir können ein gravierendes Build-Problem lösen, das durch eine veraltete Komponente in einer OSS-Abhängigkeit verursacht wird, die im gesamten Unternehmen breit genutzt wird. Durch Beiträge zu diesem OSS-Projekt kann das OSPO diese defekte Komponente reparieren und die Builds in allen Engineering-Teams um eine Stunde beschleunigen. So sieht die Rechnung aus, beginnend mit der Anzahl der Builds, die die Teams pro Woche ausführen:
- Die Entwickler führen in ihren lokalen und CI-Umgebungen 500 Builds pro Woche aus
- Der vom Unternehmen finanzierte OSS-Fix spart 15 Minuten pro Build
- Ein Entwickler kostet im Durchschnitt $125/Std. inklusive aller Nebenkosten
- Die Berechnung der Kosteneinsparung lautet also: 125 gesparte Stunden/Woche x $125/Stunde = ~$810K/Jahr an Entwicklerproduktivität
Da diese Zahlen schwer sicher zu belegen sind, empfehlen wir eine konservative Schätzung. Kürzt man die Schätzung um zwei Drittel, sinkt die Zahl auf etwa $270K. So berechnen wir den Dollarwert einer solchen Initiative.
Wichtig ist hier nicht, eine exakte Zahl zu erhalten, sondern das Gespräch mit den Stakeholdern zu führen und darauf hinzuweisen, dass dies zumindest ein Beitrag größer null ist, wahrscheinlich sogar deutlich mehr.
Ein weiterer wichtiger Punkt: Das gilt nur für einen einzelnen Fix. Über ein Arbeitsjahr hinweg kann es viele davon geben. Man sieht leicht, wie selbst sehr konservative Schätzungen dieser Verbesserungen in kurzer Zeit zu erheblichen Dollarwerten anwachsen können.
Am wenigsten greifbar / am unschärfsten
Opportunitätskosten reduzieren
Für viele Unternehmen bringen OSPOs noch weitere Vorteile, etwa die Senkung von Opportunitätskosten.
Ein Beispiel: Die Verbesserung der Time-to-Market ist für viele Unternehmen ein KPI mit hohem Wert. Abgesehen davon, dass durch einen früheren Launch schneller Umsatz entsteht, kann ein First-Mover-Vorteil zusätzlichen Umsatz erschließen, weil der Markt weniger überlaufen ist.
Hier sind zwei Arten, wie dieses Konzept als Wert dargestellt wird:
- Durch den Einsatz von X Ressourcen für Beiträge zu Y OSS-Projekt beschleunigen wir die benötigte Feature-Entwicklung um Z Monate
- Durch den um B Monate früheren Start von Initiative A erzielt das Unternehmen $C entsprechend früher
Marketing
Ebenso können Unternehmen Aufmerksamkeit gewinnen und ihre Botschaft verbreiten, indem sie Projekte sponsern und zur OSS-Community insgesamt beitragen. Es ist schwierig, den positiven Einfluss öffentlicher OSS-Arbeit auf die Marke eines Unternehmens zu bewerten. Doch die Möglichkeit, über eine offene Community zu kommunizieren, ist eindeutig ein Vorteil größer null. Deshalb entscheiden sich so viele junge Startups für Open-Core-Produkte: Der Nutzen, den sie daraus ziehen, dass die Community ihre Botschaft verstärkt, ist einer der Faktoren, die ihnen in der Anfangszeit Aufmerksamkeit verschaffen. Auch hier gilt: Um den Wert für Ihr Unternehmen zu bewerten, braucht es ein sehr „unscharfes“ Gespräch zwischen Ihrer Marketingabteilung und Ihrer Finanzabteilung. Trotzdem ist es ein wichtiges Gespräch.
Mitarbeiterbindung und Recruiting
Schließlich liegen am äußerst unscharfen Ende des Greifbarkeitsspektrums die Gespräche über Mitarbeiterbindung und Recruiting. Auch hier geht es vor allem darum zu zeigen, dass die Zahl nicht null ist. Dazu können Sie addieren:
- Wie viel Geld das Recruiting-Team ausgibt, um neue Mitarbeiter einzustellen
- Welche Kosten durch Fluktuation entstehen
- Den Wert einer besseren Fähigkeit, Talente einzustellen, basierend auf der Arbeit, die das Unternehmen öffentlich geleistet hat
Von dort aus können Sie rechnen und eine konservative Zahl ableiten, die eine verbesserte Bindung abbildet. Ähnlich wie beim Marketing ist dies eine Diskussion mit HR und der Finanzabteilung.
Alles zusammenrechnen
Wichtig bei dieser Übung ist, sicherzustellen, dass all diesen Aspekten ein Dollarwert zugeordnet wird. Idealerweise liegt der Gesamtwert über den tatsächlichen Kosten des OSS-Teams. Nach unserer Erfahrung beträgt der Wert, den wir liefern, ein Vielfaches der Kosten unseres 40-köpfigen Teams.
Entscheidend ist, dass Sie die Gespräche mit Engineering, Marketing, HR und Finanzabteilung anstoßen, damit diese Bereiche den Wert berücksichtigen, den OSS dem Unternehmen bringt. Von selbst werden sie das nicht tun. Wenn Sie in Ihrer Organisation mit solchen Dynamiken kämpfen, helfen wir gern. Melden Sie sich bei uns.