PはOSSを繋ぎ止めるダクトテープ | OSSのABC

やあ、オタク諸君！OSSのABCへようこそ。ここではオープンソースソフトウェアの世界をアルファベット順に解説していく。僕はテイラー。今日はPの文字…つまりパッチ（修正プログラム）についてだ。オープンソースのガムテープ。絆創膏。小さなヒーローが「ほら、直したぜ！」と告げる存在だ。

パッチはオープンソースの陰の英雄だ。リリースパーティーも派手なローンチ動画もないが、これらがなければ、お気に入りのツールのほとんどは金曜夜のベータ版リリース以上にひどくクラッシュするだろう。

ではパッチとは何か？基本的にはコードへの変更だ。ドキュメントの誤字を見つけたかもしれない。じわじわと正気を失わせたバグを修正したかもしれない。あるいはforループの{が抜けていると知り、眠れなくなっただけかもしれない。何であれ、修正を加え、提出すれば——さあ、プロジェクトへのパッチ適用が正式に完了したのだ。

そしてここが面白いところだ：オープンソースでは、パッチは社員だけが提供するものではない。誰でも提出できる。つまり、週末の趣味でCSSのバグを修正したことが、一生会うことのない何千人もの開発者を助けることになるかもしれない。まるでコードという世界規模の集合知へ、一つひとつのプルリクエストで恩返しをしているようなものだ。

でも現実を見よう——パッチを書く作業がいつも順風満帆とは限らない。まず何が実際に壊れているのか見極めなければならない。次に誰かが書いたスパゲッティコードを掘り起こして修正する。その後は？テストだ。ドキュメントだ。スタイルガイドだ。ああ、それとgit fetchと言う間もなくメインブランチが動いてしまうから、ブランチのリベースも忘れるな。

パッチ適用作業は、スプーンとフォークが一体になったスプークで手術しようとするような感覚だ。しかし同時に、最も純粋な貢献の形でもある。問題を見つけた時、Redditで愚痴をこぼす代わりに、袖をまくり上げて自ら解決したのだから。

そして肝心なのは、レガシーソフトウェアやサポート終了ソフトウェアにおいて、パッチが命綱だということだ。リポジトリを監視する者がいなくなっても、システムを安全に機能させ、ほんの少し長く稼働させ続けるのはパッチである。まるで過去から「まだ見守っているよ」と書かれた絵葉書を送るようなものだ。

だから、一行の修正であれ完全なリファクタリングであれ、覚えておいてほしい——どのパッチも脈拍の確認だ。それは「このプロジェクトは重要だ。まだ死んではいない」と告げているのだ。

OSSのABC、Pの回にお付き合いいただきありがとうございます。次回はQ、品質保証（Quality Assurance）に取り組みます。ここで、これらのパッチが他の部分を壊さないようにする方法を見ていきましょう。それまでは、差分（diff）をきれいに保ち、マージ競合（merge conflict）を最小限に抑えておいてくださいね。じゃあね！