オープンソースソフトウエアを支えるビジネスモデル

「オープンソースソフトウエアがゾンビ化する事情」の記事が参考になったのでメモ。
以下、主張のないラフなメモ書き。

【元ネタ】
ゾンビOSSが危ない - ［2］オープンソースソフトウエアがゾンビ化する事情：ITpro

ゾンビOSSが危ない - ［1］オープンソースソフトウエアにも寿命がある：ITpro

ゾンビOSSが危ない - ［3］オープンソースソフトウエアの「ゾンビ化」を避ける心得：ITpro

(引用開始)
1)リスク高：新機能追求型

　既存の商用ソフトにはない新機能の実現を目指して開発された「新機能追求型」のOSSは、ゾンビ化するリスクが最も高い。
　ゾンビ化するパターンは大きく三つある。（1）新機能が他のソフトでも実現可能になることで、そのOSSの存在意義が無くなるパターン、（2）新機能を実現するOSSが乱立した結果、競争に敗北するパターン、（3）新機能を追求するあまり旧バージョンのサポートがおろそかになるパターンである。
(引用終了)

(引用開始)
2)リスク並：サポートビジネス型

　サポートビジネス型OSSとは、ディストリビューションや有償サポートを販売するベンダーが開発を支えているOSSのことだ。OSS事情に詳しいNRIの高橋雅人OSS推進グループマネージャーは、このようなOSSを「商用OSS」と表現する。
(引用終了)

(引用開始)
3)リスク並：マーケティング型

　マーケティング型のOSSとは、ベンチャー企業が販売・サポート収入を目的に開発したソフトを、世間にアピールするためにオープンソース化したものである。販売・サポート収入を前提にしているので、ゾンビ化リスクはサポートビジネス型と同程度である。
(引用終了)
(引用開始)
4)リスク低：呉越同舟型

　呉越同舟型OSSとは、ライバル関係にある企業が「呉越同舟」で協調して開発するソフトを指す。SDN（ソフトウエア・デファインド・ネットワーク）ツール「OpenDaylight」やIaaS構築ソフトOpenStack、Dockerコンテナの運用管理ツール「Kubernetes」など、先端的なOSSの開発が大手ベンダーによる呉越同舟で進むケースが増えている（図5）。
(引用終了)

(引用開始)
5)リスク高：特殊事情型

　きわめて特殊な事情でOSSが生まれることもある。その一例は、米InfiniDBが開発したデータウエアハウス（DWH）ソフト「InfiniDB」だ。
(引用終了)

【1】現代のソフトウェア開発では、オープンソースを上手く使ってスクラッチ開発する場合は多い。
特に、フレームワークなどの開発基盤、DBやWebサーバなどのミドルウェア、サーバーやインフラの監視ツールなどが思いつく。

個人的には、オープンソースをベースとした開発は好きだ。
2000年代前半までは、ベンダー主導のフレームワークやパッケージ製品で開発する方法が多かったが、開発者としては苦痛で仕方なかった。
俺様フレームワークに付き合わされるのは嫌だったし、すぐに技術が陳腐化するのに、パッチやバージョンアップの対応が遅かったから。
また、オープンソースに慣れている方が、そのスキルは他の職場でも通用するし、GitHubのように最新の開発プロセスも身につく。

しかし、オープンソースにも落とし穴はある。
コミッタとコミュニティが活発に活動しなければ、環境に応じてバージョンアップして、時代に追随できないリスクがある。
オープンソースのツールのコミッタは、普通は無償で趣味でやっているだろうから、その仕事量が増えてくると、多分持ちこたえられなくなる。

【2】上記の記事で興味深いのは「新機能追求型」と「サポートビジネス型」だ。

【2-1】「新機能追求型」のオープンソースで破綻するケースは確かにある。

一番怖いのは、後方互換性を考慮しないバージョンアップを行うオープンソースだろうと思う。
安易にバージョンアップしてしまうと、OSやブラウザごとに乱立してしまい、逆に保守コストが上がってしまう。
特に、新機能の追加を優先した場合に起きやすいと思う。

【2-2】オープンソースが開発者にとっても経営者にとっても、安定したビジネスモデルになるのは、「サポートビジネス型」だろう。
ソースを公開するのは著作権放棄と思われるかもしれない。
でも、逆に、開発者やユーザからたくさんのフィードバックをもらえることで、機能や品質の改善につながる。
また、ソースの公開によって、知名度が上がる利点もあるだろう。
その方向性を突き進めると「マーケティング型」になるだろう。

「サポートビジネス型」で重要な点は、オープンソースのツールを中心としたエコシステムを作り出すことだろう。

開発チーム、熱心な利用ユーザ、バグ修正のパッチを送ってくれる熱心な開発者の三者が一つのコミュニティを形成できれば、製品の方向性を事前に示すこともでき、それによってユーザも安心感を持てる。
定期的なバージョンアップをロードマップとして事前に告知できれば、セキュリティパッチやメジャーバージョンアップを区別してリリースすることもできる。

オープンソースを長続きさせるには、開発よりも保守が重要。
保守し続けたい、と思わせるパワーが必要。
そのためには、開発チーム・利用ユーザと開発者のコミュニティとエコシステムが必要だろうと思う。

この辺りのオープンソースのビジネスモデルも整理して、その特徴や方向性、焦点を明確にしてみたい。