Lassen Sie sich dies von Lyft-Ingenieur und Envoy-Projektleiter Matt Klein sagen: Solange Sie nicht mehr Bemühungen von außen erfahren würden, als Sie in das Projekt hineinstecken, könnte Open Source ein Fehler sein. [...]
Unternehmenssoftware ist im Allgemeinen Müll. Ich kann diese Zeile schreiben, ohne die Fakten zu überprüfen, und die meisten werden gleichermaßen mit dem Kopf nicken. Aber warum? Warum ist es so schlimm? Laut dem erfahrenen Open-Source-Veteranen Matt Wilson „Weil die Leute, die die Software entwickeln, sie nicht zur Lösung von Problemen einsetzen“. Sie sind Anbieter, keine Endbenutzer.
Als hoffnungsvolles Zeichen könnte jedoch die lang erwartete, von Endbenutzern vorangetriebene Zukunft von Open Source endlich Wirklichkeit werden. Nehmen Sie zum Beispiel Envoy, einen Open-Source-Edge- und Service-Proxy, der von Matt Klein bei Lyft entwickelt wurde. In meinem kürzlichen Gespräch mit Klein argumentierte er, dass Envoy im Gegensatz zu Open-Source-Projekten, die von VC-gestützten Startups hervorgebracht wurden, mit einem eingebauten, „gefangenen Kunden“ aufwartet, der „Sie dazu zwingt, wirklich über Dinge wie die Betriebsqualität nachzudenken und sicherzustellen, dass Sie Funktionen entwickeln, die den Leuten tatsächlich wichtig sind“.
Mit anderen Worten, die Leute, die die Software entwickelten, waren dieselben, die sie zur Lösung von Problemen verwendeten, was zu besserer Software führte. In der Tat bemerkt Klein: „Einer der Hauptgründe, warum Envoy so beliebt wurde, ist, dass er für den Endbenutzer-Fall entwickelt wurde.“
Warum sehen wir also keine erfolgreichere, von Endbenutzern vorangetriebene Open Source? Laut Klein kommt das daher, dass nicht erkannt wird, dass Open Source „verdammt viel Arbeit“ ist, und dass die Kosten und Vorteile nicht klar durchdacht sind.
Wenn Open Sourcing ein „Netto-Negativ“ ist
Glücklicherweise hatte Klein keine Ahnung, wie schwer es sein würde, Envoy außerhalb von Lyft erfolgreich als Open-Source-Projekt zu starten. Er und sein Team verbrachten 2015 damit, Envoy aufzubauen und zu nutzen, um Lyft beim Übergang von einer monolithischen Infrastruktur zu einer auf Mikrodiensten basierenden Infrastruktur zu helfen. Im Frühjahr 2016 war Envoy innerhalb von Lyft ein unbestreitbarer Erfolg.
Zu diesem Zeitpunkt begann das Jucken von Open Source. „Gegen Mitte 2016“, erzählt Klein, „begannen wir ernsthafte Gespräche darüber zu führen, Envoy zu open sourcen, und damals war ich ziemlich naiv, was die weitere Entwicklung betraf.“
Klein hatte bereits mit einigen Open-Source-Projekten herumgespielt, hatte sich aber nie intensiv mit einem Projekt befasst und schon gar kein Projekt gestartet. Doch Klein war neugierig und wollte es versuchen. Die Leitung von Lyft zögerte zunächst („Das geht uns nichts an“), aber Klein blieb hartnäckig. Wie Klein es ausdrückte: „Ich war motiviert, die ganze Arbeit zu machen, und ich dachte, ich hätte verstanden, was diese Arbeit mit sich bringen würde.“ Bald stellte er fest, dass er in der Tat nicht wusste, was diese Arbeit beinhalten würde.
Zwischen der Bereitschaft des Lyft-Managements, Klein eine Chance zu geben, und Kleins Unwissenheit darüber, was diese „Chance“ bedeutete, beschlossen sie, weiterzumachen. Das ist ein Glücksfall für uns alle, die wir heute von dem beeindruckenden Envoy-Projekt profitieren, aber es hat Klein für mindestens ein Jahr ernsthaft ausgelaugt:
Wenn man sich ansieht, was ich 2016 und Anfang 2017 getan habe, um das Projekt einzuleiten und auszubauen, dann hatte es nichts mit Technik zu tun. Es war alles Führungsarbeit, Öffentlichkeitsarbeit, Marketing, Dokumentation usw., und ich habe alles selbst gemacht, und ich hätte mich [dabei] fast umgebracht. Meine Work-Life-Balance im Zeitrahmen Ende 2016/Anfang 2017 war nicht gut. Ich habe im Grunde zwei Jobs gemacht, aber ich war super motiviert, es zu tun. Trotzdem gab es viele Probleme bei dem Versuch, die Lyft-Arbeit mit der Open-Source-Arbeit in Einklang zu bringen.
Ein Open-Source-Projekt zu starten ist wie eine Firmengründung, meint Klein. Ein Großteil der Arbeit ist die gleiche. „Es gibt die PR, das Marketing, und es gibt das, was ich als Einstellung bezeichne“, sagt er, „was die Gewinnung von Beitragenden und Betreuern umfasst. Hinzu kommt die Arbeit, die damit verbunden ist, das Projekt zu dokumentieren und generisch zu gestalten, so dass es auch für diejenigen außerhalb des ursprünglichen Entwicklerteams von Nutzen sein wird.
Es ist eine Menge Arbeit, die Klein dazu bringt, etwas zu sagen, das kontrovers erscheinen könnte:
Für die meisten Leute, die etwas Open Source machen, ist es in Wirklichkeit ein Netto-Negativ. Mit Netto-Negativ meine ich, dass sie, wenn sie nicht darin investieren, wenn sie nicht all diese Dinge [wie PR, Marketing und „Einstellung“] tun, einfach nur etwas über Bord werfen werden.
Was nutzlos ist. Schlimmer noch als nutzlos, wirklich, „weil man mehr ausgibt, als man einnimmt“, fährt er fort.
Es ist einfach, Envoy jetzt anzusehen und zu sagen: „Natürlich war es das wert! Aber Klein und Lyft konnten das 2016 noch nicht sehen. Heute profitiert Lyft davon, dass Dutzende von Menschen aktiv dazu beitragen, Envoy besser zu machen. „Lyft profitiert von Funktionen, von denen wir nie wussten, dass wir sie brauchen würden, aber jetzt werden sie alle von anderen Leuten implementiert und dann benutzen wir sie einfach“, bemerkt Klein. Für all diese zusätzliche Hilfe zahlt Lyft nichts. Aber 2016 musste Klein herausfinden, wie er die Investition in Envoy rechtfertigen konnte, indem er manchmal Funktionen baute, die Lyft gar nicht brauchte, die das Projekt aber für seine aufstrebende Community attraktiver werden ließen.
„Sie fragen also, warum die Leute das nicht auch tun“, sagt er und antwortet damit auf eine Frage, die ich zuvor in unserem Interview gestellt habe. „Weil es eine Menge Arbeit ist“, antwortet er. Und die Vorteile sind nicht super klar. Es ist kein Slam Dunk. Sie wissen nicht, ob Sie gewinnen werden. Und wenn Sie nicht gewinnen, ist es ein Netto-Negativ.“
Warum sollte also jemand so etwas tun, geschweige denn ein Unternehmen, das nicht in der Softwarebranche tätig ist?
Was springt für Lyft dabei heraus?
Warum sollte Lyft diesen „massiven Aufwand“ betreiben, um interne Open-Source-Technologie einzusetzen, die innerhalb des Unternehmens bereits einen Wert hat? Nun, zusätzlich zu dem Potential für bedeutende externe Investitionen gibt es einen immensen Nutzen im Bereich der Rekrutierung. Als Sitz von Envoy sieht Lyft wie ein großartiger Ort für Entwickler aus, um branchendefinierenden Code zu entwickeln. Und für Klein hilft die erfolgreiche Gründung von Envoy auch seiner Karriere. Solche Motivationen sind nicht die gleichen, so Klein, aber sie sind aufeinander abgestimmt: „Ich sage den Leuten, dass sie nicht auf die gleiche Weise ausgerichtet sein müssen, sie müssen nur in die gleiche Richtung ausgerichtet sein“.
Das Problem ist, fährt er fort, dass wir uns in die gleiche Richtung ausrichten können, ohne die „milden Kosten“ abzuschätzen, die damit verbunden sind. Wir können die Kosten für Server oder Ingenieurgehälter bewerten, aber es ist viel schwieriger, die TCO (Total Cost of Ownership) eines erfolgreichen Open-Source-Projekts zu beurteilen:
Sie spekulieren, Sie sagen: „Nun, wenn es erfolgreich ist, bekomme ich einen Einstellungsbonus“. Aber was bedeutet das in monetärer Hinsicht? Niemand hat das bisher modelliert. Oder: „Wenn wir erfolgreich sind, bekommen wir statt des Dreierteams, mit dem wir an diesem Projekt arbeiten, ein zehnköpfiges Team, und die Ingenieure kosten eine halbe Million Dollar pro Jahr. Niemand denkt tatsächlich auf diese Art und Weise streng darüber nach. Egal, was irgendjemand behauptet, es ist nicht wahr.
Da es so schwierig ist, die finanziellen Auswirkungen des Open-Source-Erfolgs und die potenziell enormen Kosten für den Weg dorthin zu modellieren, kommt es wirklich aufs „Bauchgefühl“ an, wenn Unternehmen sich zum Weitermachen entschließen. Aber dasselbe nebulöse Kalkül hält viele davon ab, es überhaupt erst zu versuchen.
Würde Klein, mit all diesem Wissen, ein weiteres Envoy entwickeln? Würde er sich (und seinen Arbeitgeber) den Strapazen des Aufbaus eines Open-Source-Projekts aussetzen? Die Antwort ist… es kommt darauf an.
Die Go/No-Go-Entscheidung läuft auf eine „subjektive Beurteilung der Frage hinaus, ob wir den Markt gewinnen können“. Wenn das nach Geschäftsgesprächen und nicht nach Entwicklergesprächen klingt, ist das beabsichtigt. „Ich bin kein Open-Source-Purist“, betont Klein. „Ich bin ein Kapitalist.“ Als solcher geht Klein an Open Source als „eine Optimierungsübung“ heran, um festzustellen, ob das Open-Source-Projekt „den Markt gewinnen“ kann und daher „von außen Bemühungen erhalten wird, die größer sind als das, was wir hineinstecken“.
Was auf seine Weise wieder Optimismus in das Open-Source-Kalkül einführt, mit dem viele Unternehmen zu kämpfen haben. Jedes Unternehmen geht in dem Bemühen, Kunden zu gewinnen, gewisse Risiken ein. Wenn wir uns Open Source als die gleiche Art von Übung vorstellen, kann es leichter sein, die Kosten für eine gute Umsetzung zu verstehen und zu rechtfertigen.
*Matt Asay schreibt unter anderem für InfoWorld.com.
Be the first to comment