Smart companies try to commoditize their products’ complements.
complementsの例: 車に対するガソリン、OSに対するハードウェア, プログラミング言語に対する拡張. プログラミング言語を動作させるためのハードウェア. プログラミング言語を学ぶための教材.
demand for a product increases when the price of its complements decreases.
productに対するcomplementの価格が下がりコモディティ化するとproductの需要が増える
OSSについても同じことでIBMはコンサルティングカンパニーなのになぜフルタイムでOSSに貢献する開発者を雇っているかというとコンサルティング時に提案するために有力なOSSを開発レベルでサポートすることでコンサルティングの需要が高まるから
他者が作っているProductをポートフォリオに組み込むことが出来るというのは自社でリスクを負わずに間接的に開発に関わることが出来るのでソフトウェア自体がProductではないコンサルティング業では理にかなっていそう
Babelがフルタイム開発者を雇うためにスポンサードしてるが資金が尽きそうということで困っていたが、どのOSSでも同じ問題はありそう
OSS自体が製品になるとOSS自体には理念上payはないため、遅かれ早かれ資金は尽きる
OSS自体を売るのではなくそのコンサルティング自体を製品にするなどの戦略が必要
そういう意味ではBabelのような他のベースとなる基礎的なOSSをコンサルティングとして使うのは難しそう
コンサルティングが必要なほどの複雑性になり
LinuxはFOSSだがフルタイム開発のために非営利団体が存在しGoogleなどが資金提供している
AWSがaws labsなどからOSSコミュニティへの貢献を行っているのはawsというproduct自体へのcomplementとしてそれらのOSSを使うためにAWSがなくてはならないという状況にするため
何が自分たちのproductで何がcomplementなのかというのを意識する必要がある
productを売るつもりがcomplementを作っていただけという状況になると持続可能性的に厳しい
Googleの製品群がadを売るためのデータを集めるためのプラットフォームだというように
各種SNSのproductはターゲッティング広告で、個人の活動データ自体がproductになっているように
趣味でOSSを作るのはOSSはcomplementsで自分自身がportableなproductになるように
単に「それが僕には楽しかったから」というのは真実ではあるけどOSS開発を他人に勧めたい理由でもある
productにしてもいいが徐々にcomplementとなるように別の持続可能なproductを作る必要がある
product -> complementの階層構造を作る
「エコシステム」と普段自分が言う時の構造に近いかもしれない
product -> complementの依存構造が多層的でその依存構造がヴァイタルで持続可能性のある依存関係
単純に良いproductを作れば売れるという考えはナイーブで偶然性の中では必ずしも持続可能性はないので持続可能な構造にする必要がある