OSS

OSS を収益化して持続的開発を実現する方法をまとめた

OSS は無償で公開されていても、当然ながらその開発には必ず誰かの時間が費やされています。

バグを修正するのも機能を追加するのも大抵はボランティアで、ほとんどの開発者は兼業で OSS に関わっているはずです。

もしも開発者がフルタイムで OSS に関わることができれば、OSS をより早く成長させられ、開発者としても 楽しい 時間が増やせるはずです。でもそのためには、OSS 活動そのものから収益を生み出すことが必要です。

最近は OSS のサステナビリティ に興味があって、いろいろと調べた+貢献できそうなものを作ってみたので、簡単な Pros/Cons と共にまとめてみました。

オンライン寄付

寄付は一番身近な収益化の方法だと思います。

Open CollectivePatreon などが代表的です。

Open Collective は OSS プロジェクトに対して寄付を募ることができます。プロジェクトは寄付金額に応じたリワードを設定しますが、よくあるのは README.md にロゴや名前を表示するというリワードですね。
Patreon は個人がパトロンを募ることができます。これは厳密には OSS への寄付ではないですが、Vue の Evan や Babel の Henry などを見るに、事実上 OSS への寄付と見ても問題ないと思います。

Pros

GitHub で多くのスターを獲得するような人気のプロジェクトでは大きな寄付額が期待できそうです。Webpack は Open Collective で年間約 33 万ドルもの寄付を集めています。

Cons

大口の支援者が寄付を打ち切ることの恐れは常につきまといそうです。

また、OSS の技術的価値だけでなく、そのプロジェクトの抱えているユーザーコミュニティであったり話題性などの尺度で恣意的に評価されるので、その評価を上げるのが苦手なプロジェクトもなかにはあると思います。

デュアルライセンス

その OSS の利用対象がプロプライエタリなものか OSS かで異なるライセンスを適用する方法です。

License Zero などを使うと簡単にデュアルライセンスにおける非公開ライセンスを管理できます。

企業が私有するソフトウェアの開発に使いたいなら有償の非公開ライセンスを、OSS に使いたいなら無償のライセンスを選択することになります。

Pros

有償ユーザーのボリュームゾーンとなる企業から容易に収益化できそうです。

OSS が 実際に 影響を及ぼした事業に比例して収益化できる点も、開発者は望まないコミュニケーションを減らして開発に集中することができると言えそうです。

Cons

GPL や MIT ライセンスで代替できそうな類似の OSS が存在する場合、独自の価値が強力でないとあえてデュアルライセンスの OSS を選択しないケースは多くありそうです。

エンタープライズサポート

OSS の導入やアップデートなどをエンタープライズ企業向けに有償でサポートする方法です。

Red Hat が代表的だと思いますが、最近だと Serverless もエンタープライズサポートをはじめました。
Tidelift などを使うとある程度気軽にエンタープライズサポートを始めることもできます。

原則として、エンタープライズ企業が開発するプロダクトの基幹を成すような、ある程度大きなサイズの OSS でなければ成立しづらいですが、昔からあるモデルです。

Pros

ビジネスの設計次第では、継続的で高単価な収益が期待できそうです。

Cons

エンタープライズ企業を相手にできるビジネスチームが必要です。

また、契約形態にもよると思いますが、ほかの収益化手段と比べて長期的な製品開発を求められがちなのではと思われます。

SaaS として提供

OSS アプリケーションを公式にホスティングする方法です。

GitLab における gitlab.comや、WordPress における wordpress.com などが代表的です。

必然的に、アプリケーションとして動作する OSS である必要があります。Dev.to のように、最初はクローズドソースでプロダクトをリリースして、ユーザーを十分に獲得できたタイミングで OSS にするという手法もとれます。

Pros

ユーザーを獲得することができれば、投資家などからの巨額の支援も期待できます。

SaaS はひとつのプロダクトなので、有償ユーザーを集めたり広告を出したりなど、収益化の選択肢は完全に自由です。

Cons

OSS の技術的価値とは別に、プロダクト自体が エンドユーザー にとって魅力的である必要があります。

ビジネスの失敗が OSS の失敗にもつながるリスクがあります。

助成金

OSS 支援のための組織からの助成金があります。

Mozilla GrantsGoogle Open Source などのほか、さまざまな財団が支援しています。

組織によって基準も金額もまばら( というか不明なケースが多い... )なので、開発している OSS との相性が見込めるところを探すとよいかも知れません。

Pros

採択された OSS には一線を画した評価が与えられると考えられます。これはコミュニティの成長にも寄与する可能性があります。

Cons

印象論になりますが、採択される難易度はかなり高いのではと思われます。

イシューバウンティ

バウンティとは私が個人的にそう呼んでいるだけですが、総称が分からなかったので便宜上こうします。

OSS プロジェクトそのものの収益化とは異なりますが、OSS への貢献を収益化する仕組みとなります。

BountysourceIssueHunt などが代表的です。

イシューを解決した開発者に対して賞金を与えます。

Pros

自分自身が OSS プロジェクトのオーナーでなくても、イシューを解決することで収益を得られます。

貢献に応じた収益化ができる珍しい手段です。

Cons

自分が貢献したい/できるプロジェクトがイシューバウンティを実施している可能性はまだまだ低く、限定的になりがちです。

組織に所属

Facebook や Google のように自社事業のための要素技術を OSS として公開している場合や、Linux Foundation のように企業が加盟し OSS を支援できる財団があります。企業が OSS のフルタイムコミッターを雇うケースもあります。

これらの企業に所属したり、財団加盟企業に所属して OSS の開発ができます。これも OSS プロジェクトそのものの収益化とは異なりますが、OSS への貢献を収益化します。

Pros

雇用の中で OSS を開発するため安定した収益が得られます。

Cons

自分が貢献したい/できるプロジェクトに関われるかどうか、個人に与えられる裁量などはすべて企業次第です。

"Dev" トークン

これは私がつくったトークン( ≠暗号通貨 )です。

Dev - Tokens for OSS sustainability

今はまだ npm パッケージとしての OSS 限定ではありますが、OSS の開発者に対して毎月無償でトークンを配布することで OSS を収益化します。取引所でトークンを売買すれば換金したり売買益を得ることもできます。OSS 毎のトークンの配布数は、その OSS の月間ダウンロード数などから計算されます。

OSS オーナーへの配布のほか、将来的にはコントリビューターへの配布も行なう計画です。

トークンの詳しい配布ルールなどは devtoken.rocksブログ記事 にまとめてあります。

[追記/2018-8-16]: Dev トークンにいただいた質問に対する回答を ブログ記事 にまとめました。

Pros

収益が OSS のダウンロード数に比例する仕組みなので、開発者は開発に集中できます。

どのようなサイズの OSS でも、それが地味な存在でも、ダウンロードされていれば収益になります。( 将来的にはコントリビューターの貢献度に応じた配布もやりたい )

OSS 自体に何か変更をする必要がなく、他の方法との組み合わせも自由にできます。

Cons

トークン 1 つあたりの価値は取引所で行われている売買により決定されるため、為替のように時期によって価格が変動します。


以上です。

他にも代表的な手法があったら、コメントで教えていただければ追記します。

OSS は無償で提供することが多いため、収益化の話をするのはちょっと抵抗のある人もいるかも知れません。

でも OSS の成長のことを真剣に考えるためには、無視できないトピックであるはずです。

より多くの開発者がフルタイムで OSS に関わることができたら、世界全体の技術的進化のスピードも上がると思われます。

これからの社会のためにも前向きに議論していきたいテーマです。