Goブログ

Go, オープンソース, コミュニティ

Russ Cox
2015年7月8日

ようこそ

[これはGophercon 2015での私のオープニング基調講演のテキストです。ビデオはこちらでご覧いただけます。]

デンバーまでお越しいただきありがとうございます。ビデオをご覧になっている皆様にも感謝いたします。初めてのGophercon参加の方は、ようこそ。昨年お越しいただいた方は、おかえりなさい。このようなカンファレンスを開催するために尽力された主催者の皆様に感謝いたします。ここにいる皆様とお話しできることを嬉しく思います。

私はGoogleのGoプロジェクトおよびGoチームの技術責任者です。その役割はRob Pikeと共有しています。その役割の中で、私はGoオープンソースプロジェクト全体、特にその運営方法、オープンソースであることの意味、そしてGoogle内外の貢献者間の相互作用について、多くの時間を費やして考えています。今日は、私がGoプロジェクト全体をどのように見ているかを皆様と共有し、それに基づいてGoオープンソースプロジェクトがどのように進化していくかを説明したいと思います。

なぜGoなのか？

まず、原点に立ち返る必要があります。なぜ私たちはGoの開発を始めたのでしょうか？

Goはプログラマーの生産性を向上させるための試みです。私たちはGoogleでのソフトウェア開発プロセスを改善したいと考えましたが、Googleが抱える問題はGoogle特有のものではありません。

2つの包括的な目標がありました。

最初の目標は、スケーラブルな並行処理の課題に対応するためのより良い言語を作ることです。スケーラブルな並行処理とは、ネットワークトラフィックをやり取りすることで1000台のバックエンドサーバーを調整するなど、多くの懸念に同時に対処するソフトウェアを意味します。

今日、そのようなソフトウェアはより短い名前で呼ばれています。クラウドソフトウェアです。Goは、クラウドがソフトウェアを実行する前に、クラウド向けに設計されたと言っても過言ではありません。

より大きな目標は、大規模なソフトウェア開発、つまり多くの人々が使用し、共同で作業し、互いに調整が限られた状態で、長年メンテナンスされるソフトウェアの課題に対応するためのより良い環境を作ることです。Googleでは、何千人ものエンジニアがお互いにコードを書いて共有し、可能な限り他の人の作業を再利用し、10年以上の歴史を持つコードベースで作業しています。エンジニアは、他の人が書いたコードや、何年も前に書いたコード（多くの場合、同じことですが）を操作したり、少なくとも見たりすることがよくあります。

Google内部のこの状況は、GitHubのようなサイトで実践されている大規模で現代的なオープンソース開発と多くの共通点があります。このため、Goはオープンソースプロジェクトに非常に適しており、長期にわたって大規模なコミュニティからの貢献を受け入れ、管理するのに役立ちます。

Goの成功の多くは、Goがクラウドソフトウェアに非常に適しており、Goがオープンソースプロジェクトに非常に適しており、そして偶然にも、その両方がソフトウェア業界で人気と重要性を増しているという事実によって説明できると私は信じています。

他の人も同様の観察をしています。ここに2つあります。昨年、RedMonk.comで、Donnie Berkholzは「クラウドインフラストラクチャの新興言語としてのGo」について書き、「[Goの]代表的なプロジェクト…は、クラウド中心であるか、分散システムや一時的な環境を扱うために作られたものである」と述べています。

今年、Texlution.comで、著者は「なぜGolangは成功するように運命づけられているのか」というタイトルの記事を書き、大規模な開発に焦点を当てていることが、おそらくGoogle自体よりもオープンソースに適していると指摘しました。「このオープンソースへの適合性が、ますます多くのGoを目にするようになる理由だと思います…」

Goのバランス

Goはどのようにしてこれらのことを実現するのでしょうか？

どのようにしてスケーラブルな並行処理とスケーラブルなソフトウェア開発を容易にするのでしょうか？

ほとんどの人は、この質問に答える際に、チャネルとゴルーチン、インターフェース、高速ビルド、goコマンド、優れたツールサポートについて語ります。それらはすべて重要な答えの一部ですが、それらの背後にはより広い考え方があると思います。

私はその考え方をGoのバランスとして考えています。ソフトウェアの設計には競合する懸念事項があり、予見されるすべての問題を解決しようとする非常に自然な傾向があります。Goでは、すべてを解決しようとしないことを明確に試みてきました。代わりに、独自のカスタムソリューションを簡単に構築できるように、十分なことだけを行うように努めてきました。

私がGoの選択したバランスを要約する方法はこれです：より少なく。より多くを可能に。

より少なく、しかしより多くを可能にする。

Goはすべてを行うことはできません。私たちはそうしようとするべきではありません。しかし、私たちが努力すれば、Goはおそらくいくつかのことをうまく行うことができます。それらのことを慎重に選択すれば、開発者が簡単に必要なソリューションやツールを構築でき、理想的には他の人が構築したソリューションやツールと相互運用できる基盤を築くことができます。

例

いくつかの例でこれを説明しましょう。

まず、Go言語自体のサイズです。私たちは、可能な限り少ない概念を導入し、大規模な開発者コミュニティのさまざまな部分で相互理解不能な方言が形成される問題を回避するために懸命に取り組みました。Goには、その本質に単純化され、追加される複雑さを正当化する明確な利点がない限り、アイデアは導入されませんでした。

一般的に、Goでうまくやりたいことが100個ある場合、100個の別々の変更を加えることはできません。代わりに、設計スペースを調査して理解し、うまく連携し、それらのことの90個を可能にするいくつかの変更を特定しようとします。言語を肥大化させたり、今日重要に見えるが明日にはなくなるかもしれない特定のユースケースに対処するためだけに複雑さを追加したりすることを避けるために、残りの10個を犠牲にしても構いません。

言語を小さく保つことで、より重要な目標を達成できます。小さくすることで、Goは学習しやすく、理解しやすく、実装しやすく、再実装しやすく、デバッグしやすく、調整しやすく、進化しやすくなります。より少なくすることで、より多くを可能にします。

これは、他の多くの人々のアイデアを拒否することを意味しますが、私たちは私たち自身のアイデアをさらに多く拒否してきたことを保証します。

次に、チャネルとゴルーチンです。並行計算と並列計算をどのように構造化し、調整する必要がありますか？ミューテックスと条件変数は非常に一般的ですが、非常に低レベルであるため、正しく使用するのが困難です。OpenMPのような並列実行フレームワークは非常に高レベルであるため、限られた範囲の問題を解決するためにのみ使用できます。チャネルとゴルーチンは、これら2つの極端の中間に位置します。それら自体では、あまり解決策になりません。しかし、並行ソフトウェアにおける多くの一般的な問題に対するソリューションを可能にするように簡単に配置できるほど強力です。より少なく行うこと、つまり本当に十分なだけ行うことで、より多くを可能にします。

次に、型とインターフェースです。静的型を使用すると、PythonやRubyなどの動的型付け言語にはない、コンパイル時の有用なチェックが可能になります。同時に、Goの静的型付けは、従来の静的型付け言語の反復を大幅に回避し、動的型付け言語のように、より軽量で軽快に感じさせます。これが最初に気づいたことの1つであり、多くのGoの初期採用者は動的型付け言語から来ました。

Goのインターフェースは、その重要な部分です。特に、静的階層を持つJavaやその他の言語の``implements``宣言を省略することで、インターフェースが軽量になり、より柔軟になります。その剛体階層がないため、既存の、関連性のない本番実装を記述するテストインターフェースのような慣用句が可能になります。より少なくすることで、より多くを可能にします。

次に、テストとベンチマークです。ほとんどの言語でテストとベンチマークのフレームワークが不足しているでしょうか？それらの間で合意はありますか？

Goのテストパッケージは、これらのトピックの考えられるすべての側面に対処することを意図していません。代わりに、ほとんどの高レベルツールに必要な基本概念を提供することを意図しています。パッケージには、合格、失敗、またはスキップされるテストケースがあります。パッケージには、実行され、さまざまなメトリクスで測定できるベンチマークがあります。

ここでのより少なくすることは、これらの概念をその本質に減らし、よりリッチなツールが相互運用できるように、共有の語彙を作成しようとする試みです。その合意により、Miki Tebekaのgo2xunitコンバーターや、benchcmpおよびbenchstatベンチマーク分析ツールのような、より高レベルのテストソフトウェアが可能になります。

基本概念の表現について合意があるため、これらの高レベルツールは、オプトインする努力をしたものだけでなく、すべてのGoパッケージで機能し、相互に相互運用します。たとえば、go2xunitを使用することは、これらのツールが競合するテストフレームワークのプラグインである場合のように、benchstatも使用することを妨げるものではありません。より少なくすることで、より多くを可能にします。

次に、リファクタリングとプログラム分析です。Goは大規模なコードベースを対象としているため、ソースコードの自動メンテナンスと更新をサポートする必要があることを知っていました。また、このトピックが大きすぎて、直接組み込むことができないことも知っていました。しかし、やらなければならないことが1つあることを知っていました。他の設定でプログラムの自動変更を試みた私たちの経験では、私たちが直面した最も重要な障壁は、実際には開発者が受け入れられる形式で変更されたプログラムを書き出すことでした。

他の言語では、さまざまなチームが異なるフォーマット規則を使用するのが一般的です。プログラムによる編集が間違った規則を使用している場合、ソースファイルの残りの部分とはまったく似ていないセクションを書き込むか、ファイル全体を再フォーマットして、不必要で不要な差分を引き起こします。

Goにはこの問題はありません。私たちはgofmtを可能にするために言語を設計し、すべてのGoプログラムでgofmtのフォーマットが受け入れられるように懸命に努力し、最初の公開リリースからgofmtがそこにあることを確認しました。Gofmtは、自動変更がファイルの残りの部分に溶け込むような均一性を課します。特定の変更が人によって行われたのか、コンピューターによって行われたのかを判断することはできません。明示的なリファクタリングサポートは構築しませんでした。合意されたフォーマットアルゴリズムを確立することは、独立したツールが開発し、相互運用するための十分な共有ベースでした。Gofmtはgofix、goimports、eg、その他のツールを可能にしました。ここで進んでいるのは始まったばかりだと私は信じています。さらに多くのことが可能です。

最後に、ソフトウェアの構築と共有についてです。Go 1のリリースに向けて、私たちは「go get」として知られるようになったgoinstallを構築しました。このツールは、github.comのようなサイトでインポートパスを解決するための標準的なゼロ構成の方法を定義し、後にHTTPリクエストを行うことで他のサイトのパスを解決する方法も定義しました。この合意された解決アルゴリズムにより、これらのパスに基づいて動作する他のツールが可能になり、特にGary Burd氏が作成したgodoc.orgが有名です。まだ使ったことがない方のために説明すると、任意の有効な「go get」インポートパスに対してgodoc.org/そのインポートパスにアクセスすると、Webサイトがコードをフェッチしてそのドキュメントを表示します。この素敵な副産物として、godoc.orgは公開されているGoパッケージのおおよそのマスターリストとしても機能しています。私たちがやったことは、インポートパスに明確な意味を与えただけです。より少ないことを行い、より多くを可能にするのです。

これらのツール例の多くが、共有された規約を確立することに関するものであることに気づくでしょう。人々はこれをGoが「独断的」であると表現することがありますが、もっと深いことが起こっています。共有された規約の制約に同意することは、相互運用可能な幅広いクラスのツールを可能にする方法です。なぜなら、それらはすべて同じ基本言語を話しているからです。これは、より少ないことを行いながら、より多くを可能にする非常に効果的な方法です。具体的には、多くの場合、リモートインポートやソースファイルの適切なフォーマットなど、特定の概念に関する共通理解を確立するために必要な最小限のことだけを行えば、それらのコアな詳細についてすべてが合意しているため、連携して動作するパッケージやツールを作成できるようになります。

この考えについては後ほどまた戻ります。

なぜGoはオープンソースなのですか？

しかし、まず最初に、先ほど申し上げたように、「より少ないことを行い、より多くを可能にする」というバランスが、より広範なGoオープンソースプロジェクトでの私たちの活動をどのように導いているかを説明したいと思います。そのためには、まずなぜGoがそもそもオープンソースであるのかから始める必要があります。

Googleは、Goに取り組むために私や他の人に給与を支払っています。なぜなら、Googleのプログラマーの生産性が向上すれば、Googleはより迅速に製品を構築し、より簡単に保守できるからです。しかし、なぜGoをオープンソースにするのでしょうか？なぜGoogleはこの利益を世界と共有する必要があるのでしょうか？

もちろん、私たちの多くはGo以前にオープンソースプロジェクトに取り組んでおり、当然のことながらGoがそのオープンソースの世界の一部になることを望んでいました。しかし、私たちの好みはビジネス上の正当な理由にはなりません。ビジネス上の正当な理由は、Goがオープンソースであるのは、それがGoが成功できる唯一の方法だからです。Google内でGoを構築した私たちチームは、このことを最初から知っていました。Goが成功するためには、できるだけ多くの人に利用できるようにする必要があることを知っていました。

閉鎖的な言語は死にます。

言語には、大規模で幅広いコミュニティが必要です。

言語には、多くの人が多くのソフトウェアを作成している必要があります。そのため、特定のツールやライブラリが必要になったとき、そのトピックをあなたよりよく知っていて、それを素晴らしいものにするためにより多くの時間を費やした人がすでに書いている可能性が高いのです。

言語には、多くの人がバグを報告している必要があります。これにより、問題が特定されて迅速に修正されます。ユーザーベースがはるかに大きいため、Goコンパイラは、緩やかにベースとなっているPlan 9のCコンパイラよりもはるかに堅牢で仕様に準拠しています。

言語には、多くの人がさまざまな目的で使用している必要があります。そうすることで、言語が1つのユースケースに過剰適合し、技術環境が変化したときに役に立たなくなるのを防ぐことができます。

言語には、それを学びたいと思う多くの人が必要です。そうすることで、人々が本を書いたり、コースを教えたり、この会議のような会議を開催したりする市場ができます。

GoがGoogle内に留まっていたら、これらのどれも起こりえなかったでしょう。Goは、Google内、または単一の企業や閉鎖的な環境内で窒息してしまったでしょう。

基本的に、Goはオープンでなければならず、Goにはあなたが必要です。Goは、世界中のあらゆる種類のプロジェクトでGoを使用しているすべての人々、皆さんなしには成功できません。

逆に、GoogleのGoチームは、Goコミュニティ全体をサポートできるほど大きくはありません。スケーリングを続けるためには、この「より多く」を可能にしながら、より少ないことを行う必要があります。オープンソースは、そのための大きな要素です。

Goのオープンソース

オープンソースとはどういう意味でしょうか？最小限の要件は、ソースコードをオープンし、オープンソースライセンスの下で利用可能にすることです。そして、私たちはそれを実行しました。

しかし、私たちは開発プロセスも公開しました。Goを発表して以来、私たちはすべての開発を公開し、誰でも参加できる公開メーリングリストで行ってきました。私たちは誰からのソースコードの貢献も受け入れ、レビューします。そのプロセスは、Googleで働いているかどうかにかかわらず同じです。私たちはバグトラッカーを公開で管理し、変更の提案を公開で議論し、開発し、公開でリリースに向けて取り組んでいます。公開されたソースツリーが正式なコピーです。変更は最初にそこで行われます。それらは後でGoogleの内部ソースツリーに取り込まれるだけです。Goにとって、オープンソースであるということは、これがGoogleを超えた、すべての人に開かれた共同作業であることを意味します。

あらゆるオープンソースプロジェクトは、少数の人々、多くの場合1人から始まりますが、Goの場合は3人でした。Robert Griesemer、Rob Pike、Ken Thompsonです。彼らは、Goがどうあるべきか、Goが既存の言語よりも優れていると考えたことについてのビジョンを持っていました。Robertは明日の朝、そのことについて詳しく話します。私が次にチームに加わった人で、それからIan Taylor、そして一人ずつ、私たちは現在に至り、数百人の貢献者がいます。

これまでGoプロジェクトにコードやアイデア、バグ報告を提供してくださった多くの人々に感謝します。今日のプログラムの私たちのスペースで可能な限り全員をリストしようとしました。あなたの名前がそこにない場合は、申し訳ありませんが、ありがとうございます。

私は、これまでの数百人の貢献者が、Goがどうあるべきかという共通のビジョンに向かって取り組んでいると信じています。これらのことを言葉で表現するのは難しいですが、私は以前にビジョンの一部を説明するために最善を尽くしました。「より少ないことを行い、より多くを可能にする」ということです。

Googleの役割

自然な疑問は、他の貢献者と比較して、GoogleのGoチームの役割は何ですか？ということです。私は、その役割は時間の経過とともに変化しており、変化し続けていると信じています。一般的な傾向としては、時間の経過とともに、GoogleのGoチームはより少ないことを行い、より多くを可能にするべきです。

Goが一般に知られる前の非常に初期の頃、GoogleのGoチームは明らかに単独で作業していました。私たちは、仕様、コンパイラ、ランタイム、標準ライブラリの最初のドラフトを作成しました。

しかし、Goがオープンソース化されると、私たちの役割は変化し始めました。私たちがする必要があった最も重要なことは、Goに対する私たちのビジョンを伝えることでした。それは難しく、私たちは今もそれに取り組んでいます。最初の実装は、そのビジョンを伝えるための重要な方法であり、Go 1とさまざまなブログ記事、記事、および私たちが公開した講演につながった開発作業も同様でした。

しかし、昨年のGopherconでRobが述べたように、「言語は完了しました」。今、私たちはそれがどのように機能するか、人々がどのように使用するか、人々が何を構築するかを見る必要があります。今の焦点は、Goが役立つことができる作業の種類を拡大することです。

Googleの主な役割は、コミュニティを可能にし、調整し、変更がうまく連携することを確認し、Goを当初のビジョンに忠実に保つことです。

Googleの主な役割は、「より少ないことを行い、より多くを可能にする」ことです。

先ほど、ターゲットのユースケースの90％程度を可能にする少数の機能を持つ方が、99％または100％に到達するために必要な桁違いに多くの機能を避ける方が良いと述べました。私たちは、私たちがよく知っているソフトウェアの分野でその戦略を適用することに成功してきました。しかし、Goが多くの新しい分野で役立つようになるためには、これらの分野の専門家がその専門知識を私たちの議論に持ち込み、それによって、Goの多くの新しいアプリケーションを可能にする小さな調整を一緒に設計する必要があります。

この変化は、設計だけでなく開発にも当てはまります。GoogleのGoチームの役割は、純粋な開発よりも、ガイダンスの役割にますますシフトし続けています。私は、コードを書くよりもコードレビューを行う時間に多くの時間を費やし、自分でバグ報告を提出するよりもバグ報告を処理する時間の方が多いことは確かです。私たちは、より少ないことを行い、より多くを可能にする必要があります。

設計と開発がより広範なGoコミュニティに移行するにつれて、Goの元の作成者である私たちができる最も重要なことの1つは、GoをGoの状態に保つのに役立つビジョンの整合性です。私たちが達成しなければならないバランスは確かに主観的なものです。たとえば、拡張可能な構文のメカニズムは、Goコードを記述するより多くの方法を可能にする方法ですが、それは異なる方言のない一貫した言語を持つという私たちの目標に反することになります。

私たちは時々、おそらく他の言語コミュニティよりも多く「いいえ」と言わなければなりませんが、そうするときは、建設的かつ敬意を持ってそうするように心がけ、それをGoのビジョンを明確にする機会として捉えます。

もちろん、すべてが調整とビジョンではありません。Googleは今もGoの開発作業に資金を提供しています。Rick Hudsonは本日後半にガベージコレクタの遅延を削減する彼の取り組みについて話し、Hana Kimは明日、モバイルデバイスにGoをもたらす彼女の取り組みについて話します。しかし、私は可能な限り、Googleが資金提供する開発を、他の企業が資金提供する開発や、余暇を利用して個人が貢献する開発と同等に扱うことを明確にしたいと思います。私たちは、次の素晴らしいアイデアがどこから来るかわからないため、これを行います。Goに貢献するすべての人は、意見を聞いてもらう機会があるべきです。

例

時間の経過とともに、Googleの元のGoチームが直接的な開発よりも調整に焦点を当てているという主張について、いくつかの証拠を共有したいと思います。

まず、Go開発への資金源が拡大しています。オープンソースリリース前は、明らかにGoogleがすべてのGo開発の費用を支払っていました。オープンソースリリース後、多くの個人が時間の貢献を開始し、特にGoをこれらの企業にとってより役立つようにすることに関連して、Goに少なくともパートタイムで取り組むために他の企業によってサポートされている貢献者の数をゆっくりと着実に増やしてきました。今日、そのリストには、Canonical、Dropbox、Intel、Oracleなどが含まれています。そしてもちろん、Gopherconやその他の地域ごとのGo会議は、Google以外の人々によって完全に組織されており、Google以外にも多くの企業スポンサーがいます。

次に、元のチーム以外で行われたGo開発の概念的な深さが拡大しています。

オープンソースリリース直後、最初の大きな貢献の1つは、Hector Chuによって開始され、Alex Brainmanなどによって完成したMicrosoft Windowsへの移植でした。さらに多くの貢献者がGoを他のオペレーティングシステムに移植しました。さらに多くの貢献者が、より高速またはより正確、あるいはその両方になるように、数値コードの大部分を書き直しました。これらはすべて重要な貢献であり、非常に感謝していますが、ほとんどの場合、新しい設計は伴いませんでした。

最近では、Aram Hăvărneanuが率いる貢献者のグループが、GoをARM 64アーキテクチャに移植しました。これは、Google以外の貢献者による最初のアーキテクチャポートでした。新しいアーキテクチャのサポートには、一般的に新しいオペレーティングシステムのサポートよりも多くの設計作業が必要になるため、これは重要です。オペレーティングシステム間よりもアーキテクチャ間の方が変動が大きいのです。

別の例としては、過去数回のリリースで、共有ライブラリを使用してGoプログラムを構築するための予備的なサポートが導入されたことです。この機能は多くのLinuxディストリビューションにとって重要ですが、静的バイナリをデプロイするため、Googleにとってはそれほど重要ではありません。私たちは全体的な戦略をガイドするのに役立ってきましたが、設計のほとんどと実装のほとんどすべては、Google以外の貢献者、特にMichael Hudson-Doyleによって行われています。

最後の例は、goコマンドのベンダリングへのアプローチです。私はベンダリングを、外部依存関係のソースコードをツリーにコピーして、それらが消えたり、足元で変化したりしないようにすることと定義します。

ベンダリングは、少なくとも世界の他の地域が直面しているような方法では、Googleが苦しむ問題ではありません。私たちは使用したいオープンソースライブラリを共有ソースツリーにコピーし、コピーしたバージョンを記録し、必要が生じた場合にのみコピーを更新します。ソースツリーには特定のライブラリのバージョンを1つだけ含めることができるというルールがあり、そのライブラリをアップグレードしたい人が、それに依存するGoogleのコードによって期待どおりに機能し続けることを確認する責任があります。このようなことはめったに起こりません。これがベンダリングへの怠惰なアプローチです。

対照的に、Google以外のほとんどのプロジェクトは、より積極的なアプローチを採用し、自動化されたツールを使用してコードをインポートおよび更新し、常に最新バージョンを使用していることを確認しています。

Googleはこのベンダーリング問題について比較的経験が浅いため、解決策の開発をGoogle以外のユーザーに任せていました。過去5年間で、人々は一連のツールを構築してきました。現在使用されている主なものは、Keith Rarick氏のgodep、Owen Ou氏のnut、そしてDave Cheney氏のgb用のgb-vendorプラグインです。

現在の状況には2つの問題点があります。1つ目は、これらのツールがgoコマンドの「go get」とそのままでは互換性がないことです。2つ目は、これらのツール同士でさえ互換性がないことです。これらの問題により、開発者コミュニティはツールごとに分断されています。

昨年の秋、私たちはこれらのツールがすべて「go get」や他のツールと並行して動作できるように、これらのツールの動作方法に関するいくつかの基本事項についてコンセンサスを得るための公開設計議論を開始しました。

私たちの基本的な提案は、すべてのツールがベンダーリング中にインポートパスを書き換えるというアプローチに合意し、「go get」のモデルに適合させること、そして、コピーされたコードのソースとバージョンを記述するファイル形式についてもすべてのツールが合意することで、1つのプロジェクトでさえ異なるベンダーリングツールを一緒に使用できるようにすることでした。もし今日あるツールを使用している場合でも、明日には別のツールを使用できるべきです。

このように共通の基盤を見つけることは、「Lessを実践し、Moreを可能にする」という精神に非常に沿ったものでした。もし、これらの基本的な意味的側面についてコンセンサスを形成できれば、「go get」とこれらのすべてのツールが相互運用できるようになり、Goプログラムがテキストファイルにどのように保存されるかについての合意がGoコンパイラとすべてのテキストエディタの相互運用を可能にするのと同じように、ツール間の切り替えも可能になります。そこで私たちは共通の基盤に関する提案を送りました。

2つの出来事が起こりました。

1つ目は、Daniel Theophanes氏がGitHub上でvendor-specプロジェクトを開始し、新しい提案を提示し、ベンダーリングメタデータの仕様の調整と設計を引き継いだことです。

2つ目は、コミュニティがほぼ全員一致で、ベンダーリング中にインポートパスを書き換えることは現実的ではないと表明したことです。コードを変更せずにコピーできる方が、ベンダーリングははるかにスムーズに機能します。

Keith Rarick氏は、インポートパスを書き換えずにベンダーリングをサポートするために、goコマンドへの最小限の変更に関する代替提案を投稿しました。Keith氏の提案は設定不要で、goコマンドの他の部分のアプローチとうまく適合しました。その提案は、Go 1.5で実験的な機能として出荷され、Go 1.6ではデフォルトで有効になる可能性が高いです。そして、さまざまなベンダーリングツールの作成者が、Daniel氏の仕様が確定次第、採用することに同意したと私は信じています。

その結果、次のGopherconでは、ベンダーリングツールとgoコマンドの間で幅広い相互運用性が実現されるはずです。そして、それを実現するための設計は、元のGoチーム以外の貢献者によって完全に行われました。

それだけでなく、このためのGoチームの提案は本質的に完全に間違っていました。Goコミュニティはそれを非常に明確に私たちに伝えました。私たちはそのアドバイスを受け入れ、今では関係者全員が満足していると信じられるベンダーリングサポートの計画があります。

これは、設計に対する私たちの一般的なアプローチの良い例でもあります。私たちは、十分に理解された解決策について幅広いコンセンサスが得られると感じるまで、Goに何も変更を加えないように努めています。ベンダーリングに関しては、Goコミュニティからのフィードバックと設計が、その地点に到達するために非常に重要でした。

コードと設計の両方がより広範なGoコミュニティからもたらされるというこの一般的な傾向は、Goにとって重要です。あなた方、つまりより広範なGoコミュニティは、Goを使用する環境で何が機能し、何が機能していないかを知っています。Googleの私たちはそうではありません。私たちはますます皆さんの専門知識に頼り、皆さんがGoをより多くの環境で役立つように拡張し、Goの当初のビジョンによく適合する設計とコードを開発するお手伝いをしようとします。同時に、十分に理解された解決策について幅広いコンセンサスが得られるまで待ち続けます。

これにより、私の最後の点にたどり着きます。

行動規範

私は、Goはオープンでなければならず、Goには皆さんの助けが必要だと主張してきました。

しかし、実際にはGoにはすべての人の助けが必要です。そして、誰もがここにいるわけではありません。

Goには、できるだけ多くの人々からのアイデアが必要です。

それを実現するために、Goコミュニティはできる限り包括的で、歓迎的で、親切で、そして敬意を払う必要があります。

Goコミュニティは十分に大きくなったので、関係者全員が期待されることを知っていると仮定するのではなく、私や他の人々は、これらの期待を明示的に書き留めるのが理にかなっていると信じています。Goの仕様がすべてのGoコンパイラに対する期待を設定するのと同様に、オンラインでの議論や、このようなオフラインでの会議での私たちの行動に対する期待を設定する仕様を記述することができます。

優れた仕様と同様に、多くの実装を許可するのに十分な汎用性を持ちながら、重要な問題を特定できるのに十分な具体性が必要です。私たちの行動が仕様を満たさない場合、人々はそれを私たちに指摘することができ、私たちは問題を修正することができます。同時に、この種の仕様は言語仕様ほど正確ではないことを理解することが重要です。私たちは皆、それを適用する際に合理的であるという前提から始める必要があります。

この種の仕様は、多くの場合、行動規範と呼ばれます。Gopherconには行動規範があり、私たちはここにいることでそれを守ることに同意しましたが、Goコミュニティにはありません。私や他の人々は、Goコミュニティには行動規範が必要だと信じています。

しかし、それは何を言うべきでしょうか？

私たちが表明できる最も重要な全体的な声明は、あなたがGoを使用または議論したい場合、あなたは私たちのコミュニティで歓迎されているということです。それが私たちが目指していると信じている基準です。

他の理由がないとしても（そして、明確にするために、他にも優れた理由がありますが）、Goにはできるだけ大きなコミュニティが必要です。行動がコミュニティの規模を制限する限り、それはGoの足を引っ張ります。そして、行動は簡単にコミュニティの規模を制限する可能性があります。

テクノロジーコミュニティ全般、特にGoコミュニティは、率直にコミュニケーションする人々に偏っています。私はこれが根本的なものだとは信じていません。私はこれが不可欠だとは信じていません。しかし、電子メールやIRCのようなオンラインでの議論では特に簡単に行われがちです。そこではプレーンテキストが、対面でのやり取りで得られる他の手がかりや信号によって補完されていません。

たとえば、私は時間に追われているとき、言葉数を減らす傾向があり、その結果、私のメールは急いでいるだけでなく、率直で、せっかちで、さらには無視するように見えることに気づきました。私はそう感じているわけではありませんが、そのような印象を与えることがあり、その印象だけで人々がGoを使用したり貢献したりすることをためらう可能性があります。私がこの行動をとっていることに気づいたのは、一部のGo貢献者が私に個人的なメールを送信して知らせてくれたときでした。今では、時間に追われているときは、書いていることに細心の注意を払い、意図したメッセージを送信していることを確認するために、自然に書くよりも多く書くことがよくあります。

潜在的なユーザーや貢献者を遠ざける、私たちの日常のやり取りの意図的または意図的でない部分を修正することが、Goコミュニティが成長し続けるために私たち全員ができる最も重要なことの1つだと信じています。優れた行動規範は、私たちがそれを実行するのに役立ちます。

私たちは行動規範を作成した経験がないため、既存の行動規範を読んできました。そしておそらく、既存のものを採用し、わずかな調整を加えるでしょう。私が最も気に入っているのは、SpeakUp!という別のプロジェクトから生まれたDjangoの行動規範です。これは、日常のやり取りのためのリマインダーのリストの詳述として構成されています。

「友好的で辛抱強くありましょう。歓迎的でありましょう。思いやり深くありましょう。敬意を払いましょう。言葉を選ぶ際には注意しましょう。意見が合わないときは、その理由を理解しようと努めましょう。」

私は、これが私たちが設定したいトーン、送りたいメッセージ、そして新しい貢献者のために作りたい環境を捉えていると信じています。私は確かに友好的で、辛抱強く、歓迎的で、思いやりがあり、そして敬意を払いたいと思っています。常に正確にそれを実行できるわけではありませんし、もし私がそうでない場合は、役立つメモを歓迎します。私たちのほとんどが同じように感じていると信じています。

私は、人種、性別、障害、その他の個人的な特徴に基づく、またはそれに不釣り合いに影響を与える積極的な排除や、ハラスメントについては言及していません。私にとって、排除的な行動や明示的なハラスメントは、オンラインでもオフラインでも絶対に容認できないということは、私が述べたことから導き出されます。すべての行動規範はこれを明示的に述べており、私たちのものもそうであると期待しています。しかし、日常のやり取りに関するSpeakUp!のリマインダーは、同様に重要な声明だと私は信じています。それらの日常のやり取りについて高い基準を設定することは、極端な行動をはるかに明確にし、対処しやすくすると信じています。

私は、Goコミュニティがテクノロジー業界で最も友好的で、歓迎的で、思いやりがあり、そして敬意を払うコミュニティの1つになれると確信しています。私たちはそれを実現することができ、それは私たち全員にとっての利益と信用になるでしょう。

Andrew Gerrand氏は、Goコミュニティに適切な行動規範を採用する取り組みを主導してきました。もし、提案や懸念事項、行動規範に関する経験がある場合、または参加したい場合は、会議中にAndrewまたは私を見つけてください。金曜日までここにいる場合は、Andrewと私はハックデー中に行動規範の議論のために時間を確保する予定です。

繰り返しますが、次の素晴らしいアイデアがどこから来るのかはわかりません。私たちはできる限りの助けが必要です。私たちは、大きく多様なGoコミュニティが必要です。

ありがとうございました

「go get」を使用してダウンロード可能なソフトウェアをリリースしたり、ブログ記事で洞察を共有したり、メーリングリストやIRCで他の人を助けたりしている多くの人々は、この広範なオープンソース活動の一部、Goコミュニティの一部であると考えています。今日ここにいる誰もが、そのコミュニティの一部です。

今後数日間、時間を割いてGoの使用と拡張に関する経験を共有してくれる発表者の皆様に、事前に感謝いたします。

ここにいる皆様が時間を割いて参加し、質問し、Goがどのように機能しているかを教えてくれることに、事前に感謝いたします。家に帰ったら、学んだことを共有し続けてください。もしあなたが日常業務でGoを使用していなくても、Goで機能していることが他の環境で採用されるのを見るのが大好きです。Goに持ち帰る良いアイデアを常に探しているのと同じです。

ここに来るための努力をして、Goコミュニティの一員になっていただき、改めて皆様に感謝いたします。

今後数日間、以下の点についてご協力ください。私たちがうまくいっている点を教えてください。うまくいっていない点を教えてください。そして、Goをさらに良くするために、皆で協力しましょう。

友好的、辛抱強く、歓迎的、思いやりがあり、敬意を払うことを忘れないでください。

何よりも、カンファレンスを楽しんでください。