【ITニュース解説】Wasted Open Source efforts 😮

オープンソースとは、ソフトウェアの設計図であるソースコードが一般に公開され、誰もが自由に使ったり、改良したり、再配布したりできる開発モデルを指す。世界中の開発者が協力し合い、より良いソフトウェアを生み出すことを目指す、素晴らしい仕組みである。しかし、時にその協力の努力が報われず、無駄になってしまうこともある。今回のニュース記事は、まさにそのような「無駄になったオープンソースへの努力」について、具体的な体験談を交えながら問題提起をしている。

記事の筆者は、音声クローンツールを試そうとしたことから話が始まる。このツールは「PyTorch」という、AIや機械学習の分野で広く使われるフレームワークを基盤としている。筆者は「Docker」という技術を使ってツールを導入しようとした。Dockerは、アプリケーションとその実行に必要な環境（OS、ライブラリなど）をまとめてカプセル化し、どんな環境でも同じように動かせるようにする技術で、これを使うことで、開発者ごとに異なるPC環境に左右されず、同じようにソフトウェアを動かせるはずだった。しかし、筆者がDockerでツールをビルドする（実行可能な状態に準備する）作業は、必要なファイルのダウンロードや構築に非常に時間がかかり、大きな労力を要した。ようやくビルドが完了し、ツールを起動しようとした際、「docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]].」という、初心者には意味が分かりにくいエラーメッセージに直面した。

このエラーは、アプリケーションがPCの「GPU」（Graphics Processing Unit、画像処理に特化した計算装置で、AIの計算を高速化するのに非常に役立つ）を使おうとしたが、それができなかったことを示している。筆者はこの原因を突き止めるため、長時間にわたってウェブ検索を行い、ようやく解決策を見つけた。それは、Linux環境でDocker経由でPyTorchとGPUを連携させるには、「Nvidia Container Toolkit」という追加のツールをPCにインストールする必要がある、というものであった。この重要な情報が、ツールの開発リポジトリ（ソースコードが置かれている場所）にも、PyTorchの公式ドキュメントにも記載されていなかったことに、筆者は強い不満を抱いた。

筆者は、自分が費やした時間と労力を他の開発者には経験してほしくない、という強い思いから、この解決策をドキュメントに追加することを決意した。このような、自身の発見や改善点をプロジェクトに提案し、取り込んでもらう仕組みを「プルリクエスト（PR）」と呼ぶ。これはオープンソースの世界ではごく一般的な貢献方法であり、「自分が問題を解決したら、その解決策をみんなと共有することで、他の人も助かる。それがひいては自分にも返ってくる」という理想的な協力関係を築くことを目指していた。しかし、この理想はすぐに打ち砕かれる。筆者はまず、音声クローンツールのリポジトリに「Issue」（問題報告や機能提案のためのチケット）を立て、ドキュメントの改善を提案した。この提案に対し、リポジトリの管理側からは非常に冷淡で、共感のない返答が返ってきた。筆者の提案が、彼らが定めたIssueのテンプレート（書式）に合致しないという理由で、ほとんど取り合ってもらえなかったのだ。筆者は、このような対応が、新しくプロジェクトに参加しようとする人々にとってどれほど不親切であるか、そしてこれがオープンソースコミュニティで一般的なことではないかと懸念を抱いた。

最初のプロジェクトでの不本意な対応を受け、筆者は諦めなかった。問題の根本はNvidia Container Toolkitのインストール情報がPyTorchのドキュメントにないことだと考え、より大きな「PyTorch」公式リポジトリに対して直接プルリクエストを出すことを決めた。提案内容は、PyTorchのREADME（プロジェクトの概要や使い方を説明するファイル）に、Nvidia Container Toolkitの必要性とインストールガイドへのリンクを追加するという、たった一行の変更だった。しかし、ここでも思わぬ障壁に直面する。プルリクエストを提出するためには、「CLA（Contributor License Agreement）」、つまり「寄稿者ライセンス同意書」への署名が求められたのだ。これは、寄稿されたコードの著作権やライセンスに関する法的な取り決めであり、大規模なオープンソースプロジェクトでは、プロジェクトの法的なリスクを管理するために導入されていることが多い。筆者は、この複雑で理解しにくい法的文書の処理に煩わしさを感じながらも、何とか署名を済ませた。

次に、「CI（Continuous Integration）」、つまり自動テストのプロセスが走った。コードが変更されるたびに自動的にビルドやテストが行われ、既存の機能に悪影響がないか確認される仕組みである。今回はREADMEの修正だけだったので、CIは無事にパスした。翌日、メンテナー（プロジェクトの管理・運営を行う人）がプルリクエストに「triaged」というラベルを付け、他のメンテナーにレビューを依頼した。これは、プルリクエストが初期的な審査を通過し、内容が検討される段階に進んだことを意味するため、筆者は期待した。しかし、その後はまったく反応がなく、沈黙が続いた。一ヶ月が経過すると、「stale bot」（ステイルボット）という自動化されたボットが介入し、プルリクエストを「stale」（活動停止状態）とマークした。これは、長期間活動がないプルリクエストを自動的にクローズするためのボットである。筆者は「not stale」（まだ活動中だ）とコメントしたが、効果はなく、プルリクエストは最終的にオープンされてから二ヶ月後にこのボットによってクローズされてしまった。

筆者にとって、このプルリクエストは単なるドキュメントの修正以上の意味を持っていた。それは、大規模なオープンソースプロジェクトにおいて、個々の開発者が抱える小さな問題や、それを解決しようとする努力が、どれほど尊重され、扱われるのかを測る「テスト」だったのだ。残念ながら、このテストの結果は筆者にとって非常に落胆するものだった。他の開発者の努力や、彼らが現場で直面する細かな問題に対して、プロジェクトの運営側があまり関心を払っていないように感じられたのだ。この経験から、筆者は今後、大規模なリポジトリに対してプルリクエストを行うことに大きな疑問を抱いている。むしろ、自分で解決策をGist（GitHubが提供する簡易的なコード共有サービス）などに公開し、情報を広める方が、無用なやり取りを避けつつ効率的に貢献できるのではないかと考えている。この記事の最後で、筆者は改めて、Linux環境でDockerとPyTorchを使ってGPUを動かそうとして、「docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]].」というエラーに遭遇した場合、Nvidia Container Toolkitのインストールが必要であることを強調している。これは、彼自身の苦い経験から得られた、実用的な教訓であると同時に、オープンソースコミュニティの課題を浮き彫りにする貴重な示唆となっている。