Red Hatのシニアディレクターに訊くOSPO

オープンソースソフトウェアを企業において活用する際にOpen Source Program Officeを設置するという試みについては、CNCFのCTOであるChris Aniszczyk氏とCapital Oneのエンジニアによるセッションを紹介した、また日立製作所やサイバーエージェントなどのエンジニアによる座談会で日本での取り組みや苦労、組織の組み方なども紹介した。

参考：オープンソースを活用する企業にオープンソースプログラムオフィスは必要か？

参考：オープンソースを企業で活用するための組織、OSPOは日本に根付くか？

レッドハットのシニアディレクターが語るOSPO

今回はオープンソースそのものをビジネスにしている企業の中で唯一大成功していると言っても良いRed HatのOpen Source Program Officeのシニアディレクターにインタビューを行った。

また後半はこのインタビューでも触れられている2020年10月に公開された「Open Source Participation Guideline」を紹介する。インタビューに参加したのはRed HatのSenior Director Open Source Program Office, Office Of The CTOという肩書きを持つDeborah Bryant氏だ。

インタビューに参加したレッドハットのスタッフとBryant氏

今回のインタビューはテレビ会議を使って行われ、レッドハット株式会社の広報の小板橋美世氏とAPACをカバーする製品統括・事業戦略担当本部長の岡下浩明氏も参加した。

今回のインタビューの前に日本でのオープンソースプログラムオフィスの必要性について日立やサイバーエージェントなどのエンジニアに集ってもらって座談会をやりました。やはり事業部門の理解を得るのが難しいというのは一致した見解でした。多くのエンタープライズ企業にとって、オープンソースは無料のソフトウェアという扱いでしかないように思います。オープンソースに馴染んでいるエンジニアにとってコミュニティやUpstreamに貢献するというのは当たり前ですが、ビジネスオーナーにそれを理解してもらうのは難しいのです。これについてまず何かアドバイスがありますか？

Bryant：そうですね。それについては少し前に私が体験した話をしましょう。それは日本にも少し関係のある話ですから。1995年頃にたまたま前の仕事で日本に来ていた時の話でちょうどインターネット接続サービスのビジネスが始まるタイミングでした。実はインターネットを使ってビジネスをするという時に、それまで競合していた会社が協力してソフトウェアを開発するということになりました。それは企業にとっても私個人にとってもとても新しい体験だったのです。コードを書いて共有することで新しいビジネス、サービスが始まったわけです。

私は2006年に島根県の松江でRuby Cityのプロジェクトが始まった時にも島根に行っています。その時にも多くのアントレプレナーやまつもとゆきひろ氏などのイノベーターとも話をしました。その時にもオープンソースによってコードを書く、協力するということが新しい仕事の方法として上手く進んでいることを自分の目と耳で感じました。なのでエンジニアやイノベーターの人たちはオープンソースに貢献することの意味は理解していると思います。

しかしビジネスの人たちとは少し距離があるのは確かですね。でもここ5～6年は企業内にオープンソースプログラムオフィスを作るというトレンドが来ていると感じています。それはエンジニアだけではなくビジネスオーナーに対するインフルエンサーの人たちが、オープンソースのことをよく理解し始めているからだと思います。ここで言う「インフルエンサー」はエンジニアだけではなくアントレプレナーや法律家なども含まれますね。

前回の座談会の時に日立製作所のエンジニアからはシニアエグゼクティブのサポートがないと始められなかったというコメントがありました。それについては？

Bryant：それはその通りですね。やはり経営層のスポンサーがないと上手く始められないと思います。でもだからと言って最初から大きな組織を作る必要はないのです。まずは一人から始めて、それから法務の人やビジネスサイドの人を連れてくるという感じだと思います。

オープンソースには法律に関するさまざまな要件が発生しますが、日本の法律家、弁護士などはあまりソフトウェア、特にオープンソースソフトウェアに詳しい人がいないというのが現実です。そういう人を探すにはどうしたら良いでしょう？

Bryant：それはアメリカでも同じですね。法律家というのは、新しいことへのチャレンジに関してはとても保守的なのも、日米で同じかもしれません。私も顧客から相談を持ち掛けられることがありますが、最初からエキスパートを探すのは難しいのです。そういう時、私はRed Hatの法務部の人と顧客の法務部の人を繋げて、とにかく少しでも話をできる環境を用意するようにしています。

専門的なコンサルティングをするというのではなく、簡単な質問でも同じ法務の専門家同士が話をすることで助けられることがたくさんありますから。それはビジネスの人も同じで、例えばエンジニアが自社の経営層にオープンソースを理解させようとしても難しい場合は、オープンソースに理解があるビジネスオーナーと繋げることで理解が進む例が多いのです。つまり、伝えたい相手と同じような立場の人を使うということですね。

組織についてですが、兼任でオープンソース担当を作ることで実際の組織体系とは違う組織をバーチャルに作るというやり方がありますが、この方法については？

Bryant：それが上手くいかないことを、アメリカはすでに経験しています。かつてマトリクス組織という発想で一人の社員が複数の上司にレポートするというやり方が流行りましたが、上手くいきませんでしたね。やはり、必ず一人は専任の担当者を任命して、その人が活動するというのが基本だと思います。あとはさっきも言いましたが、その組織を支援してくれるビジネスサイドのスポンサーも必要です。

企業におけるエンジニアは、その企業で必要とされるソフトウェアを開発することで評価されるわけですが、オープンソースソフトウェアに対する貢献を評価することと両立させるのは難しくはないですか？

Bryant：それは逆ですね。実際には、オープンソースソフトウェアへの貢献はすべてGitHubなどの上で公開されています。すべてが公開されていて透過性が高い活動なので、評価は企業内でのブラックボックスのソフトウェア開発よりもわかりやすいはずなんです。ただし「GitHubの上でどういう活動をしているのか？」マネージャーはこれについて理解する能力を持たなければならないということはあるでしょうね。

Red HatにはUpstream Firstというポリシーがあって、バグなどを見つけても必ずUpstreamにフィードバックすることが求められますが、それを一般企業にも求めるのは難しくないですか？

Bryant：Red HatのUpstream Firstも最初からできていたわけではありません。我々もさまざまな経験を通して学んできたという経緯があります。例えばバグの修正にしても1社だけで発生しているバグを直すのか、それとももっと別のバグを選ぶのか、それを決めるのは難しい判断です。でもそれをコミュニティに公開してどれを直すのかを決める、そして直したものは必ずUpstreamにマージするということをしないと、コミュニティに信用されなくなるということを学んだわけです。

以前、ある日本企業がオープンソースソフトウェアを自社用にForkしてシステムを構築して、バグについては自社のコードを直して後からUpstreamにマージしようとしたけど、とても大変だったという経験を語ってくれたことがあります。つまり勝手にForkしたソースコードから元に戻すのが大変だったと。

Bryant：それはアメリカでもやってますよ。実際、US ArmyはLinuxのカーネルを自分達のためにForkして改造しようとして結果、失敗という経験をしています。我々は「それはまずいアイデアだ」と頭を抱えましたが。

そういうような失敗談を共有してくれるとありがたいんですが。

Bryant：そうですね、でもベンダーはだいたいサクセスストーリーを公開しようとしますから。特にUS Armyの場合は、難しいと思います。プロプライエタリソフトウェアベンダーであれば、その失敗に関連する範囲をある程度限定できるので、公開はやりやすいかもしれませんね。

今回のようなポリシーやオープンソースソフトウェアに関わる際のマニュアルをRed Hatはお持ちですか？ 去年、レッドハットの社員にインタビューした時はないという回答でしたが。

Bryant：去年の今頃であれば「残念ですがありません」という回答だったと思いますが、今年は違います。2020年10月にRed Hatとしてのオープンソースソフトウェアに関わる際のガイドラインを公開しました。この文書はRed Hatの社員からも多くのフィードバックをもらって作り上げました。社員に公開することで、我々が思ってもみなかったポイントも発見されて良いものに仕上がったと思っています。

参考：レッドハットのOpen source participation guidelines

レッドハットのOpen source participation guidelines

ここからはこのRed Hatが作成した「オープンソースソフトウェアに関わる際のガイドライン」を紹介したい。

最初は「オープンソースソフトウェアとは何か」の定義から

ここではシンプルな文章でオープンソースソフトウェアを定義しているが、実際の文章としてはOSI（Open Source Initiative）の定義やFSF（Free Software Foundation）の定義を引き合いに出して紹介している。

自分の仕事に関係のないOSSへの参加に許可は不要

またオープンソースソフトウェアに関する活動への参加の仕方という部分では、Red Hat社員は仕事の領域とは関係のないオープンソースソフトウェアの活動に参加する時に誰の許可も必要としないこと、オープンソースソフトウェアの開発に関しては仕事の時間と個人的な時間の境界は曖昧でも良いことなどが明記されている。

またBryant氏のインタビューでもでてきたUpstream Firstは4つ目の章として登場しており、ここでもRed Hatの重要なポリシーとして認知されていることがわかる。

Upstream Firstが大事なポリシーとして登場

ここでは多くの文字を費やして解説しているが、コミュニティが開発することを可能にするコードをUpstream、それに比較して例えばRed Hatが長期のサポートを保証するビルドをDownstream、もしくは非Upstreamと呼ぶということになる。これがどうして重要なのかを表す端的な例を挙げて説明している。

最初はRed Hatが開発するOSSの場合

最初の例はRed Hatが開発する場合で、これはわかりやすいだろう。この例ではRed Hat Enterprise Linux（RHEL）に対して新機能を追加する場合、コミュニティ版であるFedoraにその機能が追加された後にRHELに追加されることが解説されている。最後のマーカーの部分は「もしもUpstreamがない場合は、それを作る」としている。これはRed Hatが企業を買収したような場合に当てはまるものだ。AnsibleもQuayも買収の結果、Red Hatのポートフォリオに追加されたソフトウェアだが、当初はオープンソースソフトウェアではない部分があった。買収後にレッドハットはそれらをすべて公開して、Upstream版を用意したという実績がある。

Red HatがリードしないOSSの場合

2つ目の例はさらに踏み込んでいる。例えば、Kubernetesを例に挙げて説明しているが、もしも機能追加やバグフィックスを行ったとしてもそれがUpstreamにマージされない場合、たとえRed HatがDownstreamを製品として販売していたとしてもマージしないということになる。ここではKubernetesをUpstream、OpenShiftをDownstreamとして考えるとわかりやすいだろう。つまり、OpenShiftだけに機能追加が行われる（OpenShiftにあってKubernetesにない機能が追加される）ということは決して起こらないということだ。

このほかにもコントリビューターとして参加する際の約束、CLAとDCOの対応の違いや新たにオープンソースソフトウェアを作り始める時のチェックポイントなどが明記されており、短いながらもわかりやすいガイドラインとなっている。今回は英文を紹介したが、レッドハット株式会社はこれの要約版を日本語で公開している。

参考：レッドハットのオープンソース参加ガイドライン

オープンソース業界で大成功したレッドハットであっても、この文書の完成までここまで時間を要したことを考えると、一般企業において同様のガイドラインを用意するのはハードルが高いことかもしれないが、参考にして欲しい。