Open Source Summit NA 2022開催。Googleが解説する持続可能な信頼できるOSSのためのキュレーターとは?

2022年9月27日(火)
松下 康之 - Yasuyuki Matsushita
2022年6月に開催されたOSSummit NA 2022、初日のキーノートからGoogleのセッションを紹介する。

オープンソースソフトウェアの拡大と支援を行う非営利団体、The Linux Foundationが主催するOpen Source Summit North America 2022がテキサス州オースチンで開催された。Linux Foundation配下のCNCF(Cloud Native Computing Foundation)が主催するIT業界最大のオープンソースカンファレンスであるKubeConが2021年からリアルと配信のハイブリッドイベントとして再開されているのと同様に、Open Source Summitもリアルと配信の並列で開催されるようになった。2022年6月21日から24日にかけて開催され、今年は1200名の参加者が集うリアルイベントとなった。

この記事では初日のキーノートセッションから、GoogleのEric Brewer氏が行ったセッションを紹介する。最初に登壇したのはOpenJS FoundationのExecutive DirectorであるRobin Ginn氏だ。

MCはOpenJS FoundationのRobin Ginn氏

MCはOpenJS FoundationのRobin Ginn氏

Ginn氏のイントロダクションに続いてスピーカーとして登壇したのはAeva Black氏だ。Black氏はMicrosoftでAzureにおけるオープンソースに関わっているエンジニアだが、今回はMicrosoftという勤務先を出さずに、オープンソースコミュニティにおけるダイバーシティについて短めのプレゼンテーションを行った。

コミュニティにおけるLGBTQ+の差別について訴えるBlack氏

コミュニティにおけるLGBTQ+の差別について訴えるBlack氏

KubeConも単なるテックカンファレンスという枠を終えて、キーノートでウクライナの戦争について語られるなど社会との関わりをますます意識するような内容になっていた。OSSummitもLGBTQ+に関して、差別が未だに存在することを訴えた。これは今回の開催地がテキサスであることに多分に影響されているのだろう。というのもテキサスはLGBTQ+に対しては差別的な施策を行っているためで、その地でのカンファレンスに参加したエンジニアに対して、自由でオープンであるべきコミュニティメンバーとして差別の撤廃を訴えた形になった。

その後に行われたのがGoogleのEric Brewer氏によるセッションだ。

GoogleのEric Brewer氏

GoogleのEric Brewer氏

タイトルは「Consequence of Success: OSS is Critical Infrastructure」、オープンソースソフトウェアが社会の重要な部分に使われていることを強調しながらも、開発と保守をどのように持続していけばいいのか? について提案を行う内容だ。

OSSは成功したが課題が残っていると説明

OSSは成功したが課題が残っていると説明

このスライドではオープンソースソフトウェアはクローズドなソフトウェアに比べて成功していると説明したが、それは頻繁にソフトウェアに対して変更が行われていることと、すでに多くの領域で使われていることが影響していると説明。「巨人の肩に乗る」という部分は、先行してオープンソースソフトウェアを使う企業や組織が存在することで、その知見を活かして後発の企業や組織は安心して利用できるという部分を指している。

しかし社会のインフラとなる部分に使われるソフトウェアとしては、よりいっそう信用を勝ち取る必要があると説明。この場合の信用とは、単に機能を果たすだけではなく、バグや脆弱性などが発生した場合に、それを修正していくという部分の仕組みが必要ということだ。

最近のOSSの安全に纏わる事件を列挙

最近のOSSの安全に纏わる事件を列挙

このスライドではLog4j攻撃などを例に挙げて、オープンソースソフトウェアが進化しているとは言えるが、脆弱性などに対する持続的な保守活動が必要だと説明した。

そしてLog4jに関する脆弱性が明らかになった際にあるメンテナーが受信した「フォーチュン500に選ばれるレベルの大企業からの」メールを元に、オープンソースソフトウェアに対して抱いた間違った期待を説明した。

Log4jの脆弱性の修正を要求するメールを紹介

Log4jの脆弱性の修正を要求するメールを紹介

このメールでは、Log4jの脆弱性の修正のために「何を何時までに行うのか?」を24時間以内に返信して欲しいと要求している。しかもこの企業はメンテナーに金銭的な貢献を一度もしたことがないにも関わらず、だと説明。

OSSは「無料だがそのまま(As is)であること」が基本

OSSは「無料だがそのまま(As is)であること」が基本

そこから「オープンソースソフトウェアは基本として無償だが、そのまま(as is)で使うことが前提となっている」として、ライセンスやソフトウェアの説明にはこのことが繰り返し書かれていると説明した。しかしユーザーの期待は大きく、修正の要求は止まらないにも関わらず、コードの修正を行うメンテナーは少数だし、バグや脆弱性の修正は楽しくない仕事であると語った。またオープンソースソフトウェアが優れている理由のひとつとして挙げられる「伽藍とバザール」という書籍にあるLinus Torvaldsの法則のひとつとして有名な「given enough eyeballs, all bugs are shallow」(十分な目玉があれば、すべてのバグは洗い出される)についても、その前提である十分なエンジニアという前提がすでに崩れていることを紹介した。つまりオープンソースソフトウェアのパッケージのうち30%には、コードのメンテナンスを行うエンジニアが1名しか存在せず、実際にはゼロというプロジェクトも少なくないと説明した。

DistributionとAccountabilityという2つの役割を解説

DistributionとAccountabilityという2つの役割を解説

そしてこの状態を変えるために、オープンソースプロジェクトにおける「役割」を分解することを提案。ここではDistribution(配布)とAccountability(保証)に分解して解説を行った。つまりDistributionは開発されたパッケージを容易に配布するために工数をかける役割で、もう一方のAccountabilityは作られたパッケージに対して安全やメンテナンスなどの保証を与える役割となる。その例としてRed Hatはオープンソースソフトウェアを自社のDistributionとして提供することで、安全や更新の保証を与えていると語った。

しかしLog4jの例でも明らかなように、ビジネスサイドが求める安全や保証をすべてのオープンソースプロジェクトが提供できるわけではない、つまり現状では、主にパッケージを作る部分に注力しており、保証についてはないがしろになっている(それがAs isの意味でもある)として、その間を埋める役割として提案したのが、Curatorという新しい役割だ。

コミュニティとビジネスの中間に位置するCuratorとは

コミュニティとビジネスの中間に位置するCuratorとは

ここでas isのソフトウェアではなく必要に応じてバグ修正を行う仕事をCuration、その役割をCuratorとして定義し、バグや脆弱性を発見するのではなく発見されたバグを直す仕事に専念するものであり、その対応時間についてもSLAとして相互で納得するべきだと説明した。

ビジネスサイドから要求される仕事とメンテナーの中間に位置するCurator

ビジネスサイドから要求される仕事とメンテナーの中間に位置するCurator

その上でGoogleの例を紹介。ここではGoogleが社内ですでにキュレーションされているソフトウェアを「Assured OSS」という名称で公開することで、安全性と修正が保証されているオープンソースソフトウェアを提供できていることを解説した。

GoogleのAssured OSSを紹介

GoogleのAssured OSSを紹介

次にメンテナーの立場から、キュレーションの中身として期待することを紹介した。ここには現在のトップダウンで修正を要求されるOSSメンテナーの悩みが凝縮されていると言えるだろう。

キュレーションに求められる項目を列挙

キュレーションに求められる項目を列挙

ここでは単にリクエストをするのではなく、コードの修正などへの貢献、テスト等が十分に行われたプルリクエスト、テストケースの追加、緊急時のヘルプなどに加えて、金銭的な支援が含まれていることに注目したい。無償のソフトウェアとは言え、実際にコードを書いてバグを修正しているエンジニアも生きていくための金銭が必要であることはわかってはいるものの、無視されがちなポイントだからだ。

またソフトウェア開発のためのツールやバージョン付けのルールについてもキュレーションを支援することができると説明した。つまりオープンソースソフトウェアを使う企業にとっては、as isで使うのかキュレーションのモデルを使うのか決める必要があるというわけだ。さらにメンテナーにとっても、外部のエンジニアがキュレーションを行うための準備が必要だと語った。

Brewer氏が関わっているOpenSSFについても紹介

Brewer氏が関わっているOpenSSFについても紹介

最後に持続可能で信頼されるオープンソースソフトウェアを実現するためには、資金面でメンテナーをサポートする仕組みが必要だと説明。Brewer氏個人が関わっているOpenSSFについても、オープンソースソフトウェアの安全性を支援するための仕組みであるとして紹介を行った。

2014年に発見されたOpenSSLの脆弱性であるHeartbleedに対して、社会的に重要なインフラとなるオープンソースソフトウェアを金銭的に支援するためのプログラムであるCore Infrastructure Initiative(CII)が発展的にOpenSSFへと引き継がれたことからもわかるように、重要なオープンソースソフトウェアを開発するコミュニティを支援する仕組みが必要とされていることを示している。

ただBrewer氏が提案するキュレーション、キュレーターという仕事と役割が具体的に形になるためには、Linux FoundationやCNCFなどの非営利団体や政府機関、そしてユーザーとして無償のオープンソースソフトウェアに対して資金を提供することになる企業が連帯して行動を起こす必要があるだろう。無償の認証局を提供するLet's Encryptを開発するInternet Security Research Group(ISRG)が行っているメモリーセーフなソフトウェアを拡大するためのプロジェクトProssimoのように、企業からの寄付でオープンソースソフトウェアをメモリーセーフなRustで書き直すという具体的な形になっているのであればわかりやすいが、キュレーションという中間的な仕事と役割、それに対する資金の提供が結びつくまでにはもう少し時間がかかりそうだ。

Open Source Summit NA 2022の初日のキーノートは以下から視聴できる。Eric Brewer氏のセッションは、14分35秒から30分38秒の辺りになる。

動画:Day 1 Keynote Sessions

著者
松下 康之 - Yasuyuki Matsushita
フリーランスライター&マーケティングスペシャリスト。DEC、マイクロソフト、アドビ、レノボなどでのマーケティング、ビジネス誌の編集委員などを経てICT関連のトピックを追うライターに。オープンソースとセキュリティが最近の興味の中心。

連載バックナンバー

OSSイベント
第5回

写真で見るOSSummit North America 2022

2022/10/14
OSSummit NA 2022の展示ブースやパーティなどのアトラクションを紹介する。
クラウドイベント
第4回

OS Summit NA 2022でLFに参加したことが紹介されたOPIとは?

2022/10/6
OSSummit NA 2022のキーノートで簡単に紹介されたOPI(Open Programmable Infrastructure)について解説する。
OSSイベント
第3回

Open Source Summit NA 2022、マイクロサービスをWASMで実装したデモを紹介

2022/10/4
OSSummit NA 2022の3日目に元MicrosoftのMatt Butcher氏が登壇。マイクロサービスをWASMで実装したデモを実演。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています