Russ Cox tritt als technischer Leiter von Go zurück

 (groups.google.com)
1 Punkte von GN⁺ 2024-08-02 | 1 Kommentare | Auf WhatsApp teilen
  • Das Go-Projekt wechselt nach mehr als 12 Jahren von einer auf Russ Cox ausgerichteten Führung zu einer neuen Struktur mit Austin Clements und Cherry Mui im Zentrum
  • Ab dem 1. September 2024 übernimmt Austin die technische Leitung des Google-Go-Teams und des gesamten Go-Projekts; Cherry leitet den Go core, einschließlich Compiler, Runtime und Releases
  • Cox sieht langfristige Führung durch eine einzelne Person zwar als stabilisierend, aber auch als potenzielle Einschränkung für den Raum, in dem neue Führungskräfte wachsen können; den Führungswechsel bei Python im Jahr 2018 betrachtet er als positives Vorbild
  • Cox verlässt Go nicht, sondern bleibt als individueller Contributor aktiv – unter anderem in Design-Diskussionen, bei CL-Reviews, beim Einreichen von Issues, bei einigen Arbeiten an der Standardbibliothek und mit einem Vortrag auf der GoLab
  • Künftig will er sich stärker auf Gaby und Oscar konzentrieren, um die Produktivität im Go-Issue-Tracker zu steigern und Ansätze, die Open-Source-Maintainern helfen, auf andere Projekte zu übertragen

Führungswechsel bei Go

  • Ab dem 1. September 2024 übernimmt Austin Clements die technische Leitung von Go
    • Das gilt sowohl für Googles Go-Team als auch für das gesamte Go-Projekt
    • Austin ist derzeit technischer Leiter des Bereichs, der heute „Go core“ genannt wird
  • Cherry Mui rückt in die Rolle auf, den Go-core-Bereich zu leiten
    • Go core umfasst die Compiler-Toolchain, die Runtime und Releases
  • Russ Cox verlässt das Go-Projekt nicht, tritt aber aus dem Zentrum der Entscheidungsfindung einen Schritt zurück

Warum nach 12 Jahren Führung ein Wechsel nötig ist

  • Für Cox ist ein technischer Leiter kein Ehrenamt, sondern eher eine Service-Rolle
    • Er hat das Go-Projekt mehr als 12 Jahre lang geleitet und sich darauf konzentriert, Bedingungen zu schaffen, unter denen die Beteiligten gute Arbeit leisten können
  • Große Projekte profitieren von stabiler Führung, brauchen ab einem bestimmten Punkt aber auch die Stärken und frischen Perspektiven neuer Führungskräfte
  • Cox ist der Ansicht, dass Go durch mehr als 12 Jahre Führung durch eine einzelne Person ausreichend Stabilität aufgebaut hat
  • Das BDFL-Modell hält er weder für die Einzelperson noch für das Projekt für gesund
    • Es erschwert, Raum für neue Führungskräfte zu schaffen
    • Es wird zu einem Single Point of Failure
    • Es verringert den Spielraum, in dem das Projekt weiter wachsen kann
  • Python wird als Beispiel genannt, das stark davon profitierte, dass Guido van Rossum 2018 zurücktrat und andere die Führung übernehmen ließ

Vertrauen in Austin Clements und Cherry Mui

  • Austin arbeitet seit 2014, Cherry seit 2016 bei Google an Go
  • Cox bescheinigt beiden ein hervorragendes Urteilsvermögen sowie tiefes Wissen über Go und die Systeme, auf denen Go läuft
  • Bei allgemeinen Designfragen oder wenn er Compiler-, Linker- oder Runtime-Details tiefer verstehen musste, hat er sich auf Austin und Cherry gestützt
  • Auch die bisherigen Leiter führen ihre jeweiligen Bereiche weiter
    • Roland Shoemaker leitet weiterhin die Go-Sicherheit
    • Rob Findley und Hana Kim leiten weiterhin die Go-Tools und die IDE-Unterstützung

Welche Rolle Russ Cox künftig übernimmt

  • Cox wird sich bewusst aus der Entscheidungsfindung zurückziehen, um Austin und anderen Leitern Raum zu geben, nach vorn zu treten
  • Innerhalb von Go bleibt er weiterhin individueller Contributor
    • Teilnahme an Go-Design-Diskussionen
    • CL-Reviews
    • Antworten auf Fragen zur älteren Historie
    • Unterstützung bei Bedarf
    • Einreichen von Issues und Schreiben von CLs
    • Arbeit an einigen möglichen neuen Standardbibliotheken
    • Go-Evangelisierung in der gesamten Branche
    • Vortrag zu Go im November bei der GoLab in Italien
  • Die Details des Übergangs stehen noch nicht fest und wurden für die öffentliche Diskussion auf der Mailingliste geteilt
  • Cox und Austin wünschen sich, dass diese Veränderung nicht wie ein großes Ereignis wirkt – außer insofern, als sie das Go-Projekt stärker und besser macht

Verlagerter Fokus auf Gaby und Oscar

  • Cox will sich künftig stärker auf Gaby and Oscar konzentrieren
  • Ziel ist es, im Go-Issue-Tracker nützliche Beiträge zu erzeugen und Go-Mitarbeitenden zu helfen, produktiver zu arbeiten
  • Durch die Arbeit an Oscar sollen Ansätze gefunden werden, die Open-Source-Maintainern helfen und hoffentlich auch von anderen Projekten übernommen werden
  • Oscars übergeordnete Ziele sind drei Dinge
    • Etwas Nützliches bauen
    • Neues lernen
    • Einen Weg für andere Projekte aufzeigen
  • Diese Ziele knüpfen an die breiteren Ziele an, die Go schon immer verfolgt hat; daher erscheint Oscar für Cox als natürlicher nächster Schritt

Reaktionen der Community und Bitte um Transparenz

  • Daniel Martí nennt modules und generics als große Veränderungen und Meilensteine von Go im vergangenen Jahrzehnt und bewertet Cox’ Rolle als zentral für den langfristigen Erfolg
  • Er schlägt vor, im Zuge der Übergangsdiskussion auch die Transparenz rund um Compiler und Runtime zu erhöhen
  • Cherry Mui antwortet, Meeting-Notizen und Office Hours seien eine gute Gelegenheit, Transparenz und Beteiligung zwischen Googles Compiler-/Runtime-Team und der Community zu erhöhen
    • Sobald der nächste Office-Hours-Termin feststeht, soll ein Update auf der Mailingliste veröffentlicht werden
  • Mehrere Teilnehmende bedanken sich für Cox’ 12-jährige Führung und seine Beiträge zu Go und gratulieren Austin und Cherry zu ihren neuen Rollen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-02
Meinungen auf Hacker News

  • rsc, danke für all die Arbeit über die Jahre. In den letzten 12 Jahren ist die Entwicklung mit Go durch Race Detector, standardisiertes Error Wrapping, Module, Generics, Toolchain-Updates und mehr deutlich angenehmer geworden.
    Wünsche gibt es weiterhin. Persönlich stehen Sum Types, bessere Enums/Range Types, Unveränderlichkeit und Non-nilness auf meiner Wunschliste, aber Go gehört trotzdem zu den angenehmsten Ökosystemen, in denen ich je entwickelt habe.

    • Als RSCs größten technischen Beitrag würde ich Module Versioning nennen. Es ist absolut grundlegend für ein Sprachökosystem.
      https://research.swtch.com/vgo-intro
    • Bei non-nilness erinnere ich mich immer noch an diesen Thread:
      https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...
    • Das ist eine gute Liste der Dinge, die Go in den letzten Jahren zu einer besseren Sprache gemacht haben. Ich würde noch Iteratoren hinzufügen, die Russ zuletzt stark vorangetrieben hat.
    • Ich glaube, Go wäre viel populärer, wenn es von Anfang an nullable Types oder Sum Types gehabt hätte.
    • Auch die Semantikänderung der traditionellen dreiteiligen for-Schleife sollte man nicht vergessen: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...
      Wegen dieser Änderung sehe ich Go 1.22, auch wenn das Go-Team es offiziell nicht anerkennt, tatsächlich als die erste Go-Version, die die Go-1-Kompatibilität ernsthaft gebrochen hat.

  • Persönlich halte ich Go für eines der bisher am besten geführten Open-Source-Projekte. Auch Google gebührt Respekt dafür, dass es das unterstützt hat.

    • Mich würde interessieren, welche Faktoren ein Projekt als gut geführt erscheinen lassen.
    • Mich würde interessieren, wem Go realistisch betrachtet „gehört“.
      Theoretisch wohl einer unabhängigen Organisation oder einem Komitee, aber ich frage mich, wer in der Praxis die meisten Leute bezahlt, die daran arbeiten. Ist es Google?
    • Es wirkt wie eine Nebenwirkung davon, dass Go an der Mission gescheitert ist, C++ oder Java zu ersetzen, und stattdessen zu einer Sprache wurde, die im API-Bereich Ruby/Python usw. ersetzt.
      Dadurch passten die Projektziele nicht mehr zur Welteroberung, sondern zu den Nutzern; diesen Kampf haben dann Rust, Zig usw. übernommen.
    • Nur glibc-Verhalten zu unterstützen und den ELF-Standard nach Belieben zu ignorieren, qualifiziert ein Projekt natürlich als „bestgeführt“. /s

  • Interessant ist die Passage: „Ich glaube nicht, dass das BDFL-Modell (Benevolent Dictator For Life) für Menschen oder Projekte gesund ist.“ Die besten Projekte haben einen BDFL, und die besten BDFLs scheinen ihrer eigenen Macht gegenüber skeptisch zu sein.

    • Es wirkt oft so, als würden kompetente Menschen, die kein Interesse an Führung haben, gerade deshalb die besten Führungspersonen.
      Umgekehrt fehlt Menschen, die Führung übernehmen wollen, weil sie als „Leader“ bekannt sein möchten, manchmal sowohl Kompetenz als auch Verantwortungsbewusstsein.
    • Unabhängig davon, ob ich dem gesamten ersten Teil zustimme, ist es nicht besonders überraschend, dass die besten BDFLs ihrer eigenen Macht skeptisch gegenüberstehen.
      Der wichtigste Vorteil einer Person, die einseitig entscheiden kann, liegt meiner Ansicht nach darin, Blockaden zu umgehen, die bei vielen Stakeholdern entstehen. Wenn ein Projekt es für legitim hält, dass eine Führungsperson Entscheidungen mit starkem Konsens einfach kippt, wird es viel schwieriger, überhaupt eine Community aufzubauen, die groß genug ist, dass Menschen von ihr erfahren.
    • Ich glaube nicht, dass das stimmt. Python hatte einen BDFL, aber ich sehe nicht, dass es davon stark profitiert hätte. Mir ist auch nicht klar, aus welchen anderen Projekten diese Haltung abgeleitet wird.
      Grob betrachtet wirkt es wie eine weitere Bürokratieform, die zwar Drama reduziert, aber die Qualität nicht sichtbar steigert. Gleichzeitig gibt es massenhaft Projekte, die daran gescheitert sind, dass ein einzelner Eigentümer nicht flexibel genug war; nur hält man diese Fälle offenbar nicht für diskussionswürdig.
    • Die einzigen Menschen, denen man Macht anvertrauen sollte, sind Menschen, die keine Macht wollen.
      Das geht weit über Open-Source-Projekte hinaus.
    • Die Idee eines BDFL war von Anfang an ein Witz, das steckt schon im Namen.
      Es war eine Anerkennung der „Realität vor Ort“, in der GvR als Schöpfer von Python stand, und nie ernsthaft als Prinzip für Projektmanagement gemeint. Es war eine Beschreibung, keine Vorschrift, aber das Konzept wurde übermäßig vergegenständlicht.

  • rsc, vielen Dank für all die Mühe, die du in diese Sprache gesteckt hast, die mich zur Softwareentwicklung gebracht hat.
    Ich habe mit mehreren Programmiersprachen gearbeitet, aber Go fühlt sich für mich immer noch wie ein Zuhause an. Die Developer Experience ist hervorragend, und ich schätze sehr, dass die Sprache und ihre Schöpfer ohne Ausflüchte an Einfachheit und Verantwortungsbewusstsein festgehalten haben. Ich wünsche dir viel Glück und Erfolg bei allem, was kommt.

    • Gern geschehen. Und danke für diesen Kommentar.
      Als wir mit Go angefangen haben, hätte ich nie erwartet, dass Go das Leben von Menschen so positiv beeinflussen und neue Leute zur Programmierung und Softwareentwicklung bringen würde. Auf diese Wirkung bin ich am stolzesten.

  • RSCs Blog ist wirklich gut: https://research.swtch.com/

    • Erst jetzt fällt mir auf, dass rsc ein Akronym für diesen Blog sein könnte.
    • Ein großartiger Blog. Ich habe es hier schon früher gesagt: Seine Regex-Serie ist absurd hochwertig, und dass er sie einfach frei zugänglich veröffentlicht hat, ist ein großes Privileg.

  • Danke für alle Beiträge zu Go.
    Einer Sache, die nichts mit Go zu tun hat, stimme ich allerdings nicht zu. Python hat nicht davon profitiert, dass GvR zurückgetreten ist. Die neue „Leadership“ ist untechnisch und tyrannisch und hat die meisten echten Open-Source-Beitragenden vertrieben.
    Die Entwicklung stagniert, abgesehen von einigen Unternehmensbeiträgen fragwürdiger Qualität, die Atmosphäre ist repressiv, und entscheidend ist nur, ob man bei Microsoft/Instagram/Bloomberg in einer Machtposition sitzt. Das muss nicht unbedingt die Schuld dieser Unternehmen sein. Vielleicht wissen sie nicht, dass ihre Großzügigkeit ausgenutzt wird.

  • Allein gofmt dürfte weltweit enorm viel Zeit gespart haben. Im Grunde stand es am Anfang davon, dass jedes andere Sprachökosystem sagte: „Okay, dann machen wir eben Autoformatierung.“
    Ich mag nicht, was Autoformatter mit meinem Code machen, aber ich mag es, nicht mehr über Whitespace reden zu müssen.

    • Interessanterweise mag ich in allen anderen Sprachen Autoformatter nicht und verwende Spaces statt Tabs, aber in Go habe ich mich von Anfang an daran gewöhnt, wie gofmt Code formatiert.
      Danach schätzt man, dass man nicht mehr viel Zeit darauf verwenden muss, und zumindest für die meisten ist es kein Problem.

  • Heute habe ich von dem Projekt erfahren, auf das er sich konzentrieren möchte: https://go.googlesource.com/oscar/+/refs/heads/master/README...
    Es soll eine LLM-basierte Architektur sein, die bei der Pflege von Open-Source-Projekten hilft. Sieht cool aus.

  • https://www.youtube.com/watch?v=wwoWei-GAPo — das Projekt ist seitdem wirklich weit gekommen.
    Ich freue mich, dass es noch lebt und gedeiht. 2009 hätte ich wohl nicht erwartet, dass es so kommen würde. Ohne Russ wäre Go meiner Meinung nach nicht da, wo es heute ist. Sein Beitrag zum Projekt war enorm.

  • Danke an Russ. Tooling-Unterstützung als erstklassiges Element zu behandeln, war revolutionär und ist bis heute eines der herausragendsten Merkmale von Go.