Russ Cox、Goの技術リーダー職を退く

 (groups.google.com)
1 ポイント 投稿者 GN⁺ 2024-08-02 | 1件のコメント | WhatsAppで共有
  • Goプロジェクトは、12年以上続いたRuss Cox中心のリーダーシップから、Austin ClementsとCherry Muiを中心とする新体制へ移行する
  • 2024年9月1日から、AustinがGoogleのGoチームとGoプロジェクト全体の技術リーダーを務め、Cherryはコンパイラ・ランタイム・リリースを含むGo coreを率いる
  • Coxは、長期にわたる単独リーダーシップは安定性をもたらす一方で、新しいリーダーが成長する余地を狭める可能性があると考えており、Pythonの2018年のリーダーシップ移行を前向きな先例と見ている
  • CoxはGoを離れるわけではなく、設計議論、CLレビュー、イシュー提出、一部の標準ライブラリ作業、GoLabでの発表など、個人コントリビューターとして関わり続ける
  • 今後はGabyとOscarにより注力し、Goのイシュートラッカーの生産性向上を図るとともに、オープンソースメンテナーの役に立つ手法を他プロジェクトにも広げたい考え

Goリーダーシップの移行

  • 2024年9月1日から、Austin ClementsがGoの技術リーダーに就任する
    • 対象はGoogleのGoチームとGoプロジェクト全体の両方
    • Austinは現在、「Go core」と呼ばれる領域の技術リーダーを務めている
  • Cherry MuiはGo core領域を率いる役割に昇格する
    • Go coreにはコンパイラツールチェーン、ランタイム、リリースが含まれる
  • Russ CoxはGoプロジェクトを離れないが、意思決定の中心からは一歩退く

12年のリーダーシップ後に交代が必要な理由

  • Coxにとって技術リーダーは名誉職ではなく、奉仕の役割に近い
    • 彼は12年以上にわたりGoプロジェクトを率い、メンバーが良い仕事をできる条件を整えることに注力してきた
  • 大規模プロジェクトは安定したリーダーシップの恩恵を受けるが、ある時点では新しいリーダーの強みや新鮮な視点も必要になる
  • Coxは、Goは12年以上の単独リーダーシップを通じて十分な安定性を築いたと判断している
  • BDFLモデルは、個人にとってもプロジェクトにとっても健全ではないと見ている
    • 新しいリーダーのための余地を作りにくい
    • 単一障害点になる
    • プロジェクトがさらに成長する余地を狭める
  • Pythonは、Guido van Rossumが2018年に退き、他の人たちが率いるようになったことで大きな利益を得た事例として挙げられている

Austin ClementsとCherry Muiへの信頼

  • Austinは2014年から、Cherryは2016年からGoogleでGoに取り組んできた
  • Coxは、2人の判断力と、GoおよびGoが動作するシステムに関する知識を高く評価している
  • 一般的な設計上の問いや、コンパイラ、リンカ、ランタイムの詳細をより深く理解する必要があるとき、AustinとCherryを頼ってきた
  • 既存のリーダーたちもそれぞれの領域を引き続き率いる
    • Roland Shoemakerは引き続きGoセキュリティを率いる
    • Rob FindleyとHana Kimは引き続きGoツールとIDEサポートを率いる

今後Russ Coxが担う役割

  • Coxは、Austinや他のリーダーたちが前面に出られる余地を作るため、意思決定から意識的に一歩引く予定
  • Goの中では引き続き個人コントリビューターとして活動する
    • Goの設計議論への参加
    • CLレビュー
    • 古い履歴に関する質問への回答
    • 必要なときの支援
    • イシュー提出とCL作成
    • いくつかの新しい標準ライブラリ候補の作業
    • 業界全体でのGoの普及活動
    • 11月にイタリアで開催されるGoLabでのGo関連発表
  • 移行の詳細はまだ決まっておらず、公開で議論するためにメーリングリストで共有された
  • CoxとAustinは、今回の変化がGoプロジェクトをより強く、より良くする以外の大きな出来事には見えないことを望んでいる

GabyとOscarへ移る注力先

  • Coxは今後、Gaby and Oscarにより多くの時間を割く予定
  • 目標は、Goのイシュートラッカーで有用な貢献を生み出し、Goの開発者たちがより生産的に働けるよう支援すること
  • Oscarの取り組みを通じて、オープンソースメンテナーに役立つ方法を見つけ、それが他のプロジェクトでも採用されることを期待している
  • Oscarの大きな目標は3つある
    • 役に立つものを作る
    • 新しいことを学ぶ
    • 他プロジェクトのための道筋を描く
  • これらの目標は、Goでこれまで常に追求してきたより広い目標とつながっており、OscarはCoxにとって自然な次のステップに見えている

コミュニティの反応と透明性向上の要望

  • Daniel Martíは、この10年間のGoの大きな変化と節目としてmodulesとgenericsを挙げ、Coxが長期的成功において重要な役割を果たしたと評価した
  • 彼は、移行に関する議論とあわせて、コンパイラ・ランタイム関連の透明性を高める方法を提案した
  • Cherry Muiは、議事録とオフィスアワーはGoogleのコンパイラ・ランタイムチームとコミュニティの間の透明性と参加を高める良い機会になると答えた
    • 次回のオフィスアワーの日程が決まり次第、メーリングリストで更新を案内する予定
  • 複数の参加者が、Coxの12年にわたるリーダーシップとGoへの貢献に感謝を示し、AustinとCherryの新しい役割を祝福した

関連記事

1件のコメント

 
GN⁺ 2024-08-02
Hacker Newsのコメント

  • rsc、これまでのあらゆる仕事に感謝。過去12年間で、Go の開発は競合状態検出器、標準化されたエラーラッピング、モジュール、ジェネリクス、ツールチェーン更新などによってずっと楽しくなった
    まだ望むものは残っている。個人的には合併型、より良い列挙型/範囲型、不変性、nil 不可性がウィッシュリストにあるけれど、それでも Go はこれまで開発してきた生態系の中で最も楽しい部類だ

    • RSC の最大の技術的貢献としてはモジュールのバージョン管理を挙げたい。言語エコシステムにとって絶対的に根本的な要素だ
      https://research.swtch.com/vgo-intro
    • non-nilness を見て、いまだにこのスレッドを覚えている
      https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...
    • ここ数年で Go をより良い言語にした要素がよくまとまった一覧だ。ここに、Russ が最近強く推し進めたイテレータも加えたい
    • Go が最初からnullable 型や合併型を持っていたら、はるかに人気が高かった気がする
    • 伝統的な3節の for ループの意味変更も忘れてはいけない: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...
      この変更のせいで、Go 1.22 は Go 公式が認めなくても、実際には Go 1 互換性を深刻に壊した最初の Go バージョンだと思う

  • 個人的には、Go はこれまでで最もよく管理されたオープンソースプロジェクトの一つだと思う。これを支えた Google にも敬意を表したい

    • よく管理されたプロジェクトだと見なせる要素が何なのか気になる
    • 現実的に Go の「所有権」は誰にあるのか気になる
      理論上は独立団体や委員会のようなものだろうけれど、実際に作業している人たちの大半のコストを誰が払っているのか知りたい。Google なのだろうか？
    • Go は C++ や Java を置き換えようとしていた任務には失敗し、API 側で Ruby/Python などを置き換える言語になった副作用のように見える
      その結果、プロジェクト目標がもはや世界征服ではなくユーザーとの適合になり、その戦いは Rust や Zig などが持っていったようなものだ
    • glibc の動作しかサポートせず ELF 標準は勝手に無視するのが本当に「最高に管理された」プロジェクトの資格なんだろうね。/s

  • 「BDFL（慈悲深い終身独裁者）モデルが人やプロジェクトに健全だとは思わない」というくだりが興味深い。最高のプロジェクトにはBDFLがいて、最高の BDFL たちは自分の権力に懐疑的なようだ

    • リーダーシップに関心のない有能な人たちが、むしろ最高のリーダーになることが多いように見える
      逆に「リーダー」として知られたくてリーダーになる人たちは、能力も責任感もない場合がある
    • 前半全体に同意するかは別として、最高の BDFL が自分の権力に懐疑的なのはそれほど驚きではない
      一人が一方的に決められる権限の主な利点は、利害関係者が多いときに生じる膠着状態を回避できる点だと思う。強い合意がある決定をリーダーが正当に覆してよいと感じるプロジェクトなら、人々が認識できるほどのコミュニティが形成されるのはずっと難しいはずだ
    • その話が正しいとは思わない。Python には BDFL がいたが、大きな利益を得たようには見えない。この態度がどんな他のプロジェクトから出てきたものなのかもよく分からない
      大まかに見れば、ドラマは減らすだろうが品質を目に見えて高めるわけではない、他の官僚制に似た形に見える。一方で、単一オーナーが十分に柔軟でなくて失敗したプロジェクトは山ほどあるが、そういうものは議論に値しないと見なされがちなだけだ
    • 権力を持つに値するのは権力を欲しがらない人だけだ
      これはオープンソースプロジェクトをはるかに超える話だ
    • BDFL という発想自体がジョークで、そのことは名前にも表れている
      GvR が Python 創始者として担っていた「現場の現実」を認めた表現であって、プロジェクト管理の原則として真剣に意図されたものではなかった。処方ではなく記述だったのに、その概念が過度に実体化されてしまった

  • rsc、この言語に注いでくれたすべての努力に本当に感謝する。自分をソフトウェアエンジニアリングへ導いてくれた言語だ
    いろいろなプログラミング言語に触ってきたけれど、Go は今でも家のように感じる。開発体験が素晴らしく、言語とその作者たちがシンプルさと責任感を言い訳なく守ってきた点を本当に高く評価している。これからのすべての仕事に幸運と良い結果を祈る

    • どういたしまして。このコメントにも感謝します
      Go を始めたとき、Go が人々の人生にこれほど前向きな影響を与え、新しい人たちをプログラミングやソフトウェアエンジニアリングに引き込むとはまったく予想していなかった。その影響こそが最も誇りに思っている部分だ

  • RSC のブログは本当に素晴らしい: https://research.swtch.com/

    • 今になって初めて、rsc がそのブログの頭字語になり得ることに気づいた
    • とてつもないブログだ。前にもこのサイトで言ったが、彼の正規表現シリーズは信じられないほど質が高く、それを誰でも見られるようにただ公開してくれているのは大きな特権だ

  • Go へのすべての貢献に感謝する
    ただし Go とは無関係な一点には同意しない。Python は GvR が退いたあと利益を得ていない。新しい「リーダーシップ」は非技術的で抑圧的で、本物のオープンソース貢献者の大半を去らせてしまった
    開発は、品質の疑わしい一部企業からの貢献を除けば停滞しており、雰囲気は抑圧的で、重要なのは Microsoft/Instagram/Bloomberg で権力ある立場にいるかどうかだけだ。必ずしもこれらの企業のせいではないかもしれない。自分たちの寛大さが悪用されていることに気づいていないだけかもしれない

  • gofmt だけでも、世界中で莫大な時間を節約したはずだ。事実上、他のすべての言語エコシステムに「よし、もう自動フォーマットしよう」と言わせた源流にある
    自動フォーマッタが自分のコードにすることは嫌いだが、もう空白について話さなくてよくなったのはいい

    • 興味深いことに、他のほとんどすべての言語では自動フォーマッタを嫌い、タブではなくスペースを使うのに、Go では最初から gofmt がコードを整形するやり方に慣れる
      そうなると、もうそこに多くの時間を使わなくてよいことをありがたく思うようになり、少なくとも大半の人には問題にならない

  • 今日、彼が注力しようとしているプロジェクトを知った: https://go.googlesource.com/oscar/+/refs/heads/master/README...
    オープンソースプロジェクトの保守を助けるLLM ベースのアーキテクチャとのこと。面白そうだ

  • https://www.youtube.com/watch?v=wwoWei-GAPo — このときからプロジェクトは本当に遠くまで来た
    まだ生きていて繁栄しているのがうれしい。2009 年にはこうなるとは期待していなかった気がする。Russ がいなければ Go は今の位置まで来られなかったと思う。プロジェクトへの彼の貢献は計り知れない

  • Russ に感謝する。ツール支援を一級の要素として据えたのは革命的で、今でも Go の最も際立った特徴だ