ようこそ

[これはGophercon 2015での私のオープニング基調講演の原稿です。ビデオはこちらから入手できます。]

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

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

なぜGoなのか？

始めるには、最初に戻る必要があります。なぜGoの開発を始めたのでしょうか？

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

2つの主要な目標がありました。

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

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

より大きな目標は、スケーラブルなソフトウェア開発の課題に対応するためのより良い環境を作ることです。多くの人が共同で作業し、使用し、限られた連携で長年保守されるソフトウェアです。Googleでは、何千人ものエンジニアが互いにコードを書き、共有し、自分の仕事をこなし、他人の仕事を可能な限り再利用し、10年以上にわたる歴史を持つコードベースで作業しています。エンジニアはしばしば、他の人が書いたコード、あるいは何年も前に自分が書いたコードを扱ったり、少なくとも見たりしますが、これは多くの場合同じことを意味します。

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

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

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

今年、Texlution.comの著者は「Go言語が成功する運命にある理由」というタイトルの記事を書き、この大規模開発への焦点は、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の`testing`パッケージは、これらのトピックのあらゆる側面に対処することを意図していません。代わりに、ほとんどの高レベルなツールに必要な基本概念を提供することを意図しています。パッケージには、合格、失敗、またはスキップされるテストケースがあります。パッケージには、実行され、さまざまなメトリックで測定できるベンチマークがあります。

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

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

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

他の言語では、チームごとに異なる書式設定規則を使用することが一般的です。プログラムによる編集が間違った規則を使用すると、ソースファイルの一部がファイルの残りの部分とまったく異なるように見えるか、ファイル全体が再フォーマットされ、不必要で望ましくない差分が発生します。

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

最後に、ソフトウェアの構築と共有。Go 1のリリースに向けて、私たちは`goinstall`を構築しました。これは私たちが「go get」として知っているものになりました。このツールは、github.comのようなサイトでインポートパスを解決するための標準的なゼロ設定の方法を定義し、その後、HTTPリクエストを行うことで他のサイトのパスを解決する方法を定義しました。この合意された解決アルゴリズムにより、それらのパスを使って動作する他のツールが可能になり、最も注目すべきはGary Burdによるgodoc.orgの作成です。使用したことがない方のために説明すると、有効な「go get」インポートパスに対してgodoc.org/the-import-pathにアクセスすると、ウェブサイトがコードを取得し、そのドキュメントを表示してくれます。これの良い副次効果として、godoc.orgが公開されているGoパッケージの大まかなマスターリストとして機能しています。私たちはインポートパスに明確な意味を与えただけです。より少なく、より多くを可能に。

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

そのアイデアについては後でまた触れます。

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

しかしその前に、先ほども言ったように、私が「より少なく、より多くを可能に」というバランスが、より広範なGoオープンソースプロジェクトにおける私たちの仕事をどのように導いているかを説明したいと思います。そのためには、まずGoがそもそもなぜオープンソースであるのかから始める必要があります。

Googleは私や他の人にGoの仕事をするために給与を払っています。なぜなら、Googleのプログラマーがより生産的であれば、Googleは製品をより速く構築し、より簡単に保守できるからです。しかし、なぜGoをオープンソースにするのでしょうか？なぜGoogleはこの恩恵を世界と共有すべきなのでしょうか？

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

閉鎖的な言語は廃れます。

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

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

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

言語には、多くの人々が多くの異なる目的で使用する必要があります。そうすれば、言語が1つのユースケースに過度に適合しすぎて、技術環境が変化したときに役に立たなくなることがありません。

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

GoがGoogleの中に留まっていたら、これらは何も起こりませんでした。GoはGoogleの中、あるいは単一の会社や閉鎖された環境の中で窒息していただろう。

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

順番に、GoogleのGoチームは、Goコミュニティ全体をサポートするのに十分な大きさには決してなり得ません。規模を拡大し続けるためには、より少なくすることで、このすべての「より多く」を可能にする必要があります。オープンソースは、その大きな部分を占めています。

Goのオープンソース

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

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

どんなオープンソースプロジェクトも少数の人々、しばしば一人から始まりますが、Goの場合はロバート・グリーセマー、ロブ・パイク、ケン・トンプソンの三人でした。彼らはGoがどうあるべきか、既存の言語よりもGoが何をもっとうまくできるかというビジョンを持っており、ロバートが明日の朝にそれについて詳しく話すでしょう。私がチームに加わった次の人物で、次にイアン・テイラー、そして一人ずつ、私たちは今日に至り、何百人もの貢献者がいます。

これまでにGoプロジェクトにコード、アイデア、バグレポートを貢献してくださった多くの方々に感謝いたします。本日のプログラムでは、可能な限りすべての方の名前を記載しようと試みました。もしあなたのお名前が掲載されていなくても、申し訳ありませんが、心より感謝申し上げます。

これまでの何百人もの貢献者が、Goが何であるかという共通のビジョンに向かって働いていると私は信じています。これらのことを言葉にするのは難しいですが、私は先にそのビジョンの一部を説明するために最善を尽くしました。「より少なく、しかしより多くを可能に」。

Googleの役割

自然な疑問として、「他のコントリビューターと比較して、GoogleのGoチームの役割は何ですか？」というものがあります。私はその役割が時間の経過とともに変化しており、今後も変化し続けると信じています。一般的な傾向としては、時間の経過とともにGoogleのGoチームは「より少なく、しかしより多くを可能に」していくべきだということです。

Goが一般に知られる前のごく初期の頃は、GoogleのGoチームは明らかに独自に活動していました。仕様、コンパイラ、ランタイム、標準ライブラリなど、すべてを私たちが最初に草稿しました。

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

しかし、ロブが去年のGopherconで言ったように、「言語は完成した」。今度は、それがどのように機能するか、人々がどのようにそれを使うか、人々が何を構築するかを見る必要があります。現在の焦点は、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つのツールを使用している場合でも、明日別のツールを使用できるはずです。

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

2つのことが起こりました。

まず、Daniel Theophanesは新しい提案でGitHubにベンダー仕様プロジェクトを開始し、ベンディングメタデータの仕様の調整と設計を引き継ぎました。

第二に、コミュニティは基本的に一つの声で、ベンディング時にインポートパスを書き換えることは不可能であると述べました。ベンディングは、コードを変更せずにコピーできる方がはるかにスムーズに機能します。

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コンパイラに期待を定めるように、私たちはオンラインでの議論やこのようなオフラインの会議での私たちの行動に期待を定める仕様を書くことができます。

どのような良い仕様もそうですが、多くの実装を許容するほど一般的であり、同時に重要な問題を特定できるほど具体的である必要があります。私たちの行動が仕様に合わない場合、人々はそれを指摘でき、私たちは問題を修正できます。同時に、この種の仕様が言語仕様ほど正確ではないことを理解することが重要です。私たちは皆、それを適用する上で合理的であるという前提から始めなければなりません。

この種の仕様は「行動規範（Code of Conduct）」とよく呼ばれます。Gopherconには行動規範があり、私たちは皆ここにいることでそれに従うことに同意していますが、Goコミュニティにはありません。私や他の人々は、Goコミュニティには行動規範が必要だと信じています。

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

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

他の理由がないとしても（明確にしておくと、他にも優れた理由がありますが）、Goには可能な限り大規模なコミュニティが必要です。行動がコミュニティの規模を制限する限り、それはGoの進歩を妨げます。そして、行動は簡単にコミュニティの規模を制限することができます。

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

例えば、私は時間がないときに言葉数が少なくなる傾向があり、その結果、私のメールは急いでいるだけでなく、ぶっきらぼうで、せっかちで、時には軽蔑的にさえ感じられることを学びました。それは私の気持ちではありませんが、そのように受け取られる可能性があり、その印象だけで人々はGoの使用や貢献について再考するかもしれません。Goの貢献者の一部がプライベートなメールで教えてくれたときに、私はこれに気づきました。今では、時間がないときには、書いている内容に特に注意を払い、意図したメッセージを確実に送るために、自然に書くよりも多くの言葉を書くことがよくあります。

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

私たちは行動規範を書く経験がないため、既存のものを読んでいます。そしておそらく、既存のものを採用し、若干の調整を加えることになるでしょう。私が最も気に入っているのはDjangoの行動規範です。これはSpeakUp!という別のプロジェクトから生まれたものです。これは、日々の交流のためのリマインダーのリストを詳細に説明する形で構成されています。

「フレンドリーで忍耐強くありましょう。歓迎しましょう。思いやりを持ちましょう。敬意を払いましょう。言葉遣いに注意しましょう。意見が合わないときは、なぜなのか理解しようと努めましょう。」

これは、私たちが設定したい雰囲気、送りたいメッセージ、新しい貢献者のために作りたい環境を捉えていると私は信じています。私は間違いなく、フレンドリーで、忍耐強く、歓迎的で、思いやりがあり、敬意を払いたいと思っています。常に完璧にできるわけではありませんし、もし私がそれに達していない場合には、役立つ指摘を歓迎します。私たちのほとんどが同じように感じていると私は信じています。

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

Goコミュニティが、テック業界で最もフレンドリーで、歓迎的で、思いやりがあり、敬意を払うコミュニティの1つになり得ることに、私は何の疑いもありません。私たちはそれを実現できます。それは私たち全員にとって利益となり、名誉となるでしょう。

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

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

ありがとうございます

私は、「go get」を使ってソフトウェアを公開したり、ブログ記事で洞察を共有したり、メーリングリストやIRCで他の人を助けたりする多くの人々を、この広範なオープンソースの取り組み、Goコミュニティの一員だと考えています。今日ここにいる皆さんも、そのコミュニティの一員です。

今後数日間、Goの使用と拡張に関する経験を共有するために時間を割いてくださるプレゼンターの皆様に、心より感謝申し上げます。

会場にお越しの皆様、質問をしてくださり、Goが皆様にとってどのように機能しているかをお知らせくださることに、予め感謝申し上げます。ご自宅に戻られた後も、学んだことを共有し続けてください。日常業務でGoを使用しない場合でも、Goが他の文脈でどのように機能しているかを見ることを楽しみにしています。私たちは常に、Goに取り戻すための良いアイデアを探していますから。

この場にお越しいただき、Goコミュニティの一員となってくださった皆様に、改めて感謝申し上げます。

今後数日間、どうか、私たちが正しく行っていること、間違っていることを教えてください。そして、Goをさらに良くするために、私たち皆が協力するのを助けてください。

フレンドリーで、忍耐強く、歓迎的で、思いやりがあり、敬意を払うことを忘れないでください。

何よりも、会議を楽しんでください。