Sie haben heute wahrscheinlich Linux benutzt – besonders, wenn Sie kein iPhone haben. Und wenn Sie heute im Internet surfen, ist die Wahrscheinlichkeit groß, dass die Website, die Sie besucht haben, auch von Linux bedient wurde.
Linux ist ein Betriebssystem, aber im Gegensatz zu Software wie Microsoft Windows und macOS wurde Linux von einer selbstorganisierten Gemeinschaft von Freiwilligen entwickelt.
Im Laufe der Zeit, mit der Anstrengung von über 10.000 Entwicklern und sich entwickelnden Prozessen, um den Umfang der Arbeit zu verwalten, ist der Linux-Kernel auf insgesamt über 20.000.000 Zeilen Code gewachsen. Er bildet die stabile Grundlage für…
- Jedes Android-Telefon und -Tablet auf der Welt
- 66% der Server weltweit
- 100% der 500 wichtigsten Supercomputer
Diese Technologie stammt nicht von einem orchestrierten Team mit einem dicken Regelwerk und mehreren Managementebenen. Sie ist das Ergebnis einiger sorgfältig ausgewählter und kulturell eingebetteter Richtlinien und eines gemeinsamen Auftrags.
In diesem Beitrag gehe ich der Frage nach, wie eine so grundlegende, komplexe und wichtige Technologie ohne die traditionelle Managementstruktur so effektiv entwickelt werden konnte. Aber zuerst…
- Warum ist der Linux-Kernel so beeindruckend?
- …Und was ist überhaupt so schwer daran, Entwickler zu managen?
- Wie Richtlinien, Prozesse und 15.000.000 Codezeilen dokumentiert werden
- Wie die Kommunikation zwischen Tausenden von Entwicklern gehandhabt wird
- Wie kritische Entscheidungen (nicht) getroffen werden
- Wie die Mitwirkenden sich an einem starken gemeinsamen Ziel orientieren
- Ist dies ein wiederholbarer Prozess?
- Tell the world!
Warum ist der Linux-Kernel so beeindruckend?
Ein Kernel ist das Herzstück eines Betriebssystems. Er ist der Orchestrator aller anderen Softwareprozesse auf Ihrem Computer oder Smartphone, teilt die Ressourcen auf und sorgt dafür, dass Hardware und Software miteinander kommunizieren können.
In den Worten von G. Pascal Zachary kann der Kernel eines Betriebssystems mit „einem Chef des Haushaltspersonals verglichen werden, der so fleißig war, dass er der Familie oben jederzeit, Tag und Nacht, auf Abruf diente und jede Anfrage bearbeitete“. Der Kernel hält die Maschine am Laufen, egal womit sie konfrontiert wird. Es war ein wesentlicher Sprung von der Welt, in der Computer nur eine Anwendung gleichzeitig ausführen konnten, zu der Welt, die wir heute kennen.
Der Linux-Kernel, der auf UNIX basiert, wurde Anfang der 1990er Jahre von Linus Torvalds entwickelt.
Bereits 1991 veröffentlichte Torvalds die erste Version – gerade einmal 10.000 Zeilen Code – und löste mit der oben gezeigten bescheidenen E-Mail-Ankündigung Begeisterung in der Softwareentwicklergemeinde aus.
Mit der Kraft des Internets, das zum ersten Mal in der Geschichte die Zusammenarbeit ermöglichte, stellten Entwickler ihre eigenen Programmierkenntnisse und ihre Testzeit kostenlos zur Verfügung, während die Zahl der Kernel-Benutzer explodierte. Wenn sie experimentierfreudig waren, konnten die Benutzer versuchen, einen Patch zusammenzuschustern, wenn sie einen Fehler entdeckten, und darüber diskutieren, wie die Software verbessert werden konnte.
Wie Eric S. Raymond in seinem Buch über frühe Open-Source-Software, The Cathedral and The Bazaar, darlegt, wuchs Linus Torvalds‘ Management der Kernel-Entwickler zu einer effizienten, sich selbst organisierenden Organisation heran, die mehr als in der Lage war, eines der wohl komplexesten und am meisten genutzten Softwareprodukte der Welt zu produzieren.
In diesem Beitrag betrachte ich die Prozesse und Richtlinien, die sich im Laufe der Jahre als notwendige Unterstützung für das Linux-Kernel-Projekt herauskristallisiert haben.
Wie hat Torvalds als 21-jähriger Informatikstudent ohne formale Prozesse das Kernel-Projekt zu den Höhen geführt, die es erreicht hat…
…Und was ist überhaupt so schwer daran, Entwickler zu managen?
Nach Untersuchungen von Geneca glauben über 75 % der Führungskräfte in Wirtschaft und IT, dass ihre Software-Projekte zum Scheitern verurteilt sind. Die Schwierigkeit, zuverlässige Software zu produzieren und die Entwickler zu führen, hat unzählige Managementbücher, Produktivitätsstudien und Führungskonzepte hervorgebracht.
„Die schiere Komplexität von Software bedeutet, dass es unmöglich ist, jeden Pfad zu testen“, schreibt der CEO von Kynetix, Paul Smyth, auf Finextra. „Eine Softwareanwendung ist wie ein Eisberg – 90% davon sind nicht sichtbar. Die Hauptkomplexität der Anwendung liegt unterhalb der Wasserlinie.“
Jedes Softwareprojekt von signifikanter Größe, ob es sich nun um ein CRM oder ein Betriebssystem wie Microsoft Windows handelt, ist zu groß, um in den Kopf einer einzelnen Person zu passen. Es erfordert das gemeinsame Wissen und die Zusammenarbeit vieler Beteiligter. Das bedeutet, dass die Entwickler an spezialisierten Teilen der Anwendung arbeiten und gleichzeitig verstehen müssen, wie sich ihre Arbeit auf das Ganze auswirkt.
„No one mind can comprehend it all“, bemerkte der Manager eines Teams von 250 Microsoft-Softwareentwicklern, während sie ein Betriebssystem von Grund auf neu entwickelten, laut G. Zachary in Show stoppers! einem Buch, das die Geschichte eines Teams von Microsoft-Softwareentwicklern erzählt, die 1993 um die Fertigstellung von Windows NT rangen.
Je größer das Projekt, desto langsamer können Änderungen umgesetzt werden. Untersuchungen von Steve McConnell belegen dies und zeigen, dass bei Projekten mit mehr als 10.000.000 Zeilen der Code 5-10 mal langsamer geschrieben wird. Darüber hinaus ergab eine Untersuchung der Entwicklungspraktiken von Microsoft, dass auf 1.000 Zeilen Code etwa 10-20 Fehler kommen.
Trotz der Größe des Projekts und der Anzahl der Mitwirkenden geht die Entwicklung des Linux-Kernels schnell vonstatten, und seine große, enthusiastische Nutzerbasis findet Fehler und schreibt Patches, um Verbesserungen schnell bereitzustellen.
In den Anfängen der Entwicklung – etwa 1991 – war es für Torvalds nicht ungewöhnlich, mehr als einen neuen Kernel pro Tag zu veröffentlichen. Jetzt, in einem reiferen Stadium, in dem 80 % der Smartphones und die Mehrheit der Internetserver auf den Kernel angewiesen sind, beträgt der gewünschte Veröffentlichungszeitraum 8 bis 12 Wochen. Bei jeder Veröffentlichung werden durchschnittlich 10.000 Patches von 2.000 Entwicklern in den Kernel eingearbeitet – und das bei über 20.000.000 Codezeilen.
Welche Managementtechniken und -prozesse sind erforderlich, um ein solches Maß an Zusammenarbeit und Produktivität zu erreichen? Nun, sie wurden nicht von einem Abteilungsleiter oder einem Wirtschaftsbuchautor ausgearbeitet. Sie entwickelten sich organisch unter der Leitung des „gütigen Diktators“ Linus Torvalds.
Selbst in seiner Entstehungsphase arbeiteten Hunderte von Freiwilligen am Linux-Kernel mit, die ihre Arbeit direkt an Torvalds zur Überprüfung übermittelten. Wie hat ein schlecht gelaunter, unsozialer Hacker fast zwei Jahrzehnte lang Streitigkeiten, Beiträge und die Kommunikation zwischen Tausenden von Entwicklern in den Griff bekommen?
Wie Richtlinien, Prozesse und 15.000.000 Codezeilen dokumentiert werden
Im Gegensatz zu einer traditionellen Organisation werden neue Kernel-Entwickler nicht strikt in die Gemeinschaft aufgenommen, sondern es wird erwartet, dass sie die einführende Dokumentation vollständig gelesen und verstanden haben. Die Konzentration des Kernel-Projekts auf die Dokumentation war eine Notwendigkeit, sowohl wegen der technischen Komplexität als auch wegen der schieren Anzahl der Entwickler.
Zahlreiche FAQs, Anleitungen und Anfänge finden sich im Dokumentations-Repository des Kernels und noch mehr in Wikis, die von Kernel-Entwicklern in aller Welt erstellt und gepflegt werden.
Die Art und Weise, wie die Dokumentation geschrieben und verbessert wird, spiegelt die Art und Weise wider, wie der Kernel entwickelt wird: gemeinschaftlich, offen und inkrementell.
Durch die Nutzung der Augen und Spezialisierungen einer großen Gruppe von Menschen kann die Dokumentation viel effizienter erstellt, getestet und korrekturgelesen werden, als wenn sie von einem kleineren, engagierten Team erstellt wird. Um Linus‘ Gesetz in Begriffe zu fassen, die ein Redakteur besser versteht: Mit genügend Augen sind alle Tippfehler offensichtlich.
Neben dem Material für den technischen Support hat die Kernel-Entwicklungsgemeinschaft eine Bibliothek von Prozessdokumentationen erstellt, die die menschliche Seite der Zusammenarbeit erleichtern sollen.
Auf der Indexseite von „A guide to the Kernel Development Process“ lautet ein Absatz:
„Der Zweck dieses Dokuments ist es, Entwicklern (und ihren Managern) zu helfen, mit der Entwicklungsgemeinschaft mit einem Minimum an Frustration zu arbeiten. Es ist ein Versuch, die Arbeitsweise dieser Gemeinschaft so zu dokumentieren, dass sie auch für diejenigen zugänglich ist, die mit der Entwicklung des Linux-Kernels (oder der Entwicklung freier Software im Allgemeinen) nicht so vertraut sind.“
Niemand wird mit einem angeborenen Wissen über das Versionskontrollsystem git geboren oder darüber, wie man einen Patch an eine Mailingliste sendet. Deshalb muss der Entwicklungsprozess dokumentiert werden – dieselben grundlegenden Informationen einer Person nach der anderen zu erklären, lässt sich nicht skalieren!
Wie die Kommunikation zwischen Tausenden von Entwicklern gehandhabt wird
Die Gespräche zwischen den Entwicklern fanden in der Öffentlichkeit statt, in den Mailinglisten für die Kernel-Entwicklung. Bis heute ist die E-Mail wegen ihrer Einfachheit das bevorzugte Mittel. Diese Mailinglisten wurden archiviert und organisiert und bildeten einen Korpus lebendiger Dokumentation und Geschichte.
Der Effekt der öffentlichen Kommunikation hat einen ähnlichen Effekt wie die Vorteile der Verwendung eines Tools wie Slack heute – jede Information wird sicher und durchsuchbar gemacht, anstatt zu verdunsten. Um eine solche Informationsflut zu bewältigen, hat das Kernel-Projekt jedoch Kommunikationsrichtlinien entwickelt und diese als Teil der Dokumentation veröffentlicht.
Kommunikation und Zusammenarbeit in einem solchen Ausmaß war vor dem Internet nicht möglich, so dass frühe Projekte wie dieses schnelle und effektive Lösungen für Probleme bei der Verwaltung der Gemeinschaft, der Etikette und der Präsentation des Codes schreiben und verbreiten mussten.
Die Kernel-Dokumentation enthält Regeln für das Einreichen von Patches, so dass es für andere einfacher wird, den beigetragenen Code zu überprüfen, zu bearbeiten und zu testen. Das bedeutet, dass Patches im Klartext gemailt werden müssen, nicht als Anhang. Patches müssen auf ein einziges Mal pro E-Mail beschränkt sein und bestimmte Richtlinien für den Codierungsstil einhalten:
Diese strenge Standardisierung ist für ein so großes Projekt wie den Kernel absolut notwendig, wie für Projekte jeder Größe. Sie hilft Fehler in einem Bereich zu reduzieren, in dem ein einziger Fehler einen Welleneffekt haben kann, der in der Zukunft zu instabilem Code führt, oder die Zeit vieler Tester und Entwickler verschwendet.
Wie kritische Entscheidungen (nicht) getroffen werden
Um Torvalds zu zitieren:
„Der Name des Spiels ist es zu vermeiden, eine Entscheidung treffen zu müssen. Vor allem, wenn Ihnen jemand sagt: „Wählen Sie (a) oder (b), Sie müssen sich wirklich entscheiden“, haben Sie als Manager ein Problem. Die Leute, die Sie leiten, sollten die Details besser kennen als Sie, und wenn sie zu Ihnen kommen, um eine technische Entscheidung zu treffen, sind Sie aufgeschmissen. Sie sind eindeutig nicht in der Lage, diese Entscheidung für sie zu treffen.“ – Dokumentation zur Entwicklung des Linux-Kernels
Das Linux-Projekt hatte nicht nur keine Führungshierarchie, sondern auch klare Regeln und eine Dokumentation, die es ermöglichte, Entscheidungen zu treffen, ohne dass Diskussionen, Debatten oder (viele) Mailinglisten-Flamewars nötig waren. Ein Blick in die Archive wird Ihnen zeigen, dass der Teil mit den Flamewars nicht immer möglich ist, aber was möglich ist, ist eine Politik zu schaffen, die die Last der Entscheidung negiert.
„Der Schlüssel zur Vermeidung großer Entscheidungen ist also, Dinge zu vermeiden, die nicht rückgängig gemacht werden können. Lassen Sie sich nicht in eine Ecke drängen, aus der Sie nicht mehr herauskommen. Eine in die Enge getriebene Ratte mag gefährlich sein – ein in die Enge getriebener Manager ist einfach nur erbärmlich.“
Show Stoppers! zeigt, dass Bill Gates‘ Philosophie ähnlich ist. Er „bewunderte Programmierer und übertrug ihnen ausnahmslos die Leitung von Projekten, bei denen sie sowohl verwalten als auch programmieren konnten, um zu vermeiden, dass professionelle Manager ohne Programmiererfahrung oder mit veraltetem Wissen das Sagen hatten.“
Wie die Mitwirkenden sich an einem starken gemeinsamen Ziel orientieren
Im Fall von Linux, wie bei vielen populären Open-Source-Projekten, ist der Kernel nicht entstanden, nachdem er von einer großen Gruppe von Mitwirkenden gemeinsam entwickelt wurde; vielmehr wurde er schrittweise verbessert, ohne Entscheidungen zu treffen, die die starke Basis der bisherigen Arbeit destabilisieren. Dies passt gut zu Torvalds‘ Philosophie der Entscheidungsfindung im Management, aber auch zu einer Philosophie, die in den Code selbst eingebettet ist.
Linux basiert auf UNIX, einem früheren Betriebssystem, das auf einer Reihe von Zen-ähnlichen Prinzipien beruht. In der UNIX-Philosophie heißt es ausdrücklich:
„Entwirf und entwickle Software, sogar Betriebssysteme, um sie früh auszuprobieren, idealerweise innerhalb von Wochen. Zögern Sie nicht, die ungeschickten Teile wegzuwerfen und neu zu bauen.“
Bei Torvalds und Raymond (der versuchte, den Erfolg von Torvalds‘ Community-Building zu wiederholen) zeigte sich, dass eine frühzeitige und häufige Veröffentlichung dazu beiträgt, die Mitwirkenden um ein spannendes, wachsendes Projekt zu scharen, in dem sie eine Zukunft sehen. Raymond brachte es auf zwei wesentliche Dinge, die ein Projekt unbedingt erfüllen muss, wenn es in die Welt gesetzt wird:
- Laufen lassen
- Potenzielle Mitentwickler (Nutzer) davon überzeugen, dass das Projekt bald zu etwas Großartigem weiterentwickelt werden kann
Mit diesen Prinzipien starten viele der heutigen Startups – auch Process Street:
Oben ist Process Street im Jahr 2014. Melden Sie sich für ein Konto an, um zu sehen, wie weit wir gekommen sind.
Ist dies ein wiederholbarer Prozess?
Oberflächlich betrachtet erscheint das plötzliche Zusammenkommen einer der kompliziertesten menschlichen Schöpfungen wie Alchemie. Nimmt man jedoch die einzelnen Komponenten auseinander, wird ein zugrunde liegender Prozess deutlich. Als Eric S. Raymond The Cathedral and The Bazaar schrieb, war er gleichzeitig mit der Entwicklung eines Open-Source-E-Mail-Programms beschäftigt. Mit dem Open-Source-Projekt versuchte Raymond, die Beteiligung der Gemeinschaft und den Erfolg des Kernel-Projekts zu wiederholen.
Viele der grundlegenden Prinzipien des Bazaar-Modells, wie er es nannte, werden jedem in der Startup-Welt sofort bekannt vorkommen:
- Jedes gute Stück Software beginnt damit, dass es das persönliche Bedürfnis eines Entwicklers befriedigt.
- Die Benutzer als Mitentwickler zu behandeln, ist der einfachste Weg zu schneller Codeverbesserung und effektiver Fehlersuche.
- Frühzeitig veröffentlichen. Veröffentlichen Sie oft. Und hören Sie Ihren Kunden zu.
- Bei einer ausreichend großen Zahl von Betatestern und Mitentwicklern wird fast jedes Problem schnell charakterisiert und die Lösung für irgendjemanden offensichtlich.
- Wenn Sie Ihre Betatester so behandeln, als wären sie Ihre wertvollste Ressource, werden sie darauf reagieren, indem sie zu Ihrer wertvollsten Ressource werden.
- Das nächstbeste Mittel, um gute Ideen zu haben, ist das Erkennen guter Ideen von Ihren Benutzern. Manchmal ist letzteres besser.
- Oftmals entstehen die eindrucksvollsten und innovativsten Lösungen, wenn man feststellt, dass man das Problem falsch verstanden hat.
- Um ein interessantes Problem zu lösen, sollten Sie zunächst ein Problem finden, das Sie interessiert.
- Vorausgesetzt, der Entwicklungskoordinator verfügt über ein Kommunikationsmedium, das mindestens so gut ist wie das Internet, und weiß, wie er ohne Zwang führen kann, sind viele Köpfe zwangsläufig besser als einer.
Kurz gesagt, es ist ein wiederholbarer Prozess. Und einer, der erfolgreich aus der Open-Source-Welt in die Startup-Mentalität übernommen wurde. Er manifestiert sich in Agile, Lean, Six Sigma und den Einstellungen und Strategien, die Startups heute entwickelt haben. Auch wenn es nicht oft im gleichen Gespräch erwähnt wird, hat die Methodik, die sich um frühe Betriebssysteme herum entwickelt hat, viel mit der heutigen Idee der Iteration auf ein Minimum Viable Product gemeinsam.