どのようにInnerSourceは機能するのか？

AチームがBチームから提供されるソフトウェアを利用する場合を例に考えてみましょう。 AチームはBチームに機能追加のリクエストを送ります、でもBチームはそれを期限内に実装してAチームにリリースすることはできません。 InnerSourceでは、もしAチームがこの要求機能を得ることができない場合、代わりにプルリクエストを送信します。 それは、AチームはBチームのソフトウェアに直接機能を実装してプルリクエストを送付することを意味します。 チームBは連携して送付されたコードをレビューして受け入れます。

この例において、チームAは ゲスト チーム、チームBは ホスト チームと呼ばれます。 ゲスト や ホスト の用語は、自宅にお客を招くような感覚で使われています。 この状況では、殆どの人は良いホストとなること期待しています。 彼らはゲストの到着を見越して、物事が整理整頓されていることを保証します。 訪問者は、ドアのところで迎えられて中に招かれます。

訪問者は、家の共用エリアにある機能や設備を利用することができます。 そこには、ゲストが従うべきいくつかの家のルールがあるかもしれません、 同様に、ほとんどのゲストは、その家やホストに対して敬意を表したいと感じています。 彼らは、滞在期間中、家の備品を丁寧に扱い、家のルールにも従います。 彼らは、礼儀正しく丁寧に振る舞うことで、再度招かれることを期待しているかもしれません。 こうした家を訪問する際の考え方は、コードベースに対するホストが、ゲストからのコントリビューションを受け入れる際に、チームが取るべき態度や行動の考え方とも言えます。

それでは、InnerSourceのプロセスの仕組みがどのように機能するかを見てみましょう。 この説明の補足として、ここでゲストチームとホストチームそれぞれのキーパーソンとなる人に名前を付けておきます。 まず、 プロダクトオーナー は、ホストチームが受け入れるコントリビューションがどの機能かを決定します。 コントリビューター は、ゲストチーム内の個人で、ホストチームにレビューしてもらうためにコードを投稿します。 Trusted Committer(トラステッドコミッター) は、ホストチームを代表する人であり、コントリビューターがプルリクエストを正しく投稿するために必要な指導やタイムリーなサポートを提供します。 小さな草の根活動的な取り組みでは、一人でプロダクトオーナーとTrusted Committer 両方 の役目をすることがあります。

これらの定義を用いて、InnerSourceのコントリビューションに関する基本的なアウトラインを説明すると、次のようになります。

こうした手順は、チームの時間や優先度の一般的な組織向けのもので、特定のシステムを仮定したものではないことに注意してください。InnerSourceは、チームがすでに組織化するための確立された方法を持っていることを想定しており、ホストにコードをコントリビューションしたいと思っているゲストチームがある場合に、連携して作業するためのフレームワークを提供しています。

このオプションはゲストチームにとても有効です。なぜなら、彼らが長期的にメンテナンスする責務を負うことなく、必要とする時間までに機能を入手できるからです。 また、ホストチームにも有効で、より良い拡張性やサービスを顧客に提供することができます。 さらに、一元管理され誰もが利用可能な場所で共有された問題に対する解決策を会社全体で共有できることは、会社全体にとっても有効です。 より多くのエンジニアの時間が、機能調整ややエスカレーションプロセスのメカニズムより、会社の課題を解決するコード生産に注力されます。