オープンソース。しかし、オープンな貢献ではない。

オープンソース。しかし、オープンな貢献ではない。

大聖堂とバザール

旅の途中のプロンプト:「活気のあるバザールで買い物をする人々、背景にそびえ立つ大聖堂」

GitHub README で、オープンソース プロジェクトの現実に関する非常に興味深い記事を見つけました。

「オープンソースプロジェクト」と聞くと、おそらくGitHubで共同作業を行う開発者を思い浮かべるでしょう。数人のグループがプロジェクトを主導し、プルリクエストが送られてマージされ、バザール開発の「多人数参加型」の恩恵を受けるプロジェクトです。

結局、多くのオープンソース プロジェクトでは代替案である Cathedral が好まれていることがわかりました。

大聖堂?バザール?これらの用語は、エリック・S・レイモンドが1997年に著したソフトウェア開発に関する書籍に由来しています。彼は2つのモデルを対比させています。

  • Cathedralでは、リリースごとにソースコードが公開されますが、リリース間では少数の限定グループによって作業が行われます。
  • 最新のソースコードが常に入手できるバザール

どちらも真のオープンソース開発です。問題は、何人の料理人がキッチンに入るかという点だけです。バザールモデルはLinuxカーネルやBSDプロジェクトなど、大きな成功を収めてきましたが、小規模なプロジェクトでは時に苦戦を強いられることがあります。

なぜでしょうか?オーバーヘッドです。BoltDB作者であるベン・ジョンソン氏の言葉を引用します。

「…サードパーティのパッチを受け入れ、維持することが、私の燃え尽き症候群に繋がり、最終的にはプロジェクトをアーカイブ化することになったことに気づきました」と彼は書いています。「小さな貢献でさえ、適切にテストして検証するには通常何時間もかかりました。コミュニティの関与、そしてバグ報告や機能提案をしてくださる方々には感謝しています。歓迎しているという印象を持たれたくないのですが、私自身の精神衛生とプロジェクトの長期的な存続のために、このプロジェクトへの貢献を非公開にしておくことにしました。」

関わる人が増えるほど、以下の作業にかかる時間も増えます。

  • パッチまたは機能の検証
  • パッチのテストケース
  • 人と話す
  • 人と議論する
  • 機能XがYによって拒否された理由を説明する
  • ドキュメントの更新
  • チュートリアルの更新

…などなど。この記事には他にも役立つ情報がたくさんあるので、ソフトウェア開発やオープンソースプロジェクトに興味がある方はぜひ読んでみてください

おすすめの記事