故ジム・ワイリッチ氏や彼が開発したソフトウェアについて聞いたことがない方もいるかもしれません。しかし、彼の研究に基づいて開発された様々なアプリケーションは、きっと使ったことがあるでしょう。

ワイリッチ氏は、Hulu、Kickstarter、Twitter、その他数え切れ​​ないほどの主要ウェブサイトのコードで使用されているオブジェクト指向スクリプト言語であるRubyの主要ツールをいくつか開発しました。Rubyのコードはオープンソースであるため、誰でも使用・改変できます。Ruby開発者であり、ソフトウェア会社Test Doubleの共同創業者であるジャスティン・シールズ氏は、「ワイリッチ氏は西洋諸国におけるRubyコミュニティの創始者の一人です」と述べています。

2014年にワイリッヒが亡くなったとき、シールズ氏は彼のソフトウェアテストツールの一つが誰もメンテナンスしていないことに気づきました。これは、他の開発者がバグ修正、セキュリティパッチ、その他の改善をRubyコミュニティに提出しても、誰もその変更を承認しないということを意味していました。そのツールに依存するテストは、コードが時間の経過とともに陳腐化し、新しいテクノロジーとの互換性を失うため、最終的には失敗することになります。

この事件は、オープンソースソフトウェアコミュニティ内で高まっている懸念を浮き彫りにしました。それは、プログラマーが書いたコードは死後どうなるのか、というものです。ユーザーの死後、ソーシャルメディアアカウントがどうなるかについては、多くの記事が書かれています。しかし、プログラマーの死はそれほど深刻な問題ではありません。これは、ほとんどの企業や政府が商用ソフトウェアを運用しており、専任の担当者がメンテナンスを行っていることが一因です。しかしながら、現在ではますます多くのプログラムが、ワイリッヒのようなプログラマーによって開発された、あまり知られていないものの重要なオープンソースソフトウェアに依存しています。

LinuxオペレーティングシステムやGoogleの人工知能フレームワークTensorFlowなど、よく知られているオープンソースプロジェクトもあります。しかし、これらのプロジェクトはすべて、より小規模なオープンソースコードライブラリに依存しており、そのコードライブラリもまた別のコードライブラリに基づいています。その結果、複雑で、しばしば目に見えない、相互依存的なソフトウェアネットワークが形成されています。

これは重大な問題につながる可能性があります。例えば、2014年には、クレジットカードやデビットカード決済を処理するほぼすべてのウェブサイトで使用されているオープンソースプログラムであるOpenSSLに、「Heartbleed」と呼ばれるセキュリティ脆弱性が発見されました。このソフトウェアはほとんどのLinuxディストリビューションにバンドルされていましたが、大規模なセキュリティ監査を行う時間やリソースが不足していた少数のボランティアによってメンテナンスされていました。Heartbleed脆弱性が発見されて間もなく、別の一般的なオープンソースアプリケーションであるBashにも同様のセキュリティ欠陥が見つかり、無数のウェブサーバーやその他のデバイスが攻撃に対して脆弱になりました。

未発見の脆弱性は確かに数多く存在します。Libraries.ioはソフトウェアプロジェクト間の関係性を分析するチームであり、1,000以上のプログラムで使用されている2,400以上のオープンソースコードライブラリを特定していますが、オープンソースコミュニティからはほとんど注目されていません。

セキュリティは問題の一部に過ぎません。ソフトウェアライブラリがタイムリーに更新されない場合、ソフトウェアのアップグレードは機能しません。つまり、古いライブラリに依存するアプリケーションは、ユーザーがソフトウェアを更新した後に機能しなくなる可能性があります。コードベースを保守している開発者が亡くなったり、プロジェクトを放棄したりすると、そのソフトウェアを使用しているすべての人に影響が及びます。昨年、プログラマーのAzerKo ulu氏がLeftpadというコードベースをインターネットから削除したことで、波及効果が生じ、Facebook、Netflix、その他多くの企業で問題が生じたと報じられています。

バス係数

オープンソースソフトウェアのメンテナーが少ないほど、孤立化のリスクが高まります。開発者の間では、この状況を「バス係数」という陰鬱な言葉で表現するほどです。これは、オープンソースプロジェクトを誰もメンテナーがいなくなった場合に影響を受ける人数を指します。Libraries.ioは、多くのプログラムで使用されているものの、ひっそりと貢献しているオープンソースライブラリは約3,000個あると特定しています。

プロジェクトの孤立はオープンソースソフトウェアを使用する際のリスクですが、商用ソフトウェアベンダーも古いプログラムのサポートやアップデートを停止する可能性があり、ユーザーに同様の問題を引き起こす可能性があります。場合によっては、悪意のあるプログラマーが孤立したオープンソースコードを悪用する可能性もあります。

これは、シールズ氏がWeirichオープンソースプロジェクトで作業していた際に遭遇した問題の一つです。Weirich氏が亡くなった後も、彼の最も人気のあったプロジェクトには共同管理者がいました。しかし、シールズ氏はテストツールであるRspec-Givenが引き継がれていないことに気づきました。彼はRspec-Givenのアップデートを担当するつもりでしたが、その過程で多くの問題に直面しました。

Rspec-Givenのコードは、現在6,700万のリポジトリを誇るコードホスティングおよびコラボレーションサイトであるGitHubでホストされています。Weirich氏のGitHub上のRspec-Givenページは、他のRubyユーザーがバグを報告したり、コードの改善に協力したりする主要な場所です。しかし、Weirich氏が生前にこのページに名前を付けていなかったため、GitHubはSearches氏にこのページの管理を許可しませんでした。そのため、Searches氏はコードの新しいコピーを作成し、別の場所に移さなければなりませんでした。また、コードを配布する「パッケージ管理システム」であるRuby Gemsの運営者にも、Weirich氏のバージョンではなくSearches氏のバージョンのRspec-Givenを使用するよう説得し、すべてのユーザーが変更にアクセスできるようにしました。GitHubは、プロジェクトの管理権の移管に関する方針についてコメントを拒否しました。

このアプローチはRspec-Givenに関連する潜在的な問題に対処しましたが、同時にSearls氏には多くの潜在的な問題点も明らかになりました。Searls氏は次のように述べています。「オープンソースを純粋に技術的な現象と捉えるのは簡単です。しかし、何かが作られ、他者に利用されると、それは社会的な現象にもなります。」

ほとんどのパッケージ管理システムには、リポジトリの管理権を移管するための専用のプロセスが少なくとも用意されていますが、このプロセスは、プロジェクトが孤立していることに気づいた誰かが自発的に引き継ぐという状況に大きく依存しています。「公式のポリシーはありません。主に、このようなケースは頻繁に発生しないからです」と、Ruby Gemsプロジェクトのエヴァン・フェニックス氏は言います。「このような事態については、ケースバイケースで対応するための諮問委員会を設けています。」

現在、一部のパッケージマネージャーはライブラリの実行状況を監視し、長期間更新されていないものの頻繁に使用されているプロジェクトにフラグを立てています。Perlパッケージマネージャーのメンテナンスに携わるニール・バウアーズ氏は、孤立したプロジェクトを引き継ぐボランティアを探すことがあると言います。バウアーズ氏によると、彼のチームは開発者によって放棄されたプロジェクトを頻繁に指摘し、引き継ぐよう勧めているそうです。

「デススイッチ」

サールズ氏はRspec-Givenを引き継いだ当時まだ30歳でしたが、オープンソースプロジェクトの遺言と後継者計画を準備していました。開発者は、その他にも将来に向けて様々な努力をすることができます。例えば、Apache Foundationなどの他の組織に著作権を譲渡することも可能です。しかし、多くのオープンソースプロジェクトは基本的に趣味として始められるため、プログラマーは所有権の譲渡について考えないことが多く、気づいた時には手遅れになっていることがよくあります。

Searls 氏は、GitHub や Gems などのパッケージ マネージャーがプラットフォームに「デッドエンド スイッチ」のようなものを追加して、作成者がログインしていないか長期間更新していない場合にプロジェクトまたはアカウントの所有権を自動的に他のユーザーに移譲できると考えています。

移行計画は、単にコードへのアクセスを提供するだけにとどまりません。Pythonで書かれた2DデジタルプロットライブラリであるMatplotlibは、2012年に創設者のジョン・ハンター氏が亡くなった後、マイケル・ドレットブーム氏に引き継がれました。ドレットブーム氏は、後継者はコードを理解する必要があると指摘します。「コードの一部しか理解できないこともあります。知識は一人の人間の頭の中にしか存在しないのです。」

つまり、理想的には、プロジェクトが元の開発者以外の誰かによって使用されるようになったら、できるだけ早く他の人をプロジェクトに参加させる必要があるということです。Searls氏は、これには別の利点もあると指摘しています。それは、プロジェクトのメンテナンスタスクを割り当てることができ、開発者のバーンアウトを防ぐことができるということです。