オープン ソース化の旅: Roslyn の 1 年目の試行錯誤とその成果

今回は、マネージ言語チームでプログラムマネージャーを務める Kasey Uhlenhuth の記事をご紹介します。

「一緒に冒険をする仲間を探しているのじゃよ」

— ガンダルフの言葉より (『ホビットの冒険』 J.R.R. Tolkien 著、英語)

2014 年 4 月 3 日、サンフランシスコで開催された Build カンファレンスのステージで Anders Hejlsberg が .NET Compiler Platform (別名 “Roslyn”) のソース コードを公開 (英語) したときから、このプロジェクトのオープン ソース化の旅が始まりました。当時はオープンソース (灰色の魔法使い) に導かれながらプロジェクトを進めた経験が少なく、開発チームは不安と期待を抱いたまま旅を始めました。今回の記事では、Roslyn のオープンソース化 1 年目の試行錯誤とその成果についての真実の物語をお話したいと思います。

冒険への誘い

開発者がコードを中心としたツールやアプリケーションを作成する際、これまではマイクロソフト製のコンパイラの処理を再現するセマンティックな分析エンジンを自前で開発する必要がありました。しかし、「ブラックボックス」のコンパイラの処理を推察する作業は非常にコストと時間がかかり、しかもその結果必ずしも正常に動作するものが得られるとは限りませんでした。このため、マイクロソフトはコンパイラをプラットフォームとして設計し直して (英語) Roslyn を構築することにしました。コンパイラプラットフォームに API を提供することで、メタプログラミング、C# や VB の対話的な用法、コードの生成や変換、コード分析、リファクタリングといったコードベースの革新的なソフトウェアを開発するためのあらゆる参入障壁が低くなります。私たちはこの目標を念頭に、2009 年から C# と VB のコンパイラの再設計を開始しました。

最初の一歩

Roslyn のオープン ソース化は突然決まったわけではありません。2009 年に行った元のアーキテクチャについての議論では、マイクロソフトの言語のコンパイラをオープンソース化することを検討していました。プラットフォームのソース コードと API に開発者がアクセスできるようになれば、コード ベースの技術革新をまったく新しいレベルに進化させ、より深い領域に取り組むことができるようになります。このビジョンに従い、将来的に決定すべき事項は前もって積極的に決定していくという原則を定め、オープンソース化をスムーズに進められるようにしました。

しかしその後の 5 年間、このオープン ソース化という夢を叶えるための最初の一歩を踏み出すことはありませんでした。一方この間に、F#、ASP.NET、TypeScript の各チームはオープン ソースの手法でよい成果を上げました。それに続くかたちで、Roslyn チームもようやく 2014 年の Build からオープン ソース化プロジェクトを開始しました。

試行錯誤と最初の失敗

2014 年 4 月にこのオープン ソース化プロジェクトの旅を開始したとき、私たちは何の地図も持ち合わせていませんでした。そして、地図に従うのではなく、進むべき道をオープンに探していくことに決めたのです。そうすることで、完璧な道を見つけるまでに私たちがどのようにして裂け谷にたどり着き、カラズラス山の吹雪をかき分け、洞窟や岩の割れ目をくぐり抜けてきたかを皆様に見ていただくことができるからです。あえて「オープンな場所で学ぶ」というリスクを負うことにしたわけですが、私たちはオープンな開発プロセスをゼロから確立するという絶対の自信を持っていました。また幸運なことに、コミュニティの皆様からも多大なサポートが得られ、進むべき正しい道に導いていただくことができました。

しかし、まだだれも通ったことのない道を進むのですから、クモの巣にかかったり、突然の吹雪に遭遇することもありました。しかし、オープン化という戦略によって、私たちは早い段階で過ちに気付き、よりよい道へと軌道修正して、プロジェクトが正しい方向に進むようにすることができました。たとえば、言語の設計ノートを毎週公開 (英語) したり、外部のビルド スクリプトをテストしたり、イシューや質問 (英語) への応答が増えたのもその成果です。

仲間との出会い

旅の途中では、素晴らしい仲間にも出会いました (ドワーフやホビット、エルフ、人間のすべてが仲間です!)。すべての仲間がこの旅の力強い支えとなってくれました。言語設計ノートには、コミュニティからすぐさまフィードバックが返されました。いくつかのフィードバックは、VB14 と C# 6.0 の意思決定に不可欠なものでした。たとえば、こちらのディスカッション (英語) があったおかげで、私たちはプライマリコンストラクターに力を注ぐ必要性に気付かされました。また、null 条件演算子の構文 (英語) と文字列の補完 (英語) に関する貴重なデータを得ることもできました。

さらに、優れたツールの中には、コミュニティによって作成されたものも多数あります。以下は、Roslyn プロジェクトを共に戦うコミュニティが主導してくれているプロジェクトの一部です。

• C# Pad (英語): ブラウザー内で C# を実行できるインタラクティブなシェルです。
• CodeConnect.io (英語): 設計時にコール スタックを視覚化するもので、リファクタリング機能や検索機能を使用できます。
• DuoCode (英語): C# 6.0 のコードを JavaScript のコードにクロス コンパイルします。
• LINQPad.CodeAnalysis (英語): Roslyn と連携して作業をしやすくするための機能を LINQPad に追加するライブラリです。
• Mono/Roslyn (英語): .NET Framework をオープン ソースとしてクロス プラットフォームで実装したものです。
• OzCode v2.0 (英語): Roslyn を使用して魔法のようなデバッグ エクスペリエンスを提供します。
• Scrawl (英語): FluentCo.de が提供する最先端の Web 開発者向けの軽量エディターです。
• scriptcs (英語): C# をスクリプト言語として使用できるようにすると共に、コマンド ラインの C# REPL を提供するオープン ソース プロジェクトです。
• Try Roslyn (英語): Roslyn のデモを行うもので、コンパイラのバグを再現する方法を示しています。
• WebEssentials Markdown エディター (英語): Roslyn が提供するエディターです。

Roslyn を使用するコミュニティ内のプロジェクトの作業量と質から、プラットフォームをオープン ソース化する選択は正しかったと確信しました。

成長と新しいスキル

私たちは当初、ソース コードを CodePlex で公開していました。CodePlex を利用したのは、簡単にすぐさま利用できたことと、当時はマイクロソフトのオープン プロジェクトの「ために設立された場所」であったことが理由です。しかし、GitHub をプラットフォームにして欲しいという声を多くいただいたことから、GitHub に移動することに決めました (英語)。

移動に伴いワークフローも変更し、他のチームが採用しているベスト プラクティスのいくつかを取り入れました。移動前の私たちは、「限定的なオープンソース化」モデルを採用していました。これは、トラッキングやコード レビューはすべてチーム内で行い、コミュニティから協力いただいたものをコードのベースに取り入れながらもそのコードを直接マージすることはしない (自分たち自身でコードをコピー アンド ペーストしてマージする) という手法です。

GitHub に移動してからは、「完全なオープン ソース化」モデルを採用し、開発や作業を完全にオープンなかたちで進めています。バグや設計ノートは GitHub のイシュートラッキング システムで管理し、コードの変更はすべてプル リクエストという形で投稿しています。GitHub のコード レビュー システムも自分たち自身が使用していて、イシューのリンクやコードに関する議論にはマークダウンを使用しています。また、プルリクエストのどの部分を採用するか、プル リクエストをマージする際にどのような承認が必要か、推奨するスタイル ガイド、プル リクエストをクローズするまでの期間 (たとえば約 10 日間など) といった明確なルールを決定しました。

このワークフローの変更は、コミュニティの参加者を増やすうえで不可欠なものでした。チームの中心的な開発担当者をコミュニティの皆様と同じコード投稿プロセスに従わせることで、私たちも民主的なかたちでプロジェクトに参加し、透明性をさらに高めました。その結果、ユーザーがわざわざ要望を出したり、作業がいつ終わるのか知らないといったことがなくなりました。開発者はイシューのトラッキングシステムを見れば、そのイシューに取り組み始めた人がいるのかどうかを確認することができます。イシューはマイルストーン (英語) にアサインされ、優先順位が付けられます。イシューは常に議論中であるか、Up-for-Grabs (英語) のタグが付けられます。

変革

可能な限り開発をオープンに行う現在のワークフローに移行し、コミュニティ メンバーと同一の協力モデルを採用することで、移行前の約 2 倍のコミュニティの協力を得られ、作業期間も約 3 分の 1 にまで短縮されました。

Roslyn のユーザー数も着実に増加しています (今後の増加も期待しています!)。次のグラフは、新しいモデルを採用した後のプルリクエストのユーザーとイシューのログ ユーザーの増加の状況を表しています。

さらに、以下は私たちの応答率と取り組み具合を示す統計です。これを見ると、社内の中心チームが新しい開発手法に従ってコードの承認順位を適切に決定していることがわかります。

イシューの応答率はプル リクエストの半分ほどですが、これは皆様から大量のイシューをいただいているためです。この数字に感謝すると共に、私たちは常にこれを改善する道を模索しています。

このほかにも、さらに多くのコードをオープン ソース化してきました。1 月以降、次の 3 つのプラットフォーム コンポーネントをオープンソース化しました。

• スクリプト作成 (英語)
• 式エバリュエーター (英語)
• Visual Studio 言語サービス (英語)

インタラクティブな設計ノート (英語) も公開しています。

今後の対応

このプロジェクトの旅が始まってから 1 年が経過しましたが、課題はまだまだ山積みです。現在開発チームでは、オープンソース システムのより細かな課題を解決することに取り組んでいます。まず、過去のイシューをまだ CodePlex から GitHub に移行していないので、そこから取り組み始めます。また、GitHub でのイシューのラベリングについてよく把握していない部分があるので、ラベリングをより民主的なかたちで使用できるように検討したいと思います。

さらに、この取り組みを別の製品のリリースに活用するための方法も検討する必要があります。どのコードをどのリリースや製品、NuGet パッケージに活かすのが最適であるのか、これを透明性や民主性を保ったまま過去の成果をないがしろにせずに済む方法を思い付いた方はぜひアイデアをお寄せください。

開発チームではまず、F5 キーによるビルドで、コンパイラとワークスペースの階層の変更をわかりやすくすることに取り組んでいます (英語)。

今後の道のり

このプロジェクトの冒険はまだまだ続きます。さまざまな困難や危険が待っているかもしれませんが、ここまでの道のりは心躍るものでした。コミュニティの皆様には、文章ではお伝えできないほど感謝しています。Roslyn 用にすばらしいテクノロジを作成してくださりありがとうございました。また、質の高いフィードバックやコードのご提供もこのプロジェクトの成功にはなくてはならないものでした。ガラドリエルが言うとおり、「どんなに小さなこと (プル リクエスト) でも、未来を変えることができる」のです。また、Gitter (英語)、GitHub (英語)、Twitter (英語) を通じて皆様と共に作業し、皆様のことをさらに深く知ることができたことも大きな喜びでした。皆様は私たちにとってのサムワイズギャムジーです。今後も引き続きご協力くださいますようよろしくお願いいたします。まだこのプロジェクトにご参加されていない方は、こちらのページ (英語) をご確認ください。これから始まる 2 年目の旅を支えていただけますと幸いです。

「終わりじゃと? いや、旅はまだ終わりではない」

— ガンダルフの言葉より (『指輪物語』J.R.R. Tolkien 著、英語)

完
Kasey Uhlenhuth (マネージ言語チーム、プログラム マネージャー)