第42回 オープンソース財政支援ガイド ~ 後編 ~

こんにちは、オープンソースコンサルタントの内です。

前回より、「オープンソースプロジェクトを財政的に支援するガイド」をシリーズでお届けしています。

第41回 オープンソース財政支援ガイド ~ 前編 ~

今回は、その続き、「後編」をご紹介したいと思います。

■プロジェクトで働くために企業に雇用される

オープンソースに関わる仕事をするために、時に企業は個人を雇用することがあります。

あなたが関わりたいオープンソースプロジェクトを使用する企業を探しましょう。

これは、分割配置の考えでもあります。
例えば、50%は会社の仕事のためになり、50%はオープンソースの仕事になる、ということ。

その他に、新規プロジェクトの構想があるなら、あなたが作ろうとしているものに興味を持ちそうな会社を探しましょう。

良い点:

・リソースを持っている人達に入り込むことができる。

・企業ニーズにうまく沿うことができる。

・安定収入

悪い点:

・彼らを消耗する、企業の利益に貢献しない人。

・プロジェクトが既に有名で利用されている必要がある。

・ガバナンスの問題。

企業がプロジェクトに不当な影響を与える可能性もある。

・プロジェクトの原動力やバランスに影響を与える可能性がある。

プロジェクト事例:

DonaldStufft氏Hewlett-PackardにてPythonパッケージに従事

Rich Hickey氏 Cognitech&Clojure

Aaron Patterson氏 ManageIQチームに参加

■現在の勤め先でプロジェクトを開始する

実は、雇用される側のプロジェクトとしてスタートした、オープンソースプロジェクトも多いのです。

時にプロジェクトが会社よりも大きくなることもありますが、アイデアを形にするには、サイドプロジェクトとして始めるのはすばらしい方法です。

この道を追い求める場合は、自分が会社のオープンソースへの取り組みへのポリシーを理解しているかを確認すべきです。

仕事中にオープンソースに貢献することを奨励する会社もあります。
オープンソースの仕事を会社のプロジェクトとして扱う会社もあります。
始める前から何も仮定する必要はありません。
開始前に、あなたの勤めている会社に確認してみてはいかがでしょう。

良い点:

・給与を心配せず、新しいアイディアを自由にテストできる。

・企業ニーズにうまく沿うことができる。

・新しく実験的なアイデアに向いている。

悪い点:
・サイドプロジェクトとして行う必要がある。または仕事中にプロジェクトの仕事に従事することの承認を得る必要がある。

・会社からの不当な影響を受けるリスクがある。

・後でガバナンスが複雑化するきっかけになってしまう可能性がある。

プロジェクト事例:

Mozilla と Rust言語

Google と Go言語

FacebookとReact

Futuriceのopen source program

■助成金

助成金は、返済を求められない効果絶大な寄付金です。

助成金を提供する側にとってもメリットがあります。
助成金によってあなたとのコネクションができ、インパクトのあるデモンストレーションや仕事の成果、税制上の利点など、他の利益を享受することもあるわけです。

助成金は、企業、ソフトウェア財団、慈善財団や政府など様々な出所があります。

助成金の技術的、法的な視点によって、どこが出所になるかが大きくかわります。

例えば、企業から奨励金をもらったとしても、法的にはコンサルティング契約の対価扱いになる可能性があります。

慈善団体は非営利活動に対してのみ助成金を出せるので、あなた自身が非営利にならなければなりません。

もしくは、一般的に、あなたのスポンサーになってくれる非営利を探すことになるでしょう。

もし、助成金や奨励金、補助金に馴染みがない場合、最善の方法は、過去に受け取ったことがある人に相談してみることかもしれません。

以下にいくつか実際に助成金を受け取った例を挙げます。

良い点:

・寄付同様、販売の対価ではないので、動作保証や納品義務など、条件がほとんどない。

・一定期間、保証された資金がプロジェクトを支援してくれる。

・プロジェクトルームに、一息つく時間や実験的開発をする余裕が生まれる。

悪い点:

・ソフトウェアに関連する補助金の出所がそこまで多くはない。

・助成金は有限なので、助成金がなくなるまでに継続性を模索しなければならない。

プロジェクト事例:

Dat

Andrey Petrov + Stripe Open-Source Retreat and urllib3

Django + Mozilla Open Source Support

■コンサルティングやサービス提供

コンサルティングは、オープンソースワークに資金提供する、柔軟な方法になる可能性があります。

自分の時間をより自由に組み立てることができるようになります。
(例えば、週30時間をコンサルティングにあてて、10時間をオープンソースワークにあてるというかんじ。)

コンサルティングは正社員として雇われるよりも安定しなかったり、福利厚生がなかったりするので、時間に対してより多くの金額を請求できることが多いのが実情です。

この手の仕事を定期的に行うつもりの場合は、合同会社等法人を設立したほうがいいかもしれません。

プロジェクトが有名ならば、プロジェクト自体に関連するコンサルティングサービスも提供できるかもしれません。

例えば、プロジェクトを構築したり、カスタマイズを提供したり、使用方法のトレーニングを提供する、といった手段でクライアントからお金をもらうことができます。

良い点:

・対価を得やすいビジネスモデルである。

悪い点:

・コンサルティングは労働集約的な面がありスケールアウトが難しい。
(例外もありますが)

・ビジネスニーズによっては、プロジェクト自体に関連したコーディングやタスクに集中できない可能性がある。

・使いやすいシンプルなソフトウェアをつくるのと相反する可能性がある。

・プロジェクトに関連したサービスで対価をもらうには、プロジェクトに十分な知名度がなければならない。

プロジェクト事例:

Neighbourhoodie

Baroque Software

OpenSSL

■SaaS

SaaSはSoftware as a Serviceの略で、このモデルの場合、ソースコード自体はオープンソースですが、人々がそのプロジェクトを使いやすくするための付加価値を提供します。

一般的な例では、ホスティングサービスを提供して利用料を受け取る形があります。

良い点:

・オープンなプロジェクトの周辺でコミュニティを形成しやすく、ホスティングのサービスと切り離してお金を生む可能性がある。

・オープンソースプロジェクトはユーザーにフォーカスを当てることができるようになり、企業がプロジェクトを採用しやすい形でニーズが育つ。

・ユーザー数によってスケールが大きくなる可能性がある。

悪い点:

・開発者を採用してプロジェクトを運用するよりも、ホスティングのほうが安くないといけない。

・2層の製品サポートがフリーユーザーに不満をもたらす可能性がある。

プロジェクト事例:

WordPress.com

Moodle

Forge Laravel

Gitlab

Sentry

Travis CI

Ghost

■デュアルライセンス

プロジェクトが2つの異なるライセンスを持つ同一のソースコードを提供することがあります。

1つは商用向けで、もう1つはGPL等のライセンスです。

後者については誰でも無料で使用できるものですが、企業は法的な心の平和のために商用ライセンスを支払うことになります。

良い点:

・対価を得やすいビジネスモデルである。

・成功すればスケールが大きくなる。

悪い点:

・ソフトウェアが自由に手に入るのというのと、相反することになる可能性がある。

・カスタマーのニーズに十分合うぐらいのプロジェクトの大きさが必要。

プロジェクト事例:

MySQL

SQLite

■オープンコア

オープンコアモデルのもとでは、プロジェクトのいくつかは無料ですが、他の機能はプロプライエタリ(保有者が情報を公開しないこと)で、お金を払ったユーザーのみ利用可能となります。

このパターンは、企業ニーズがあるプロジェクトがほとんどです。

良い点:

・対価を得やすいビジネスモデルである。

・成功すればスケールが大きくなる。

悪い点:

・対価を請求できるぐらいの何か特別な機能が必要となる。

・ソフトウェアが自由に手に入るのというのと、相反することになる可能性がある。

・2層の製品サポートがフリーユーザーに不満をもたらす可能性がある。

プロジェクト事例:

Docker

Elastic

Mesosphere

Sidekiq

■基金&コンソーシアム

基金は、寄付を受けたり配布したりすることができる、法的根拠のある機関です。

営利を目的としていないため、中立性を示したり、プロジェクトの財産管理をするのに良い選択肢となります。

良い点:

・中立的な立場。基金がコードを保護し、コミュニティ管理を支援。

・複数の寄贈者間に影響が分配される。

・プロジェクトの正当性を示せる可能性があり、企業は個人に対してよりも基金に対して資金提供しやすくなる。

悪い点:

・本当に大きなプロジェクトのみ対象となる。

・設立が難しい。プロジェクトに制限が出る可能性がある。

・非常に大きなコミュニティ成果と多様なスキルが求められる。
(実体を立ち上げた後に資金集めをする必要あり)

プロジェクト事例:

RubyTogether

Python Software Foundation

Node.js Foundation

■ベンチャーキャピタル

ベンチャーキャピタルは成長性の高いビジネスへ資金提供する形のひとつです。

銀行ローンや他の負債による資金調達と異なり、ベンチャーキャピタルは資金提供の対価として株式(ビジネス所有権の一部)を保有します。

トレードオフとしてローンを組むのとは違い、ビジネスが大失敗しても株主に返済する義務はありません。

しかし、成功した場合は出資者に大金を戻すことが想定されます。

ベンチャーキャピタルは「ハイリスクハイリターン」です。
言ってしまえば、ベンチャーキャピタルは銀行よりもリスクを取りますが、同時に成功した時にはより多額での精算も期待するということ。

ベンチャーキャピタルとのやり取りに馴染みがない場合は、ベンチャーの立ち上げに成功した、自分に類似性のある創業者にリーチするところからスタートするのが最善策です。

良い点:

・立ち上げに関するサポートがビジネスの成長に役立つ可能性がある。

・膨大な資本が利用可能となる。

悪い点:

・ベンチャーキャピタルはイグジットを期待するものである(出資者に倍返しをするなど)。

これが、オープンソースビジネスでは達成するのが構造的に困難であることは歴史が語っている。

・ベンチャーキャピタルによってモチベーションが変わってしまう可能性があり、優先度が惑わされることがある。

プロジェクト事例:

Npm

Confluent

NodeSource

Meteor

長々と書きましたが、実はこのガイドもクリエイティブコモンライセンス CC0 1.0(パブリックドメイン)ライセンスのオープンソースとして、github上に公開されている情報です。

https://github.com/nayafia/lemonade-stand

パブリックドメインのライセンスに基づき、意訳交じりで日本語化したりちょっとアレンジしてご紹介しました。

「アメリカ限定」な情報も交じっており注意が必要ですが、資金集めの方法としてはまとまっている情報だと思います。

これからオープンソースでビジネスをと検討されている方は、ぜひ参考にして頂ければと思います。