Russ Cox quitte son poste de leader technique de Go

 (groups.google.com)
1 points par GN⁺ 2024-08-02 | 1 commentaires | Partager sur WhatsApp
  • Le projet Go passe d’un leadership centré sur Russ Cox pendant plus de 12 ans à une nouvelle organisation centrée sur Austin Clements et Cherry Mui
  • À partir du 1er septembre 2024, Austin prendra le rôle de leader technique de l’équipe Go de Google et de l’ensemble du projet Go, tandis que Cherry dirigera le cœur de Go, incluant le compilateur, le runtime et les releases
  • Cox estime qu’un leadership unique de longue durée apporte de la stabilité, mais peut réduire l’espace nécessaire à l’émergence de nouveaux leaders, et considère la transition de leadership de Python en 2018 comme un précédent positif
  • Cox ne quitte pas Go et reste un contributeur individuel, participant aux discussions de conception, aux revues de CL, à l’ouverture d’issues, à certains travaux sur la bibliothèque standard et à des présentations comme GoLab
  • À l’avenir, il se concentrera davantage sur Gaby et Oscar pour améliorer la productivité sur le suivi des issues de Go, et cherchera à étendre à d’autres projets des approches utiles aux mainteneurs open source

Transition du leadership de Go

  • À partir du 1er septembre 2024, Austin Clements assumera le rôle de leader technique de Go
    • Cela concerne à la fois l’équipe Go de Google et l’ensemble du projet Go
    • Austin est actuellement le leader technique de la zone aujourd’hui appelée « Go core »
  • Cherry Mui est promue à la tête de la zone Go core
    • Go core inclut la toolchain du compilateur, le runtime et les releases
  • Russ Cox ne quitte pas le projet Go, mais se retire d’un pas du centre de la prise de décision

Pourquoi un changement après 12 ans de leadership

  • Pour Cox, le rôle de leader technique n’est pas une fonction honorifique, mais plutôt un rôle de service
    • Pendant plus de 12 ans à la tête du projet Go, il s’est concentré sur la création des conditions permettant aux membres de l’équipe de faire du bon travail
  • Les grands projets bénéficient d’un leadership stable, mais à un certain moment, ils ont aussi besoin des forces et du regard neuf de nouveaux leaders
  • Cox estime que Go a accumulé suffisamment de stabilité grâce à plus de 12 ans de leadership unique
  • Il considère que le modèle BDFL n’est sain ni pour la personne ni pour le projet
    • Il rend difficile la création d’espace pour de nouveaux leaders
    • Il constitue un point de défaillance unique
    • Il réduit la marge de croissance du projet
  • Python est cité comme exemple d’un projet ayant beaucoup gagné lorsque Guido van Rossum s’est retiré en 2018 pour laisser d’autres personnes prendre la direction

Confiance envers Austin Clements et Cherry Mui

  • Austin travaille sur Go chez Google depuis 2014, et Cherry depuis 2016
  • Cox juge leur discernement ainsi que leur connaissance de Go et des systèmes sur lesquels Go s’exécute remarquables
  • Il s’est souvent appuyé sur Austin et Cherry lorsqu’il fallait aller plus loin sur des questions générales de conception ou sur les détails du compilateur, de l’éditeur de liens et du runtime
  • Les leaders actuels continueront aussi de diriger leurs domaines respectifs
    • Roland Shoemaker continuera de diriger la sécurité de Go
    • Rob Findley et Hana Kim continueront de diriger les outils Go et le support IDE

Le rôle que Russ Cox assumera désormais

  • Cox prévoit de se retirer volontairement des décisions afin de laisser à Austin et aux autres leaders l’espace nécessaire pour passer au premier plan
  • Il restera actif dans Go comme contributeur individuel
    • Participation aux discussions de conception de Go
    • Revue de CL
    • Réponses aux questions liées à l’ancien historique du projet
    • Soutien en cas de besoin
    • Ouverture d’issues et rédaction de CL
    • Travail sur quelques potentielles nouvelles bibliothèques standard
    • Promotion de Go dans l’industrie au sens large
    • Présentation sur Go à GoLab en novembre, en Italie
  • Les détails de la transition ne sont pas encore arrêtés et ont été partagés sur la mailing list pour discussion publique
  • Cox et Austin souhaitent que ce changement ne soit perçu que comme un moyen de rendre le projet Go plus fort et meilleur, sans en faire un grand événement

Un focus qui se déplace vers Gaby et Oscar

  • Cox prévoit de se concentrer davantage à l’avenir sur Gaby and Oscar
  • L’objectif est de produire des contributions utiles dans le suivi des issues de Go afin d’aider les personnes qui travaillent sur Go à être plus productives
  • À travers le travail sur Oscar, il espère trouver des approches utiles aux mainteneurs open source et voir celles-ci adoptées dans d’autres projets
  • Oscar poursuit trois objectifs principaux
    • Construire quelque chose d’utile
    • Apprendre quelque chose de nouveau
    • Tracer une voie pour d’autres projets
  • Ces objectifs sont en continuité avec les ambitions plus larges poursuivies depuis toujours dans Go, ce qui fait d’Oscar une étape naturelle pour Cox

Réactions de la communauté et demande de transparence

  • Daniel Martí cite modules et generics parmi les grands changements et jalons de Go sur les dix dernières années, et estime que Cox a joué un rôle clé dans son succès à long terme
  • Il a aussi proposé, dans le cadre de la discussion sur la transition, des moyens d’améliorer la transparence autour du compilateur et du runtime
  • Cherry Mui a répondu que les comptes rendus de réunion et les permanences seraient une bonne occasion d’améliorer la transparence et la participation entre l’équipe compilateur/runtime de Google et la communauté
    • Une mise à jour sera publiée sur la mailing list dès que la date des prochaines permanences sera fixée
  • Plusieurs participants ont remercié Cox pour ses 12 années de leadership et sa contribution à Go, tout en félicitant Austin et Cherry pour leurs nouveaux rôles

À lire aussi

1 commentaires

 
GN⁺ 2024-08-02
Commentaires sur Hacker News

  • rsc, merci pour tout le travail accompli. Au cours des 12 dernières années, le développement en Go est devenu bien plus agréable grâce au détecteur de conditions de concurrence, au wrapping standardisé des erreurs, aux modules, aux génériques, aux mises à jour de la chaîne d’outils, etc.
    Il reste encore des choses que j’aimerais voir. Personnellement, les types somme, de meilleurs enums/types intervalle, l’immutabilité et la non-nullité figurent sur ma liste de souhaits, mais Go reste malgré tout l’un des écosystèmes les plus agréables dans lesquels j’aie développé

    • La plus grande contribution technique de RSC, à mon avis, est la gestion des versions des modules. C’est absolument fondamental pour un écosystème de langage
      https://research.swtch.com/vgo-intro
    • En voyant non-nilness, je me souviens encore de ce fil
      https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...
    • C’est une bonne liste des éléments qui ont fait de Go un meilleur langage ces dernières années. J’y ajouterais aussi les itérateurs, que Russ a beaucoup poussés récemment
    • Je pense que Go aurait été bien plus populaire s’il avait eu des types nullables ou des types somme dès le départ
    • Il ne faut pas non plus oublier le changement de sémantique de la boucle for traditionnelle à trois clauses : https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...
      À cause de ce changement, je considère que Go 1.22 est en pratique la première version de Go à rompre sérieusement la compatibilité Go 1, même si l’équipe Go officielle ne le reconnaît pas

  • Personnellement, je vois Go comme l’un des projets open source les mieux gérés à ce jour. Respect également à Google pour l’avoir soutenu

    • Je me demande quels éléments permettent de dire qu’un projet est bien géré
    • Je me demande à qui appartient réellement la « propriété » de Go
      En théorie, ce serait une organisation ou un comité indépendant, mais je me demande qui paie effectivement la plupart des personnes qui y travaillent. Google ?
    • On dirait un effet secondaire du fait que Go a échoué dans sa mission de remplacer C++ ou Java, et qu’il est devenu un langage remplaçant Ruby/Python, etc., côté API
      Du coup, l’objectif du projet n’est plus de conquérir le monde, mais correspond désormais à ses utilisateurs, et cette guerre a été reprise par Rust, Zig et d’autres
    • Ne prendre en charge que le comportement de glibc et ignorer à sa guise le standard ELF, voilà sûrement ce qui qualifie un projet comme « le mieux géré ». /s

  • Le passage « je ne crois pas que le modèle BDFL (dictateur bienveillant à vie) soit sain pour une personne ou pour un projet » est intéressant. Les meilleurs projets ont un BDFL, et les meilleurs BDFL semblent sceptiques vis-à-vis de leur propre pouvoir

    • Les personnes compétentes qui ne s’intéressent pas au leadership semblent souvent faire les meilleurs leaders
      À l’inverse, ceux qui veulent devenir leaders pour être connus comme des « leaders » manquent parfois de compétence comme de sens des responsabilités
    • Indépendamment du fait que je sois ou non d’accord avec toute la première partie, il n’est pas très surprenant que les meilleurs BDFL soient sceptiques vis-à-vis de leur propre pouvoir
      À mon avis, le principal avantage d’un pouvoir de décision unilatéral exercé par une seule personne est de contourner les blocages qui apparaissent quand il y a beaucoup de parties prenantes. Dans un projet où le dirigeant se sentirait légitime à renverser des décisions faisant l’objet d’un fort consensus, il serait beaucoup plus difficile de former une communauté suffisamment reconnue
    • Je ne pense pas que ce soit exact. Python avait un BDFL, mais je n’ai pas l’impression qu’il en ait beaucoup bénéficié. Je ne sais pas non plus très bien de quels autres projets vient cette attitude
      À première vue, cela ressemble à une forme de bureaucratie comme une autre, qui réduit peut-être les dramas mais n’améliore pas visiblement la qualité. Par ailleurs, il existe une montagne de projets qui ont échoué parce qu’un propriétaire unique n’était pas assez flexible, mais on estime simplement que ceux-là ne méritent pas d’être discutés
    • Les seules personnes qui devraient avoir du pouvoir sont celles qui n’en veulent pas
      Cela va bien au-delà des projets open source
    • L’idée même de BDFL est une blague, et cela se voit dans le nom
      C’était une expression qui reconnaissait la « réalité du terrain » du rôle de GvR en tant que créateur de Python, pas un principe de gestion de projet conçu sérieusement. C’était une description, pas une prescription, mais le concept a fini par être beaucoup trop réifié

  • rsc, merci infiniment pour tous les efforts consacrés à ce langage qui m’a amené vers l’ingénierie logicielle
    J’ai touché à plusieurs langages de programmation, mais Go me donne toujours l’impression d’être chez moi. L’expérience de développement est excellente, et j’apprécie énormément que le langage et ses créateurs aient défendu sans détour la simplicité et le sens des responsabilités. Je te souhaite bonne chance et le meilleur pour la suite

    • De rien. Merci aussi pour ce commentaire
      Quand nous avons lancé Go, je n’imaginais absolument pas qu’il aurait un impact aussi positif sur la vie des gens et qu’il attirerait de nouvelles personnes vers la programmation et l’ingénierie logicielle. C’est cet impact qui me rend le plus fier

  • Le blog de RSC est vraiment excellent : https://research.swtch.com/

    • Je viens seulement de remarquer que rsc pouvait être l’acronyme de ce blog
    • C’est un blog incroyable. Comme je l’ai déjà dit ici, sa série sur les expressions régulières est d’une qualité folle, et le fait qu’il l’ait simplement mise en ligne pour que tout le monde puisse la lire est un vrai privilège

  • Merci pour toutes les contributions à Go
    En revanche, je ne suis pas d’accord sur un point sans rapport avec Go. Python n’a pas bénéficié du départ de GvR. La nouvelle « direction » est non technique et oppressive, et a fait partir la plupart des vrais contributeurs open source
    Le développement stagne, à l’exception de quelques contributions d’entreprises à la qualité douteuse, l’ambiance est répressive, et ce qui compte vraiment, c’est d’occuper un poste de pouvoir chez Microsoft/Instagram/Bloomberg. Ce n’est pas forcément la faute de ces entreprises. Elles ne se rendent peut-être pas compte que leur générosité est exploitée

  • Rien que gofmt a probablement fait économiser énormément de temps dans le monde entier. Il est en quelque sorte en amont du mouvement qui a poussé pratiquement tous les autres écosystèmes de langage à dire : « bon, faisons simplement du formatage automatique »
    Je n’aime pas ce que les formateurs automatiques font à mon code, mais j’aime ne plus avoir à parler des espaces

    • Fait intéressant, dans tous les autres langages, je déteste les formateurs automatiques et j’utilise des espaces au lieu des tabulations, mais en Go je me suis habitué dès le départ à la façon dont gofmt formate le code
      Ensuite, on finit par apprécier de ne plus devoir y consacrer beaucoup de temps, et au moins pour la plupart des gens, ce n’est pas un problème

  • J’ai découvert aujourd’hui le projet sur lequel il veut se concentrer : https://go.googlesource.com/oscar/+/refs/heads/master/README...
    Il s’agit d’une architecture basée sur les LLM pour aider à maintenir les projets open source. Ça a l’air sympa

  • https://www.youtube.com/watch?v=wwoWei-GAPo — le projet a vraiment parcouru un long chemin depuis cette époque
    Je suis heureux qu’il soit toujours vivant et florissant. En 2009, je ne crois pas que je m’attendais à cela. Sans Russ, je ne pense pas que Go serait là où il est aujourd’hui. Sa contribution au projet a été immense

  • Merci à Russ. Faire du support outillé un élément de premier ordre était révolutionnaire, et cela reste aujourd’hui l’une des caractéristiques les plus marquantes de Go