GitHub、ベルリンで発表した新機能などを解説するメディア説明会を開催

GitHub Satelliteの振り返りを国内で

GitHubは、2019年5月23日にベルリンで行われたGitHub Satelliteの振り返りとなるメディア向け説明会を国内で開催した。これは年次で行われるGitHub Universeを補佐するイベントという位置付けのGitHub Satelliteで発表された内容を、日本のメディアに対して説明するものだ。スピーカーとして、2018年にGitHubに入社したOpen Source Economy Product Managerのデヴォン・ツェーゲル（Devon Zuegel）氏が本社より来日した。他にソリューションアーキテクトである池田尚史氏も出席し、セキュリティ、エンタープライズ、コミュニティという3つの分野について、ベルリンで発表された内容を解説する形となった。

池田氏（左）とツェーゲル氏（右）

冒頭の挨拶に立ったギットハブ・ジャパン合同会社の代表である公家尊裕氏は「GitHubを利用するデベロッパーが3600万人に達した」ことを紹介し、GitHubの成長が継続していると述べたのち、プレゼンテーションをツェーゲル氏に譲った。

ギットハブ・ジャパンの代表、公家氏

Satelliteで語られた3つの重点分野セキュリティ、エンタープライズ、コミュニティ

ツェーゲル氏は、GitHub Satelliteで発表された内容を3つの領域に絞って解説を始めた。3つの領域とはセキュリティ、エンタープライズ、そしてコミュニティだ。

OSS特有の事情があるセキュリティ問題

まずセキュリティについてだが、オープンソースソフトウェアの成り立ちとして多くのライブラリーやフレームワーク、ミドルウェアなどの他のオープンソースソフトウェアに依存して構成されることで、デベロッパーが認識できる以上のデベロッパーやメンテナーが関わっているという事実がある。

そのため「悪意のあるデベロッパーがコミュニティに侵入した結果、クリプトカレンシーのマイニングなどのスクリプトが挿入される事態が発生」し、その修正に数ヶ月が必要となったという事例を紹介。オープンソースコミュニティが企業という枠にとらわれなくなった代償として、常に脆弱性の存在を意識する必要が高まったことから、「セキュリティ脆弱性アラート」の機能を実装したことを紹介した。ここではWhiteSourceとパートナーシップを結ぶことで、最新の脆弱性情報が常に利用できるようになったと解説した。

WhiteSourceを使った脆弱性アラートの実装

また脆弱性情報や依存関係のあるライブラリーのソースコードを元に、ライブラリーの更新が必要であることを検知する依存関係の識別、及び更新を実施するプルリクエストを送る機能として、2019年5月にGitHubが買収したDependabotの機能を紹介した。

DependabotがGitHubから利用できる

ユーザーの要望で実現したエンタープライズむけ機能

エンタープライズ向けの新機能としては、アカウントのグループ化機能、オンプレミスにリポジトリーを実装できるインターナルリポジトリ、ユーザーのパーミッションを従来のRead、Write、Adminの3種類にTriageとMaintainを追加したこと、社内ユーザーの活動を分析できるオーガナイゼーションインサイトの4つを紹介した。

4つのエンタープライズ向け機能

どれもエンタープライズユーザーからの要望によって実装されたという機能だが、これまで3段階だったユーザーアカウントのパーミッションを5段階にしたのは注目される。しかし後に記述するRBAC（Role Base Access Control）とも併せて考えると、エンタープライズ企業がすでに保有するアカウント情報、特に組織や権限と言った部分とどうやってすり合わせるか？　と言う部分に工夫が必要だろう。なぜならTriageやMaintainというGitHub独特のRoleを、社内のコンプライアンスと調整した上で実装することが必要になるだろうと思われるからだ。

新しいパーミッションはTriageとMaintain

コミュニティ向け機能

また最後に紹介されたコミュニティ向け機能という部分では、GitHub Sponsorsが目玉の機能となった。これはGitHubのユーザーページに「Sponsor」というボタンを追加し、個々のデベロッパーに寄附できるようにするという機能である。

デベロッパーページに表示されるSponsorボタン

また初年度に限り、GitHubがマッチングファンドを行うことも発表された。これは例えば毎月$10の寄附を行うと、それと同額の寄附をGitHubが行うというものだ。北米では企業と従業員が行うチャリティの一環として、従業員個人の寄附と同額をその企業が支払うという仕組み（マッチング）がある。それをそのままGitHubに持ってきたものという理解で良いだろう。日本ではあまりその発想は浸透しているとはいえないが、少なくとも財務的に困窮しているプロジェクトやデベロッパーにとっては、単純に寄附が倍額になるという意味で価値があるといえる。

マッチングファンドは初年度限定のようだ

この後は質疑応答となった。この前日、個別にツェーゲル氏、池田氏にインタビューを行っているので、その内容も加味して回答をまとめてみたい。

Dependabotによってソースコードとそれが利用するライブラリーの依存関係を理解し、脆弱性を発見するのは良い進化だが、実際には脆弱性以外にも最新のライブラリーとの整合性のチェックが必要となり、その場合、ビルド～テストというプロセス、つまりContinuous Integrationは必須となる。その場合、GitHubが自前のCIツールを開発する予定は？

池田：すでにGitHubのワークフローでは、サードパーティのCI/CDツールとの連携ができている。CircleCIやTravisなどがその例だが、それと同じように外部のCI/CDツールと連携するという部分は変わらない。

GitHub Sponsorsは使いようによってはコミュニティを操作にも使える可能性があるのでは？　例えばある企業が、意図的に自社に有利な仕様変更を行うために資金投入することも考えられるのでは？

ツェーゲル：その可能性についてはGitHubとしても認識はしている。そのためにコミュニティおよびデベロッパーとして、寄附を受け付けないという選択も可能だ。そしてGitHubとしても、そのような行いが発生しないように注意深く動向を観察するので、今の所は問題は起きないと思っている。

GitHub SponsorsはLinux FoundationのCore Infrastructure Initiative^※1と同じ発想のものか？

※1 Core Infrastructure Initiative（CII）：インフラとなるようなオープンソースソフトウェアに対して資金を提供し、安定的にソフトウェア開発、バグや脆弱性の修正を可能にしようとするプロジェクト。

ツェーゲル：発想は同じだ。ただ、CIIがよりコアで非常に大きな規模で使われているインフラストラクチャーのソフトウェアに注目しているのに対して、GitHub Sponsorsはもっと利用範囲が狭いプロジェクトも対象としている。今は個人が対象だが、将来的には企業から継続的な支援を行えるように拡張を予定している。すでに多くのオープンソースソフトウェアに関与している企業とは話し合いをしているという段階だ。現時点ではデベロッパーの数や金額などを公表する予定はないが、これはグローバルなプログラムなので、日本でもこれが利用されることを願っている。

GitHub Sponsorsや新しいエンタープライズ向けの機能が出てきているが、UIなどはまだ英語のままだ。日本語化を進める意思はあるのか？

池田：現時点では日本語化を進めるという方向であることは間違いないが、詳しい状況などについては話せることは少ない。日本語化に関しては、別途紹介する機会を作りたいと思っている。

新しいパーミッションが紹介されたが、RBACを実装しようとするとGitHubだけではなくすでに企業が保有するアカウント情報との連携やすり合わせが必要では？ 例えばMicrosoftのActive Directoryなどとの連携は？

池田：すでにActive Directoryなどとはシングルサインオンできるように連携機能が完成しているので、それを使えば連携は可能だ。

しかしRBACはさまざまなベンダーやプロジェクトがそれぞれのレイヤーで実装している。例えばKubernetesにはKubernetesのRBACがあるし、それぞれが独自のRBACを実装していると言えるのでは？それを統合していく考えは？

池田：それぞれのベンダーがRBACを実装しているのはその通り。GitHubとしてそれを統合しようという動きをしているかと言えば、それは現状ではないというのが回答だ。

セキュリティの実装という中で良く出てくるRBACも、それぞれの実装が孤島のようになっており、エンタープライズ企業にとってはどこに中心をおいてポリシーを作っていくべきか？　という議論が今後、多く出てくるのではと思わせる回答となった。

GitHub Satelliteで発表された内容以外にオープンソースソフトウェアに関する一般的な質問をツェーゲル氏に行ったので、それもここに記したいと思う。

最近、オープンソースソフトウェアを開発する企業^※2がパブリッククラウドプロバイダーに対して「フリーライドを禁ずる」ライセンスアグリーメントを発表して話題になっているが、こういう状況に対して何かコメントは？

※2 ElasticやMongoDB、Redisなど。

ツェーゲル：一般論で言えば、オープンソースソフトウェアに対してパブリッククラウドプロバイダーがコードを書くことやその他の活動を通して貢献をしていれば、こういう問題は起こらないのだと思う。しかし実際に起こってしまっているというのは不幸なことだと言うしかない。

短期的な視点でサービスを顧客に提供することだけを考えてオープンソースソフトウェアを利用するというのではなく、Googleのように長期的な視点でまずプロジェクトに貢献すること、その上でコミュニティとも良い関係を作ること。これが、最終的にオープンソースソフトウェアのコミュニティ全体に対して良いこととして返ってくるという発想を持つことが重要だと思う。

多くのオープンソースソフトウェアのコードを管理しているGitHubにとって、オープンソースが業界全体に良い影響を与えているということは十分に理解しているとすれば、パブリッククラウドプロバイダーが短期的に利益だけを追求するためにフリーライドすることが好ましい状況だとは言えない。かと言って、営利企業としての目的を無視するもの難しいという双方の論点を理解した上での微妙な回答となった。

カントリーマネージャーの公家氏によれば、GitHubが開催するイベントの中心はGitHub Universeであり、Satelliteはそれを補うために世界中を回る衛星のような存在ということなので、より大きな発表は11月のUniverseまでお預けということだろう。今から11月のイベントが楽しみだ。

説明会で配布されたステッカー

蛇足だが、配布された資料におけるギットハブ・ジャパンの説明に2018年10月に完了したMicrosoftによる買収が記述されていないのは興味深い。