# オープンソースソフトウェア開発 Navigation: [[index]] | [[concepts/_index]] ## 定義 オープンソースソフトウェア開発とは、単にソースコードを公開する行為ではなく、コードを中心に据えた組織運営の様式・業界構造への働きかけ・価値提案の三つが絡み合う営みである。[[Open Networking Foundation]](ONF)の事例では、ベンダー中立で商用製品に忠誠を持たないエンジニアリングチームが、ネットワーク業界を垂直統合型から水平統合型へ変容させるという破壊的変革のミッションを、オープンソースソフトウェアを主要な手段として遂行した。この過程は、少数の設計者が孤立して組み立てる「伽藍」と、多数の参加者が構成要素を自由に再発明・フォークする「バザール」(Eric Raymondの対比)のどちらか一方には収まらず、アーキテクチャ原則を共有しつつ個々の構成要素の自由な進化を許すハイブリッドとして現れる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 3 オープンソースソフトウェア]] §3.1, §3.2) オープンソースソフトウェアの価値提案は、サポート販売やクラウドサービス化といった直接的な収益化モデルだけでは捉えきれない。実装の内部構造に触れ、可能なら実際にコードを動かす経験は、スライド資料の説明では得られない複雑なシステムへの概念的に深い理解を与える。この「教育的価値」は定量化が難しいが、そのソフトウェアを書いた・投資した動機(利他的とは限らず、ビジネス上・国益上の理由を伴うことが多い)とは独立に成立する。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 3 オープンソースソフトウェア]] §3.3, §3.5) ## 横断的知見 - **「表面的な公開」と「実質的な開放性」の乖離は、ネットワーキングと大規模言語モデルの双方で同じ形の問題として現れる**: 本概念のソース(ch.3)は、オープンソースの真の価値がコードの列挙ではなく内部構造への到達可能性にあると論じ、「PowerPointのスライドに描かれたシステムを見ていても上っ面しか理解できない」と述べる。[[オープンLLM開発]]の[[@2025__arXiv__OLMo 3]]は、この同じ問題をモデル重みの公開可否という軸で捉え直し、「最終重みのみの公開」(オープンウェイト)と、事前学習データ・中間チェックポイント・訓練ログまで含めた「モデルフロー」の公開を明確に区別する。分野が異なっても、形式的な公開(ソースコードの存在、重みファイルの配布)だけでは他者による深い理解や再構築を保証できず、構築過程そのものへのアクセスが要る、という論点は共通する。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 3 オープンソースソフトウェア]] §3.3, [[@2025__arXiv__OLMo 3]]) - **ONF単体の組織パターン(伽藍とバザールのハイブリッド)を論じた既存の観察は、ハードウェアとソフトウェアで役割分担する2組織構成という、より広い設計として捉え直せる**: 既出の横断的知見・定義は、[[Open Networking Foundation]] (ONF) がベンダー中立なエンジニアリングチームを擁し、アーキテクチャ原則を共有しつつ個々の構成要素の自由な進化を許すハイブリッドな組織パターンでSDNのオープンソース化を進めたと記す。[[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Preface]] はこれを補い、ONF が担うのはソフトウェアコンポーネントの実装であり、コモディティハードウェア(ベアメタルスイッチなど)の仕様策定・認証は [[Open Compute Project]] (OCP) という別組織が担うという役割分担を示す。すなわち、SDNのオープンソース化戦略は単一組織内部の「伽藍とバザールのハイブリッド」だけでなく、ハードウェア標準化(OCP)とソフトウェア実装(ONF)を別組織に分業させるという、組織間の役割分担レベルの設計判断も伴っていたことが分かる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 3 オープンソースソフトウェア]] §3.1, §3.2, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Preface]]) - **ONFの抽象的な「伽藍とバザールのハイブリッド」パターンは、SONiC Foundationの運営機構において段階的ゲート構造として具体化される**: 既出の知見は、ONFがアーキテクチャ原則を共有しつつ個々の構成要素の自由な進化を許すハイブリッドな組織パターンでSDNのオープンソース化を進めたと抽象的に記す。[[SONiC Foundation]]の運営プロセス(ch.3)はこれを具体的な機構として補強する: 技術トピックごとのワーキンググループでの自由な議論・精査(バザール的段階)と、デザイン文書(HLD)のレビュー・技術運営委員会(TSC)による監督という集中レビュー(伽藍的段階)が、新機能のアップストリームという単一のプロセス内で明確に分離・直列接続されている(ワーキンググループでの検討→HLD作成・レビュー→ソースコードレビュー→マージ)。抽象的な「ハイブリッド」という特徴づけが、実際の組織では「どの段階でバザール的自由度を許し、どの段階で伽藍的な集中審査を課すか」という設計判断として具体化されることが分かる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 3 オープンソースソフトウェア]] §3.1, §3.2, [[@2025__Gihyo__実践SONiC入門 - Chapter 3 コミュニティ運営と開発プロセス]] §3.1, §3.3.1) - **OCP/ONFの静的な役割分担(同時期の並存的分業)に対し、SONiC Foundationの沿革は同一プロジェクトが時間軸で母体組織を乗り換える動的な進化パターンを示す**: 既出の知見はOCPとONFがハードウェア標準化とソフトウェア実装をそれぞれ担う並存的な分業関係にあると記す。SONiC Foundationの事例(ch.3)はこれとは異なる時間軸のパターンを追加する: SONiCはもともと2016年にMicrosoftによってOCP(ハードウェア標準化団体)へのコントリビューションとして始まり、SAIとともにOCPプロジェクトとして活動した後、2022年にLinux Foundation傘下の専用ガバナンス組織(SONiC Foundation)として独立した。すなわち、ハードウェア標準化団体の傘下でソフトウェアプロジェクトとして始まり、規模拡大に伴って専用のソフトウェアガバナンス組織へ分離独立するという時間的進化も、OCP/ONF型の分業パターンと並ぶもう一つの組織形成経路として観察できる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Preface]], [[@2025__Gihyo__実践SONiC入門 - Chapter 3 コミュニティ運営と開発プロセス]] §3.1.1) - **「ベンダーによる変更の小出し戦略」という抽象的な懸念は、SONiCの商用版とアップストリームの関係において『先行実装後の選別的還元』という具体的な機構として現れる**: 本概念のソース(ch.3、LambdaNote書)は、オープンソースの「武器化」に関連してベンダーが変更を小出しにする戦略への警戒を示唆する(既出の未解決の問い参照)。[[@2025__Gihyo__実践SONiC入門 - Chapter 4 商用版SONiCと有償サポート]]はこの構図をSONiCの商用版-コミュニティ版関係において具体化する: 商用版が先行してサポートする機能には、将来コミュニティ版へアップストリームされる予定のものと、完全に独自機能でアップストリーム予定のないものの2種類があり、著者は前者について「必ずしもベンダーが差別化のために遅れさせているわけではなく」アップストリームに要する時間・労力や需要の見えにくさが要因になりうると留保をつける。すなわち、抽象的な「小出し戦略」への懸念は、実際のプロジェクトでは「差別化目的の意図的な出し惜しみ」と「アップストリームコストゆえの合理的な遅延」が外形上区別しにくい形で混在しており、ユーザーがメーリングリストで需要を可視化することがこの曖昧さに対する数少ない能動的な打ち手として提示されている。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 3 オープンソースソフトウェア]] §3.3, [[@2025__Gihyo__実践SONiC入門 - Chapter 4 商用版SONiCと有償サポート]] ch.4 §4.1.2, §4.2) - **OSSの直接的収益化モデル(サポート販売)を「単体では価値を捉えきれない弱い手段」とする既存の観察は、大規模OSSの本番導入という利用者側の視点から見ると『構造的に不可欠な調達行為』として裏返る**: 本概念のソース(ch.3、LambdaNote書)は、サポート販売やクラウドサービス化といった直接的収益化モデルだけではOSSの価値提案を捉えきれないと論じ、教育的価値という別の(定量化しづらい)価値軸を対置する。[[@2025__Gihyo__実践SONiC入門 - Chapter 4 商用版SONiCと有償サポート]]は同じ「サポート販売」を供給側でなく需要側(導入企業)の視点から描く: 大規模なOSSを商用環境に導入する際、Microsoft・Alibabaのような常に新規開発を続ける大規模組織であってもすべてのサブモジュールに精通した開発チームを自前で維持するのは非常に困難であり、技術支援企業と共同で不具合修正・新規機能開発を継続することが一般的だと述べる。ch.4はこの技術支援を「商用版SONiCの提供」「開発支援」「コミュニティ連携」「導入支援や導入後の技術サポート」の4種に分類し、体制・予算・方向性に応じた組み合わせを推奨する。両ソースを重ねると、サポート販売は供給側から見れば教育的価値と比べて「弱い」収益化モデルの一つに過ぎない一方、需要側(大規模組織を含む導入企業)から見ればサブモジュール横断の専門性を自前で維持できないという構造的制約への対応として、購買が事実上不可欠になっている非対称性が見える。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 3 オープンソースソフトウェア]] §3.3, §3.5, [[@2025__Gihyo__実践SONiC入門 - Chapter 4 商用版SONiCと有償サポート]] ch.4 §4.5) - **ch.3が抽象的に主張する「実際にコードを動かす経験」という教育的価値は、Appendix 1のソースコードビルド手順によって具体的な到達可能性として裏づけられる**: 本概念のソース(ch.3)は、実装の内部構造に触れ「可能なら実際にコードを動かす経験」がスライド資料の説明では得られない深い理解を与えると論じるが、その「可能なら」が何を要求するかは述べない。[[@2025__Gihyo__実践SONiC入門 - Appendix 1 ソースコードからのビルド]]は、この条件を満たすための具体的な手段を提供する: sonic-buildimageレポジトリをクローンし、README.mdの手順(GNU make利用)に従うことで、誰でも実際に稼働するSONiCイメージ(sonic-$(PLATFORM).bin)をソースコードから再現できる。すなわち、ch.3の言う「教育的価値」は単にソースコードが公開されていることではなく、そのソースコードから実行可能な成果物を独立に再構築できる手順とツールチェーンが公開されていることに支えられており、Appendix 1のビルド手順はSONiCというプロジェクトにおけるこの条件の具体的な充足例だと位置づけられる。ただし、Appendix 1自体は「検証可能性」や「教育的価値」という語を用いておらず、本概念のこの観察はch.3の抽象的主張とAppendix 1の具体的手順を突き合わせて得られたものである。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 3 オープンソースソフトウェア]] §3.3, [[@2025__Gihyo__実践SONiC入門 - Appendix 1 ソースコードからのビルド]]) ## 未解決の問い - 「教育的価値」を定量化する方法はあるか。ch.3(LambdaNote書)の著者自身、投資対効果の計算方法が「皆目見当がつかない」と述べている。 - ONFの「伽藍とバザールのハイブリッド」という組織パターンは、非営利かつベンダー中立という ONF 固有の構造に依存するのか、それとも営利企業が主導する OSS コンソーシアムでも再現可能か。SONiC Foundationのようにベンダー・ユーザー企業混在の理事会を持つ組織でも同型のハイブリッドが成立している点は、再現可能性を支持する事例といえるか。 - オープンソースの「武器化」(ベンダーによる変更の小出し戦略への対抗)は、ONF のようなベンダー中立組織が存在しない領域ではどのような代替手段で実現されているか。 - OCP と ONF のハードウェア/ソフトウェア分業は、SDN 固有の事情(ハードウェアのコモディティ化とソフトウェアのクラウド化という技術的分離、Preface が述べる本書のテーマそのもの)に強く依存した組織設計なのか、それとも他分野のオープンソース化(例えば[[オープンLLM開発]]におけるハードウェア標準化団体の不在)にも一般化できる分業パターンなのか。 - SONiC Foundationが2023年から採用した「ワーキンググループでの事前精査→コミュニティ全体レビュー」という2段階レビュー運用は、アップストリーム提案の急増に対するスケーリング上の適応(事後的な設計変更)である。ONFやOCPなど他のネットワーキング系OSSガバナンス組織にも、規模拡大に伴う同種のレビュー段階追加は観察されるか。 - 商用版が「アップストリーム待ちの汎用機能」と「アップストリーム予定のない独自機能」のどちらに当たるかを、ユーザーが導入前に外形的に判別する手段はあるか。ch.4はメーリングリストでの需要表明を能動的な打ち手として挙げるが、判別基準そのものは示されていない。 - サポート調達の4分類(商用版提供・開発支援・コミュニティ連携・導入支援)は、SONiC・ネットワーキング以外の大規模OSS(例: Kubernetesディストリビューション、PostgreSQL)にも一般化できる分類か。 - Appendix 1のビルド手順が提供する「実行可能な成果物の独立再構築」は、ch.3が定量化困難とする「教育的価値」の必要条件にすぎないのか、それとも十分条件に近づくのか。ビルドが再現できても、生成されたバイナリを実際に動かし挙動を観察・改変する経験(教育的価値の本体)まで到達するには、別の障壁(実機・仮想環境の用意等)が残る可能性がある。 ## 関連 - ソース: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 3 オープンソースソフトウェア]] / [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Preface]] / [[@2025__Gihyo__実践SONiC入門 - Chapter 3 コミュニティ運営と開発プロセス]] / [[@2025__Gihyo__実践SONiC入門 - Chapter 4 商用版SONiCと有償サポート]] / [[@2025__Gihyo__実践SONiC入門 - Appendix 1 ソースコードからのビルド]] - 概念: [[反復可能性]] / [[技術的負債]] / [[オープンLLM開発]] / [[ヘルメティックビルド]] - 実体: [[Open Networking Foundation]] / [[Open Compute Project]] / [[Aether]] / [[Linux Foundation]] / [[SONiC Foundation]] / [[SONiC]] ## 出典 - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 3 オープンソースソフトウェア]](§3.1〜§3.3, §3.5: ONFの組織構造・伽藍とバザールのハイブリッド・教育的価値・隠れたコスト) - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Preface. https://sdn.systemsapproach.org/preface.html - 海老澤健太郎, 『実践SONiC入門』, 技術評論社, 2025, 第3章 §3.1, §3.3.1(SONiC Foundationの運営機構・アップストリームプロセス)、第4章 §4.1.2, §4.2, §4.5(商用版とアップストリームの関係・技術支援の調達)、Appendix 1(ソースコードからのビルド手順)