プログラマーの死後のオープンソースプロジェクトの運命

最近亡くなったジム・ワイリッヒや彼のプログラムについて聞いたことがないでしょう。 しかし、あなたは彼の仕事に基づいて構築されたアプリケーションをほぼ確実に使用しました。



Weirichは、Hulu、Kickstarter、Twitterなどのサイトのコードで記述された人気のあるプログラミング言語であるRubyのいくつかの主要なツールの作成を支援しました。 彼のコードのソースは公開されていたため、誰でも使用および変更できました。 「彼はWestern Rubyコミュニティの多産なメンバーでした」と、Ruby開発者でソフトウェア開発会社Test Doubleの共同設立者であるJustin Searls氏は述べています。



2014年にWeirichが亡くなったとき、Searlesは、ソフトウェアをチェックするためのWeirichのツールのいずれもサポートしていないことに気付きました。 つまり、他の開発者がプロ​​ジェクトにバグ修正、セキュリティパッチ、またはその他の改善を送信した場合、誰も変更を承認しません。 このツールに基づくテストは、コードが廃止され、新しいテクノロジとの互換性がなくなるため、最終的に失敗します。



このケースは、オープンソースソフトウェアコミュニティにおける懸念の高まりを反映しています。 プログラマの死後、コードはどうなりますか？ ユーザーの死亡後、ソーシャルアカウントを使用したソーシャルネットワークで何が起こるかについては、すでに多くの記事が執筆されています。 しかし、プログラマーにとって、この問題はそれほど深刻ではありませんでした。 一部の企業と政府は、人々のチームによってサポートされている商用ソフトウェアに依存しているためです。 しかし今日、より多くのプログラムが、Weirichのようにあまり知られていないが重要なソフトウェアに依存しています。



Linux OSまたはGoogle TensorFlowの人工知能プラットフォームなど、いくつかのオープンソースプロジェクトが有名です。 しかし、そのようなプロジェクトはそれぞれ、小さなオープンソースライブラリに依存しています。 そして、これらのライブラリは他のライブラリに依存しています。 その結果、ソフトウェア依存関係の複雑で、ほとんど隠されたネットワークができます。



これは2014年に発生した、Heartbleedと呼ばれるセキュリティ脆弱性を伴う大きな問題につながる可能性があります。これは、銀行カードの支払いを処理するほとんどすべてのWebサイトで使用されるソースコードプログラムであるOpenSSLにあります。 このソフトウェアはLinuxのほとんどのバージョンに付属していますが、包括的なセキュリティ監査を実施する時間もリソースもないボランティアの小さなチームによってサポートされていました。 このような大失敗の後まもなく、別の一般的に使用されるオープンソースプログラムであるBashでセキュリティ問題が発見されました。これにより、無数のWebサーバーやその他のデバイスが攻撃に対して脆弱になりました。



まだ未解決の脆弱性があります。 ソフトウェアプロジェクト間の関係を分析する人々のグループ、Libraries.ioは、少なくとも1,000の他のプログラムで使用されている2,400を超えるオープンソースライブラリを発見しましたが 、これらはオープンソースコミュニティから適切な注目を集めていませんでした。



また、セキュリティ上の欠陥は問題の一部にすぎません。 ソフトウェアライブラリを更新しないと、新しいプログラムでの動作が停止する場合があります。 つまり、古いライブラリに依存するアプリケーションは、他のソフトウェアを更新した後に動作を停止する可能性があります。 開発者がプロ​​ジェクトを終了または放棄すると、このソフトウェアに依存しているすべての人が苦しむ可能性があります。 昨年、プログラマーのAzerKoçuluがインターネットから小さなLeftpadライブラリを削除したとき[Leftpadだけでなく、左パッドも、インターネットからではなく、npmパッケージストレージシステムから / transl。]、発散効果につながり、Facebook、Netflix、およびその他のプロジェクトのサポートに頭痛の種を追加しました 。

バス係数

コードの一部を所有する人が少ないほど、コードが所有者なしで放置されるリスクが高くなります。 開発者はそのようなケースに対して悲観的な用語さえ持っています- バスファクターは、プロジェクトをサポートする誰もいない前にバスがノックダウンしなければならない人々の数を意味します。 Libraries.ioは、サポートするプログラマがほとんどいない他の多くのプログラムで使用されている約3,000のオープンソースライブラリを特定しました。



孤立したプロジェクトは、オープンソースソフトウェアを使用するリスクがありますが、商用ソフトウェアメーカーは、古いプログラムのサポートや更新を停止することにより、ユーザーを同じ立場に置くことができます。 場合によっては、責任あるプログラマーが孤立したオープンソースプロジェクトを採用します。



SearlesはこれをWeirichのプロジェクトの1つで行いました。 彼の死の時に彼の最も人気のあるプロジェクトは、他の誰かと一緒に彼によって管理されました。 しかし、 Searlsは 1つのプロジェクト、 Rspec-Givenのテストツールを見つけました。 しかし、彼はいくつかの困難に遭遇しました。



Rspec-Givenは、GitHubコードのコラボレーションと配置のために人気のあるサイトに住んでおり、約6700万のプロジェクトがあります。 GitHubのRspec-GivenのWeirichページは、他の人々がバグを報告したり、コードの改善に役立つ情報を提供したりする主要な場所でした。 しかし、GitHubはシアーズにページのコントロールを与えたくありませんでした。なぜなら、ワイリッヒは死ぬ前にそのような権利を彼に与えなかったからです。 そのため、Searlesはコードの新しいコピーを作成し、別の場所に配置する必要がありました。 また、コード配布パッケージ管理システムであるRuby GemsのオペレーターにWeinrichのバージョンではなくRspec-Givenのバージョンを使用するよう説得し、すべてのユーザーがSearlsによる変更にアクセスできるようにしなければなりませんでした。 GitHubは、プロジェクトの転送ルールに関するコメントを拒否しました。



これにより、Rspec-Givenに関連する潜在的な問題は解決しましたが、Searlesがどれだけ間違っている可能性があるのか​​目を開きました。 「オープンソースプロジェクトを純粋に技術的な現象として扱うのは簡単です」とSearls氏は言います。 「しかし、何かが始まるとすぐに、他の何百人もの人々の仕事がそれに依存している場合、それも社会現象になります。」



ほとんどのパッケージ管理システムのサポートグループには、ライブラリの制御を移すプロセスが少なくとも1つありますが、通常、プロジェクトが孤立していることに気づき、それをサポートするボランティアに依存します。 「このような問題は頻繁に発生しないため、このテーマに関する公式ルールはありません」とRuby GemsプロジェクトのIvan Phoenix氏は言います。 「このような問題を個別に解決する専門家のアドバイスがあります。」



一部のパッケージ管理システムは、ライブラリを追跡し、長期間更新されていない一般的に使用されるプロジェクトをマークします。 Perlプログラミング言語のパッケージシステムの保守を支援するNeil Bowers氏は、孤児プロジェクトをサポートするボランティアを探すこともあると言います。

デッドマントリガー

Rspec-Givenを管理することで、当時30歳だったSearlsは、オープンソースプロジェクトの譲渡の意志と計画を書きました。 開発者は、プロジェクトの将来を確保するために他のアクションを実行できます。 たとえば、Apache Foundationなどの一部の財団に権利を譲渡します。 しかし、多くのオープンソースプロジェクトは趣味として開始されることが多いため、プログラマーは手遅れになるまで権利の移転について考える必要がないかもしれません。



Searlsは、GitHubとGemsなどのパッケージ管理システムが自身に「デッドマントリガー」を追加し、この作成者が特定の期間ログインまたはプロジェクトに変更を加えていない場合、プログラマーがプロジェクトまたはアカウント管理を他の誰かに自動的に転送できるようにすることを提案しています時間。



しかし、転送計画は、コードへのアクセスを他の人に公開することだけではありません。 2012年に作成者のジョンハンターが亡くなった後、人気のある数学ライブラリMatplotlibの開発を引き継いだMichael Drotbomは、後継者もコードを理解する必要があることを示しています。 「コードには、たった1人しか理解できない部分があることがあります」と彼は言います。 「知識は一人の人間の頭の中にしか存在しません。」



これは、開発者以外の人々がプロジェクトを使い始めた直後に、人々がプロジェクトに早期に関与する必要があることを意味します。 Searls氏によると、このアプローチには別の利点があります。プロジェクトをサポートするための作業の分散は、開発者の「燃え尽き」を防ぐのに役立ちます。