Es gibt keine einheitliche Definition für den Erfolg von Open-Source-Projekten.
Heutzutage steht jeder auf Open Source. Microsoft hat gerade seine 3D Movie Maker-Software unter einer Open-Source-Lizenz veröffentlicht. Spotify hat eine Reihe von Projekten, die es veröffentlicht hat und zu denen es beiträgt, und hat gerade einen Fonds zur Unterstützung der Betreuer von Projekten angekündigt. Es gibt sogar Game-Engine-Code aus dem Mittelalter (1998), der Open Source ist.
Open Source:Unbedingt lesen
Mit diesen Projekten und Millionen anderer verfügbarer Projekte ist es eine berechtigte Frage, zu fragen … warum? Oder besser gesagt, warum ist die überwiegende Mehrheit dieser Projekte von Bedeutung und für wen? Die meisten Projekte werden schließlich nie Kubernetes sein.
Nach mehr als zwei Jahrzehnten im Open-Source-Bereich wird mir jedoch allmählich klar, dass dies die falsche Frage ist.
Das Firecracker-Beispiel
Nehmen Sie Firecracker, ein Open-Source-Mikrovirtualisierungsprojekt, das AWS 2018 veröffentlichte. Firecracker wurde fast überall als coole Technologie gefeiert … und verschwand dann größtenteils aus der Öffentlichkeit. Ich habe über einige frühe Community-Erfolge geschrieben, aber selbst das (unter anderem Weave Ignite, um die Benutzerfreundlichkeit von Firecracker zu verbessern) kam von einem engen AWS-Partner. Um Firecracker mehr Community-Heft zu verleihen, schlug ich vor, dass AWS Google folgt und die Governance rund um Firecracker öffnet, nicht nur um seinen Code.
AWS hörte nicht zu, aber nicht zum ersten Mal schien meine Meinung keine Rolle zu spielen. (Das ist eine höfliche Art zu sagen, dass ich mich vielleicht geirrt habe.)
Schneller Vorlauf bis 2022, und Firecracker wird leise an vielen coolen Orten eingesetzt. Ich sage „leise“, denn warum sollte irgendjemand seine Infrastruktur von den Dächern schreien? Aber als ich nachfragte, tauchten einige interessante Benutzer auf, wie Stripe, Fly.io, System Initiative und mehr. Natürlich ist es immer noch so, dass die meisten Mitarbeiter von Firecracker bei AWS angestellt sind.
Aber selbst wenn Firecracker eine Community of One (AWS) geblieben wäre, hätte es sich wohl gelohnt. Tatsächlich habe ich das im Wesentlichen argumentiert, als ich für AWS gearbeitet habe, und darauf hingewiesen, dass es klare kundenorientierte Gründe für Open-Source-Firecracker gab, unabhängig von der Beteiligung der Community. Open Source stellte sicher, dass Firecracker gut mit der Linux-Community zusammenspielte, und ermöglichte den Kunden engere „zusammengesetzte Produktgewinne“.
Millionen Feuerwerkskörper
Spielen Sie jetzt dieses Firecracker-Beispiel mal die mehr als hundert Millionen GitHub- (und andere Open-Source-) Repositories aus. Es geht nicht darum, das nächste Kubernetes zu sein. Bei jedem Open-Source-Projekt geht es darum, die Bedürfnisse des einzelnen Entwicklers, eines Unternehmens oder einer breiteren Community zu erfüllen.
Manchmal können diese Bedürfnisse groß sein. In einem Gespräch, das ich mit Lyft Engineering Lead und Envoy-Gründer Matt Klein hatte, betonte er:„Für die meisten Leute, die etwas Open Source machen, ist es eigentlich ein Netto-Negativ“, denn „wenn sie nicht darin investieren, wenn sie es nicht tun all diese Dinge tun [wie PR, Marketing und Einstellung], werden sie nur etwas über die Wand werfen.“ Für Klein trug die signifikante, branchenweite Beteiligung an Envoy dazu bei, dass sich das Projekt für die Investition, die er (und damit Lyft) getätigt hatte, lohnte.
Aber wohl nicht jeder muss diese Art von Rendite erzielen. Im Fall von Firecracker hätte es, wie ich argumentierte, gereicht, den Code offen zu beziehen und die Kunden einfach zusammenarbeiten zu lassen. Für Google hingegen, das wohl versuchte, eine Multicloud-Realität durch Kubernetes voranzutreiben, musste es groß werden. Jedes Projekt hat unterschiedliche Anforderungen und unterschiedliche Erfolgsmaßstäbe.
Sie sind also nicht das nächste Kubernetes? Das ist gut. Bist du auch nicht der nächste Kracher? Auch gut. Für Open-Source-Entwickler ist es wichtig, herauszufinden, was ein gesundes Projekt für Ihre speziellen Bedürfnisse bedeutet, und sich nicht von den Erfolgsdefinitionen anderer ablenken zu lassen.
Offenlegung:Ich arbeite für MongoDB, aber die hier geäußerten Ansichten sind meine .
Quelllink