Claudeへ問う「バザール型開発のやり方を教えて」

バザール型開発モデルは、オープンソースソフトウェアの開発において広く採用されている手法です。主な特徴は以下の通りです。

1. 公開性: ソースコードは一般に公開され、誰もがアクセスできます。開発の過程が透明化されています。
2. 分散性: 世界中の多数の開発者が自発的に参加し、並行して開発を進めます。開発者たちはインターネットを介して疎結合的に協力します。
3. 遊牧性: 開発者は自由に移動でき、複数のプロジェクトに参加できます。特定のプロジェクトに縛られません。
4. ボトムアップ: 開発の方向性は上意下達ではなく、開発者コミュニティの合意から自然と生まれます。良いアイデアが支持を集めていきます。
5. 早期の公開と頻繁なリリース: 開発初期の段階からソースコードを公開し、頻繁にリリースすることで、ユーザーからの早期フィードバックを得ます。
6. 並行バグ修正: 多数の開発者が並行してバグ修正に取り組むことで、迅速な修正が可能になります。

バザール型開発は、大勢の自発的な貢献者から成り立っており、トップダウンの開発モデルとは対照的なアプローチです。柔軟で分散型の開発が行われ、優れたアイデアが伸張する傾向があります。

バザール型開発におけるソフトウェアの企画から開発、リリース、アップデート/アップグレードまでの一般的なプロセスは以下の通りです。

1. 企画段階

   • 新しいソフトウェアのアイデアが誰かの発案から生まれる
   • メーリングリストやフォーラムで議論が始まり、関心を持つ開発者が集まる
   • 要件定義やスコープ、目標が徐々にプロジェクトコミュニティの合意で決まっていく

2. 開発段階

   • ソースコード管理システム(GitHubなど)上で共同開発が開始される
   • 開発者は自由に機能の実装やバグ修正に取り組む
   • レビューとテストを重ねながら、品質を高めていく
   • 頻繁にソースコードが公開され、外部の開発者からもフィードバックが得られる

3. リリース段階

   • ある程度の機能が実装され、ある水準の品質が確保されたらリリース候補が決定される
   • コミュニティでレビューが行われ、リリースが承認される
   • パッケージ化されたソフトウェアが公開リポジトリに公開される

4. アップデート/アップグレードの段階

   • リリース後も開発は続き、新機能の実装やバグ修正が行われる
   • 重要な更新が積もれば、新しいリリースとしてアップグレードされる
   • マイナーアップデートは頻繁に公開され、ユーザーに通知される
   • メジャーアップグレードはある程度の間隔を置いて行われる

このように、企画からリリース、アップグレードまで、多くの開発者が参加し、合意形成を重ねながらソフトウェアが進化していきます。オープンで分散型のプロセスが特徴的です。

バザール型開発においては、安定版(stable)と開発版(unstable)の2系統以上のバージョンが併存していることが多くあります。それぞれのバージョンの開発プロセスは以下のように異なります。

安定版(stable)の開発プロセス:

• 安定版は製品の品質と信頼性が最優先される
• 新機能の実装よりも、バグ修正とセキュリティ更新が中心
• リリースサイクルは半年~1年程度と比較的長め
• 開発者コミュニティ内の合意を経て、慎重にリリースされる
• 企業や組織では、安定版を採用することが多い

最新版(unstable/testing)の開発プロセス:

• 新機能の実装が最優先され、積極的に変更が加えられる
• バグの修正よりも新機能の実装に重きが置かれる
• 頻繁に新バージョンがリリースされる(週単位など)
• 先駆的なユーザーや開発者が使用し、フィードバックを提供
• 安定版へマージされる前の実質的な開発の場

これら2系統のバージョンは、通常は別々のリポジトリで開発が進められます。安定版では確実性が重視され、最新版では機能の先行開発が行われています。

最新版で十分にテストが行われた新機能は、安定版の次期メジャーリリースに取り込まれていきます。この過程で開発者コミュニティによる厳しいレビューとフィードバックを経て、品質が確保されます。

このようなマルチストリーム開発により、安全性と新機能の両立を図ることができます。

バザール型開発では、新機能の導入、不具合管理、作業分担、進捗管理、ユーザーフィードバックの対応など、様々な側面で特徴的な運営方式が取られています。

新機能の導入

• 新機能のアイデアはメーリングリスト、Issue トラッカー、フォーラムなどで提案される
• 有用性や実現可能性が議論され、コミュニティからの合意を経て実装が進められる
• 最新版リポジトリに実装されたものが並行してテストされる

不具合の管理

• ユーザーやテスターから報告されたバグはIssue トラッカーに集約される
• バグの重要度や影響範囲に基づいて優先順位が付けられる
• 開発者コミュニティからボランティアが修正に着手する

作業分担の管理

• 作業は基本的に自発的なボランティアベースで分担される
• 熱意のある開発者が中心となって機能の実装を主導する
• メンターと呼ばれる有力開発者が全体の進捗や品質を監視する

進捗管理

• ロードマップは柔軟に変更されることが多い
• マイルストーンやIssueに沿って進捗を管理する
• 定期的な開発者ミーティングでスケジュールの調整を行う

ユーザーフィードバック対応

• バグ報告のほか、新機能の要望もユーザーから寄せられる
• ユーザーコミュニティのモデレーターがフィードバックを集約する
• 開発に取り込むかどうかは、コミュニティでの議論を経て決定される

このように、バザール型開発では分散型で自発的な参加に基づいた柔軟な開発が行われますが、同時にコミュニティプロセスを通じてある程度の管理と調整も行われています。

バザール型開発では基本的には自由な参加が認められていますが、一定の選別やメンターの選出プロセスがあります。

参加者の選別

• 原則として誰でも参加可能ですが、実際にコードを書く開発者になるには一定の審査があります。
• プルリクエストを通じてコーディングスキルを実際に示す必要があります。
• コードレビューを経て、品質基準を満たせばコミットする権限が与えられます。
• 中核となるコアコミッターの地位を得るには、長期に渡る優れた貢献と、コミュニティでの評価が必要です。

メンターの選出

• メンターとは、プロジェクト全体を見渡し、新参者のサポートや技術的な方向性を決める有力開発者です。
• メンターはコアコミッターから選ばれることが一般的です。 -優れた技術力と長期の貢献実績、コミュニティでの影響力が重要な指標となります。 -既存のメンターによる推薦や、コミュニティ投票などの過程を経て正式に選出されます。

つまりコアコミッターやメンターといった中核メンバーになるには一定の関門がありますが、初心者でも自由に参加し徐々にスキルとコミュニティでの評価を高めていくことができます。実力主義とオープンさが両立しているのがバザール型開発の特徴です。

バザール型開発におけるプロジェクトメンバーの規模は、ソフトウェアの大きさや人気度合いによって大きく異なります。しかし一般的な目安として、以下のようなメンバー構成が考えられます。

【小規模プロジェクト】(10人程度まで)

• メンター: 1-2人
• コアコミッター(中核開発者): 2-4人
• 貢献開発者: 3-5人
• テスター/ユーザー: 多くて10人程度

【中規模プロジェクト】(10-100人程度)

• メンター: 2-5人
• コアコミッター: 5-15人
• 貢献開発者: 10-30人
• テスター/一般ユーザー: 50-500人程度

【大規模プロジェクト】(100人以上)

• メンター: 5-10人以上
• コアコミッター: 20人以上
• 貢献開発者: 50人以上
• テスター/一般ユーザー: 1,000人以上

人数の内訳を役割別にみると、おおよそ以下のようになります。

• メンター: 全体の1-5%程度
• コアコミッター: 全体の5-10%程度
• 貢献開発者: 全体の10-30%程度
• テスター/一般ユーザー: 全体の60-80%程度

つまり、中核メンバーは全体の20%以下が一般的です。残りの大多数はテスター、一般ユーザー、時折的な貢献者となります。

また、有名で人気の高いプロジェクトほど、一般ユーザー数が格段に多くなる傾向があります。代表的なオープンソースプロジェクトでは、数万人規模のユーザー/テスター層を抱えているケースもあります。

メンター、コアコミッター、貢献開発者は、以下のような具体的な役割を担っています。

【メンター】

• プロジェクト全体の技術的な方向性を決定する
• 新機能の採否や優先順位を判断する
• コードレビューを行い、品質を監視する
• 新規参加者の教育とサポートを行う
• コミュニティ運営全般を監督する
• コアコミッターの承認や選出を行う

【コアコミッター(中核開発者)】

• プロジェクトの中核となるコード改修を担当する
• 重要な新機能の実装を主導する
• バグ修正作業を積極的に行う
• プルリクエストのレビューを行う
• メンターと協力しながらプロジェクトの方向性に関与する
• 新規参加者の育成・指導を行う

【貢献開発者】

• 比較的小規模な新機能の実装を行う
• バグ報告やバグ修正に貢献する
• ドキュメンテーションの執筆や翻訳を行う
• テストの実施やテストコードの作成を行う
• コードレビューでフィードバックを提供する

つまり、メンターはプロジェクト全体のガバナンスと技術的指導を担い、コアコミッターはプロジェクトの中核をなすコーディングを主導し、貢献開発者は様々な形で機能実装やメンテナンスに貢献します。

これらの役割分担と協力によって、オープンソースプロジェクトの機能拡張とメンテナンスが効率的に進められるのです。

オープンソースソフトウェア(OSS)の著作権については、以下のような特徴があります。

著作権の保持

• OSSの場合でも、ソースコードには著作権が存在します。
• 著作権者は、通常、そのソースコードを書いた個人または団体(企業など)になります。

オープンソースライセンス

• OSSでは、著作権者がオープンソースのライセンスを設定し、そのライセンスに従ってソースコードを自由に利用できるようにしています。
• 代表的なオープンソースライセンスには、MIT、Apache、GNU GPLなどがあります。
• ライセンスによって、ソースコードの改変や再配布の条件が異なります。

コピーレフトとパーミッシブ

• GNU GPLのようなコピーレフトライセンスは、ソースコードの改変物もGPLで公開することを求めます。
• MITライセンスなどのパーミッシブライセンスは、改変物の扱いをより自由にしています。

ソースコードのクレジット表示

• ほとんどのOSSライセンスでは、ソースコードを利用する際にオリジナルの著作権者のクレジットを表示することが求められています。

企業とOSS

• 企業がOSSを利用する際は、そのライセンスを遵守する必要があります。
• 一方で、企業がOSSに貢献してコードを提供した場合、その企業も当該コードの著作権者となります。

このように、OSSではオープンソースライセンスを通じて著作権者がコードの利用条件を設定しますが、同時に他者によるコードの自由な利用を認めています。このバランスが取れているのがOSSの特徴です。

オープンソースライセンスには主に以下のような種類があり、それぞれ特徴が異なります。

パーミッシブライセンス

• MIT、BSD、Apacheライセンスなどが代表的
• ソースコードの改変や再配布を非常に自由に許可
• 改変したコードを公開するかどうかも任意
• 著作権表示のみを求める簡単なライセンス

コピーレフトライセンス

• GPL(General Public License)がもっとも有名
• ソースコードの改変物も同じGPLでライセンスする義務がある
• オリジナルのコードと改変コードを明確に区別できなくなるため、GPL感染と呼ばれる
• オープンソースの精神を守るためにコピーレフト条項を設ける

LGPL(Lesser GPLライセンス)

• GPLの制約をある程度緩和したライセンス
• 独自のコードとLGPLコードをリンクできるが、LGPLコードの改変部分はLGPLで公開する必要がある

デュアルライセンス

• 商用利用と非商用利用で、ライセンスを使い分ける
• 非商用の場合はオープンソースライセンスを適用
• 商用利用の場合は、有償の独自ライセンスを適用

ライセンスを選ぶ際は、どの程度の自由度を許容するか、オープンソース精神をどこまで重視するかが主な判断基準となります。プロジェクトの方針に合わせて、最適なライセンスを採用する必要があります。

また、複数のオープンソースコードを組み合わせて利用する場合は、それらのライセンス同士が矛盾しないかに注意を払う必要があります。

はい、一部の営利企業においても、バザール型開発が採用されるケースがあります。

その主な理由としては、以下のようなメリットが挙げられます。

1. 優秀な人材の参加を促進 オープンな開発では、能力の高い開発者が世界中から自発的に参加しやすくなります。優秀な人材が集まることで、高品質なソフトウェアが開発できます。
2. ユーザーからの直接的なフィードバック 開発の初期段階からソースコードを公開することで、ユーザーからリアルタイムのフィードバックが得られます。ユーザー要求に応えた製品開発ができます。
3. 迅速な機能拡張とメンテナンス
   多くの開発者が並行して機能追加やバグ修正に取り組めるため、アップデートのサイクルを速くできます。
4. コストの削減 組織内で抱え込む必要がないため、開発コストを抑えられる可能性があります。

ただし、営利企業が採用する際は、以下のような課題にも留意が必要です。

• 機密情報の取り扱いへの配慮
• 知的財産権の確保
• コミュニティの運営管理
• 最終的な製品の品質保証

そのため、完全にオープンにするのではなく、一部のモジュールやコードのみをオープン化するなど、ハイブリッドな形態を取ることが多くなっています。代表例としては、Microsoftの.NETプラットフォームなどがあげられます。

営利目的のソフトウェア開発においてバザール型の開発手法を採用する場合、開発メンバーへの対価支払いについては、以下のようなパターンが一般的です。

1. 中核開発者への給与支払い プロジェクトの中核となるコアコミッターやメンターについては、企業から給与を支払うことが多くみられます。彼らは企業の正規従業員または契約従業員として雇用されています。技術的な方向性の決定や重要機能の実装など、プロジェクトの中心的役割を担います。
2. 外部貢献者へのバウンティ支払い 一方で、外部から参加する貢献開発者に対しては、実装した機能やバグ修正の価値に応じて、バウンティ(報酬)を支払うケースがあります。優れた外部コードに対して事後的に報酬を渡すスタイルです。
3. オープンソース財団への寄付 プロジェクトを支えるオープンソースコミュニティへの還元として、関連する非営利財団に寄付を行うこともあります。財団はそれらの資金で外部開発者への奨励金を出したり、イベントを開催したりします。
4. ソースコードのクローズ化 完全にオープンにせず、最終的な製品のソースコードは企業内でクローズ化し、オープン部分は限定的にするハイブリッド型もあります。

つまり、核となる部分の開発は企業内の人員で行い、周辺機能の一部をオープンに外部と協力しながら開発を進める、というパターンが多くみられます。完全にオープンなケースは限られています。

企業は自社プロダクトの根幹部分の管理は維持しつつ、メリットの高い部分のみでバザール型の手法を上手く取り入れる、ハイブリッドな形態を選ぶ傾向にあります。

バザール型開発には以下のような主な欠点や課題があげられます。

1. 計画性と方向性の不確実性 多数の開発者が自由に関与するため、事前の詳細な計画を立てにくく、開発の方向性が常に確定しない状態にあります。要件の変更が頻繁に発生するリスクがあります。
2. 品質と一貫性の担保が困難 開発者の力量にばらつきがあり、コーディングスタイルも様々です。全体として一貫した品質とアーキテクチャを維持することが難しい場合があります。
3. リーダーシップとガバナンスの重要性 自由な開発を統括するリーダーシップとガバナンスが非常に重要になりますが、意思決定プロセスが複雑で困難を伴うことがあります。
4. セキュリティとバグ対応の遅れ
   分散開発のため、深刻なバグやセキュリティホールへの対応が遅れる可能性があります。責任の所在が不明確になりがちです。
5. 活動維持のモチベーション確保 ボランティアベースの開発では、メンバーのモチベーション維持が課題となります。活動が停滞するリスクがあります。
6. ドキュメンテーションの不足 開発者主導のため、ドキュメントの作成や保守が不十分になりがちです。

このように、バザール型開発では分散性と自由度が高いため、計画性や品質管理、責任の所在などについて課題が生じる可能性があります。うまく機能するには適切なガバナンスが重要になってきます。

はい、リーダーシップとガバナンスを適切に機能させるために、多くのオープンソースプロジェクトで様々な工夫がなされています。

メンターやコアコミッターの選出プロセス

• 貢献実績の評価基準を明確化し、客観的に選出する
• コミュニティ投票などで信任を問う
• ロールやゾーンを明確化し、責任範囲を定める

意思決定プロセスの標準化

• メーリングリストや定期ミーティングでの合意形成
• 投票制による多数決の採用
• 拒否権の設定や上位メンターによる最終決定権付与

行動規範やポリシーの制定

• コントリビューションポリシーや行動規範を文書化
• 違反時の制裁措置や解決プロセスを明記
• コミュニティの価値観を共有し遵守することを求める

商用プロダクト開発との切り分け

• コアプロダクトとコミュニティ版を分離
• 企業による開発部分と一般公開部分を分ける
• 価値の高いコア部分は企業が完全管理

財団やスポンサー企業の役割

• 財団がプロジェクトのガバナンスを監督
• プロジェクトリーダーの任命や資金面の支援
• スポンサー企業がガバナンスに積極的に関与

このように、様々な側面から、分散開発の弱点を補い、一定の統制を図るための工夫が重ねられています。ただし、依然として運営の難しさは大きな課題となっています。

確かにバザール型開発においては、品質と一貫性を確保することが大きな課題となります。その理由は主に以下の点にあります。

1. 開発者の力量のばらつき プロジェクトに参加する開発者の技術力には大きなばらつきがあります。上級者から初級者まで混在しており、誰がどのような品質のコードを書くかを統制することは難しいです。
2. コーディングスタイルやルールの不統一 参加者が世界中から集まるため、コーディングスタイルやルール、手法が開発者ごとに異なります。統一されたアーキテクチャやコーディング規約を守らせるのが困難です。
3. 開発プロセスの非標準化 開発手順やテスト、レビューのプロセスが、開発者ごとにバラバラになりがちです。品質管理のための標準的な開発ライフサイクルを確立するのが難しいことがあります。
4. 膨大な規模と複雑性 大規模プロジェクトでは、コードベースが膨大で複雑になります。全体の一貫性と品質を保つのは非常にチャレンジングな作業となります。
5. 説明責任の所在の不明確さ バグや品質問題が発生した際に、最終的な責任の所在が不明確になりがちです。開発者個人への説明責任を求めづらいケースがあります。

そのため、品質確保のためには以下のような取り組みが重要となります。

• 厳格なコードレビューやテストの実施
• コーディング規約やスタイルガイドの統一
• メンターやコア開発者による監視と指導
• 品質基準やポリシーの文書化と徹底
• 自動テストや静的解析などの品質ツールの活用

バザール型開発の柔軟性と分散性を活かしつつ、このような施策で品質と一貫性の確保を図る必要があるのです。

バザール型開発で成功しているオープンソースプロジェクトの代表例は以下の通りです。

1. Linux オープンソースOSの代表格。Linuxカーネルは世界中の開発者が参加するバザール型開発で作られており、サーバー、モバイル、スーパーコンピューターなどで幅広く利用されている。
2. Apache HTTP Server 最も普及しているWebサーバーソフトウェア。Apacheソフトウェア財団が中心となり、多数の貢献者によるバザール型開発が行われている。
3. Mozilla Firefox オープンソースのWebブラウザ。Mozilla財団が運営するMozillaプロジェクトによってメンテナンスされており、数多くの開発者が関与している。
4. LibreOffice オープンソースのオフィススイート。フォークされたOpenOffice.orgをベースに、The Document Foundationが中心となってバザール型で開発を進めている。
5. WordPress 人気の高いオープンソースCMSで、コアは限られた数の開発者がリードし、プラグインなどはコミュニティ全体で開発されている。
6. Python 汎用的な高級プログラミング言語。Python Software Foundationが管理するオープンソースプロジェクトで、世界中の開発者が貢献している。
7. Git 分散バージョン管理ツールとして広く利用されている。Linuxカーネル開発で用いられていたものがオープンソース化され、現在はコミュニティが主体となって開発が進められている。

このように、OS、ミドルウェア、アプリケーションなど、さまざまな分野で成功しているオープンソースプロジェクトが存在しています。バザール型開発モデルが機能し、優れた製品が生み出されてきました。

その他のバザール型開発で成功しているオープンソースプロジェクトの例としては、以下のようなものがあげられます。

8. Docker コンテナ仮想化ツール。Docker Inc.が主体となり開発を主導しているが、多数の外部貢献者も参加している。
9. Node.js
   サーバーサイドJavaScriptエンジン。Node.js財団がガバナンスを担い、オープンガバナンスモデルで開発が行われている。
10. React Facebookがオープンソース化したJavaScriptUIライブラリ。Facebookが中心になりつつも、外部からの貢献も積極的に受け入れている。
11. TensorFlow
    Googleが開発したオープンソースの機械学習ライブラリ。Googleが主導しつつ、外部コミュニティからの貢献も受け入れている。
12. MySQL オープンソースのリレーショナルデータベース管理システム。オラクル社の商用版もあるが、コミュニティ版もバザール型で開発が進められている。
13. VLC Media Player マルチメディアプレーヤー。VideoLAN非営利団体が中心となり、世界中のボランティア開発者が参加している。
14. Blender 3Dコンピュータグラフィックスソフトウェア。Blender財団が管理し、プロ有志や熱心な愛好家らが貢献している。

このように、インフラからエンドユーザー向けアプリケーションまで、非常に広範囲の分野でバザール型開発が成功を収めているといえるでしょう。

はい、営利企業においてもバザール型の開発手法を一部取り入れ、成功を収めている製品はいくつか存在します。

1. .NET Core Microsoftのオープンソースのソフトウェアフレームワーク。.NETプラットフォームのクロスプラットフォーム対応版で、内部開発とオープンソース開発を組み合わせている。
2. Visual Studio Code Microsoftの無料型クロスプラットフォームIDEで、オープンソースとして公開されている。コミュニティからの貢献を積極的に受け入れている。
3. Chromium GoogleがオープンソースのWebブラウザエンジンとして開発しているプロジェクト。Google ChromeやMicrosoft Edgeの元となっている。
4. Android Open Source Project (AOSP)
   Google が運営しているオープンソースの Android モバイルオペレーティングシステム。OEMベンダーや開発者コミュニティも関与している。
5. Eclipse IDE
   オープンソースの統合開発環境。Eclipse財団が中心となり、企業や個人開発者が協力して開発を進めている。
6. LibreOffice オープンソースのオフィススイート。元々StarOfficeに由来するが、フォークされてオープン化された製品。
7. MySQL オラクルが運営するオープンソースのリレーショナルデータベース管理システム。商用版と並行してコミュニティ版が公開されている。

これらの製品は、コア部分の開発は企業内で行いつつ、一部の機能や拡張性の部分についてはオープンソースコミュニティと連携してバザール型の開発を取り入れているケースが多いです。完全にオープンというわけではありませんが、メリットを上手く取り入れています。