Thoughtworks Go のオープンソース化
2014年3月25日
チャド・ワシンクトン：Thoughtworks Studios マネージングディレクター
Goは、Thoughtworks Studios（Thoughtworksのプロダクトグループ）が過去6年間にわたって構築してきた製品であり、継続的デリバリーを支援します。自動化されたデプロイメントパイプラインの作成と管理に役立ちます。チェックインからデプロイメントまでのビルド・テスト・リリースの全プロセスを自動化できます。
Thoughtworksは、Goをオープンソース化する発表を行いました。現在、BSDスタイルのライセンスの下で自由に利用可能であり、ソースコードもまもなく公開されます。この背景とよくある質問への回答を説明するために、Thoughtworks Studiosのマネージングディレクターであるチャド・ワシンクトンにインタビューを行いました。
マーティン：なぜ世界は別の継続的インテグレーションサーバーを必要とするのですか？
チャド：Goは継続的インテグレーションサーバーではありません。継続的デリバリー（CD）を目的としており、継続的インテグレーションはその一部です。Goは、シーケンシャルおよびパラレル実行、ファンインとファンアウトの依存関係管理、およびデプロイメントパイプラインに固有のその他の活動を容易にモデル化できます。
これは、スクリプトによるCIサーバーやプラグインを使用して実現できるものではないでしょうか？
何でも寄せ集めることはできますが、時にはすべきではありません。デプロイメントパイプラインは、CDツールにおいて第一級の概念であるべきであり、頭痛の種を避けることができます。私は、Thoughtworksを含む多くのチームが、CIツールを使用してパイプラインを実装することに多大な時間とリソースを浪費しているのを見てきました。単純なワークフローを超える場合、ソースへの明確なトレーサビリティなど、欠けている基本的なものがあります。
Goをオープンソース化することは、商用製品として失敗したことを意味するのでしょうか？
いいえ、商用製品としては目標を達成できませんでした。Thoughtworksは三本柱の組織です。その柱の一つは、ソフトウェアの卓越性を推進し、ITに革命を起こすことです。もう一つは、持続可能なビジネスを運営することです。大きな行動の変化を提唱し、高額な料金を請求し、寄せ集めの無料CIソリューションと競争するのは困難です。（私たちはOSS CIサーバーの大ファンでもあります。私たちは3つの成功したものをOSS化しました。）つまり、革命を正当化するには、経済的に十分な利益を得られていませんでした。明確な最小値を持つスライダーのバランス調整と考えてください。
また、インフラストラクチャソフトウェアはOSSである必要があると考えるようになりました。Goが包含するエコシステムのほぼすべては、ソース管理とビルドから、デプロイメントと構成管理まで、OSSです。このようなツールにはコミュニティが必要です。OSSビジネスモデルはいくつかの点でより困難ですが、継続的デリバリーを主流にするために収益を放棄する意思があります。私たちの創設者であるロイは、公共財の創造を強く信じています。
なぜソースコードはまだ公開されていないのですか？
何かを自由に利用可能にすると決めたときに起こる興味深いドミノ効果があります。同じように料金を請求し続けることはできません。それは非倫理的です。対応として、見込み客や顧客に大幅な割引を提供するか、今は支払わないように伝えます。それは疑念を生み出し、驚くべきことに人々はあなたに支払うことに固執します。恐怖を取り除くと、最終的に降伏し、個人にオープンソース化していることを伝えます。そのシナリオを何度も経験すると、広範な発表で先に進む必要があります。とにかく発表するのです。GoogleはAndroidをOSSとして事前に発表し、HPもWebOSについて同じことをしました。私の推測では、どちらも同様の方法でリークされた非発表を避けることを試みていたということです。
コードはまだ準備できていません。開発者のエクスペリエンスを向上させるために懸命に取り組んでいます。コードコメントの言語のクリーンアップや古いライセンスの削除など、予想される作業があります。しかし、他にも複雑な問題があります。私たちは、2つのデータセンターにまたがる大規模なVMグリッド上でGoを構築、テスト、リリースするためにGoを使用しています。より単純な公開ビルドインフラストラクチャを作成する必要があります。それをOpenStackで実行しています。Goの広範な自動化された機能テストスイートはTwistで記述されていますが、Twistはオープンソースではないため、それを回避する必要があります。やるべきことがたくさんあります。
golangがあるのに、なぜGoという名前なのでしょうか？
Goは当初、CruiseControlへのオマージュとしてCruiseという名前でした。しかし、類似した名前の選択が混乱を引き起こしたため、2010年7月にGoに名前を変更しました。これはGoogleがgolangを公に発表した後ですが、当時はそれほど人気のある言語ではありませんでした。
これは名前を変更する良い機会ではないでしょうか？
はい。ソースコードを公開するためのすべての作業を考慮すると、最初に名前を変更する手間でさらに遅延を受け入れることはしませんでした。しかし、名前はコミュニティ次第です。コードが公開された後、コミュニティが名前を変更したい場合、私たちは喜んで協力します。
GoとCruiseControlの関係は何ですか？
Thoughtworksは、2001年にOSSプロジェクトとして最初の継続的インテグレーションサーバーであるCruiseControlを作成しました。2007年に、CruiseControlを近代化するための取り組みを開始しましたが、CruiseControlのアーキテクチャでは、私たちが望むグリッドと第一級のデプロイメントパイプラインを実現できないことに気づきました。現在、CruiseControlとGoは共通点がありません。
今後、Goにどのようなサポートを提供する予定ですか？
現在のGoチームはどこにも行きません。実際、プロジェクトに活気のあるコミュニティがあれば、さらに人員を追加します。Thoughtworksは、商用アドインとサポートも提供します。
最近、「Snap」という別のツールをリリースしましたが、それらの違いは何ですか？
Snapは、サービスとしてのホスト型CDです。これは、デプロイメントのニーズがより単純なアプリケーションを対象としています。私たちは、複雑で困難なCD設定を解決するためにGoを構築しました。Snapは、通常のクラウドプロバイダーにデプロイするチームや組織にとって、CD自体をシンプルにするために設計されています。つまり、Goの機能の広さは複雑なシナリオに焦点を当てているのに対し、Snapの機能の深さは、慣習を使用してCDを容易にすることに焦点を当てています。
追加する機能は何ですか？
やりたいことがたくさんありますが、その順番は、主にコミュニティによって決定されます。よりコミュニティ主導のプロセスを優先するために、チームに「プロダクトマネージャー」の役割を持たせないという意識的な決定をしました。
拡張ポイントを追加することは非常に重要なリストの項目であり、それにより人々はGoをより簡単に拡張できます。バリューストリームマップ（VSM）に視覚化に加えてより多くのバリューストリーム関連の機能を持たせるという、本当にクールなアイデアがあります。多くのユーザーが、開始を容易にする機能を要求しています。Goの認証をプラグインに移行して、ユーザーが独自の認証を作成できるようにしたいと考えています。
これらの項目のリストは、GitHubのissueで近日中に大幅に改善され、誰でもコメントして順番に貢献できます。