多くの組織は、独自開発よりもコストを抑えられる選択肢と考えてオープンソースソフトウェアを採用しています。しかし、Googleのケーススタディ「How much does it cost to maintain a copy of an open source software package (at Google)?」によると、その保守にも依然としてエンジニアリング上の労力が必要です。
この調査によると、Google社内で保持するオープンソースパッケージのコピーに対する更新の大半は、4エンジニアリング時間以内で完了するとみられます。一方、負荷の大きい更新では、ローカルでの改変、依存関係、影響を受けるソフトウェアの修復が作業量を押し上げ、数日から数カ月に及ぶこともあります。
Googleは、2024年4月から12月にかけて実施された54件のパッケージ更新について、エンジニアリング工数を追跡しました。あわせて、更新に時間がかかる要因について従業員への調査も行っています。
ローカルでの変更が繰り返し作業を生む
パッチ検出結果を利用できた47パッケージのうち、自社独自のパッチを適用しているパッケージの更新工数は、パッチのないパッケージの中央値の3倍でした。一方、平均工数は両グループで同じでした。従業員は、パッチとカスタマイズが追加作業の最大の原因だと指摘しています。
あなたの経験では、OSSパッケージや更新プロセスのどのような特徴が、平均より更新に時間がかかる原因になっていますか。（出典：Google）
企業がオープンソースパッケージのコピーに改変を加えている場合、エンジニアは新バージョンを取り込む際にその変更を考慮しなければなりません。パッチの調整や、互換性の問題の解消が必要になることもあります。
外部依存関係やアップストリームのコントリビューターの数が多いほど、更新工数も大きくなる傾向がありました。元のプロジェクトのリポジトリでの活動状況も、工数との関連を示しています。一方、過去の更新やバージョンのインストール時期、社内での利用度合いについては、更新の複雑さとの間に一貫した関係は見られませんでした。
長期化する更新の原因は修復作業
総工数の中央値は2.2エンジニアリング時間、平均は13.9時間でした。ある更新では、推定400時間を要しています。
「2日を超えた更新では、時間の大半が修復作業に費やされました」と、Google Open SourceのSophia Vargas氏は説明しています。
この作業では、下流の依存関係の問題を解決し、破損部分を修復します。更新はそのパッケージに依存するアプリケーションやほかのコンポーネントに影響を及ぼす場合があり、更新を完了させる前に修復が必要になります。
54件の更新のうち52件では、担当エンジニアはプログラミング言語には精通していたものの、そのパッケージやGoogle社内での使われ方についてはまったく知識がありませんでした。作業に着手できるだけの知識を得るのにかかった時間は、平均で1時間未満でした。
Google特有の環境が結論の一般化を制限
観察対象となった作業は、データ収集期間中にGoogleが実施したパッケージ更新の1%未満にとどまります。更新対象は社内の事業上の優先度に基づいて選ばれており、パッケージのうち52件はGoレンジで書かれたものでした。
Googleは原則として、インポートした各パッケージについて、社内リポジトリで1つのバージョンのみを保持しています。同社のツールやプロセスは、影響を受けたソフトウェアの修復に必要な作業を含め、保守工数に影響を与えています。
この調査では、エンジニアが使用できるツールを指定しておらず、生成AIを含む個々のツールの影響も評価していません。更新が止まったパッケージやアーカイブ済みのパッケージについては、対象範囲が限定的でした。
翻訳元: https://www.helpnetsecurity.com/2026/10/12/google-open-source-maintenance-costs-report/
