オープンソースでお金を稼ぐ方法いろいろ。

オープンソースソフトウェア（以下OSS）が広く使われるようになって久しい。ご存じの通りOSSは無償で入手できるものばかりであるため、多くの人が疑問に思うことがひとつある。それは、「OSS開発者はどこから収入を得ているのか？」ということだ。収入源の実体がよく分からないために「霞を食って生きているのか？」などと揶揄されることもある。実際OSS開発者は「どうやって収入を得るか？」ということについて色々と悩んでいる場合も多かったりするのだが、実はOSSには様々なビジネスモデルも存在する。そんなわけで、今日はOSSを活用して収入を得る様々な方法について詳解しよう。OSS開発者になることに躊躇している人の背中を後押しすることが出来れば幸いである。

プロプラエタリソフトウェアのビジネスモデル

まずはおさらいである。OSSのビジネスモデルについて考える前に、プロプラエタリソフトウェアのビジネスモデル（特にライセンス関連）について復習しよう。プロプラエタリライセンスのビジネスモデルを図式化すると次のようになる。

見ての通りユーザーはお金を払ってライセンスを購入しないとソフトウェアが使えない。使いたいからライセンスを購入する。このように、プロプラエタリライセンスのビジネスモデルはとても分かり易い。誰でも直感的に分かる。そのため、このモデルに慣れ親しんだ人にとって、OSSでビジネスをする、または収益を上げるというのは想像すら出来ないことが多いのである。

どのようなビジネスモデルにも共通することであるが、ユーザーがお金を払うのは何らかの障壁があるときだ。その障壁を解決して「何かが出来ない状況」を打破するために、お金を払うのである。OSSではプロプラエタリソフトウェアのように、単純なライセンスの販売によって収益をあげるのは難しい。だが、たとえライセンス販売が出来ないとしても、そこにユーザーが存在する限り、ビジネスは存在する。ITシステムは年々複雑化の一途を辿るばかりであり、ソフトウェアの利用形態も複雑になるばかりである。そのため、ソフトウェア利用時における「障壁」のタイプも様々に多様化しているのである。すなわち、ソフトウェアに対するニーズが多様化しているのである。その複雑化したニーズを捉えられなければ、如何にプロプラエタリライセンスによる収入があったとしても機会を逸してしまうことになるし、ニーズを的確に捉えればOSSソフトウェアにも大いにチャンスがあるだろう。

というわけで、以下にOSSを用いたビジネスモデルを紹介する。

デュアルライセンスモデル

このモデルが最も分かり易いOSSビジネスモデルだろう。デュアルライセンスとは、OSSライセンスとプロプラエタリライセンスを組み合わせたモデルであり、収益源はライセンスの販売である。「OSS版が無料で使えるのに一体だれがわざわざプロプラエタリライセンスを購入するのか？！」という疑問を持たれる方もいらっしゃるだろう。もちろん、プロプラエタリライセンスでなければいけない理由＝障壁が存在するから、それがライセンスを購入する動機になる。OSSライセンスではなくプロプラエタリライセンスでなければいけない理由とは何か？それには大きく別けて次の2つのものが挙げられる。

ひとつは、一部の機能をあえてOSS版には搭載せず、プロプラエタリライセンスだけで提供するケースである。通常版をOSSライセンスで、高機能版をプロプラエタリライセンス（有償）でというもので、つまり一部のコンポーネントに対するプロプラエタリライセンスを販売するという分かり易いモデルである。このモデルを図に表すと次のようになる。

もうひとつは、Copyleftライセンスに特有の事情であり、「Copyleftライセンスを回避したい」という障壁を解決することで対価を得るものである。ご存じの通り、フリーソフトウェア（自由なソフトウェア）は、ユーザーがどのようにそれを利用しても自由である。ただし、Copyleftライセンスが適用されたOSSソフトウェアを組み込んでソフトウェアを開発した場合、自らのソフトウェアをCopyleftしなければならないという制限がある。（これにより、派生ソフトウェアのユーザーにも自由が保障されるという寸法である。）そこで、プロプラエタリソフトウェアを開発したい人には、OSS版と同等の機能を持ったプロプラエタリ版を販売するというビジネスモデルが成り立つのである。これは、MySQLが伝統的に採用してきたモデルであり、図に表すと次のようになる。

後者のデュアルライセンスモデルとしては、他にQtなどが挙げられる。

サポートサービス

ソフトウェアはライセンス的に利用出来ればそれでいいというわけではない。OSSを利用するにあたっては、ライセンス的な障壁は一切存在しないが、ただ単に利用出来ればいいというものではない。ソフトウェアの利用を続けていると、図らずも「トラブル」に見舞われてしまうことになるからだ。如何なるソフトウェアもバグから完全に逃れることは出来ないので、トラブルは一定の確率で発生してしまうことになる。特にサーバーサイドで利用するソフトウェアは、安定して動作し、問題が発生した場合にも速やかに復旧させなければいけないだろう。

などと言うと「OSSなら自分でデバッグ出来るだろ！」というツッコミが聞こえて来そうである。確かにソースコードの隅から隅まで熟知したエキスパートなら、問題が発生した場合であっても自ら解析してバグの修正を行うことが出来るかも知れないが、ソフトウェアの規模は巨大化の一途を辿る一方であり、ユーザーが自分で問題に対処するのは現実的ではなくなって来ている。そもそもユーザーの本業はOSSのバグを修正することではなく、OSSを用いて自らのビジネスを成功させることである。バグ修正に時間を割くにも限界があるだろう。

そこで、必要とされるのがその道のプロによる有償のサポートサービスである。トラブルが発生して、ソフトウェアが利用出来ない状況が発生したとき、そのトラブルという障壁を迅速に解決するためにお金を払うのである。このモデルを図に表すと次のようになる。

サポートサービスはダウンタイムを短くするために有効な手段であるが、まだ工夫の余地はある。例えば、問題を迅速に見付けるために遠隔監視を行ったり、定期的にヘルスチェックをしたり、運用そのものを請け負ったりというビジネスモデルも考えられるだろう。

コンサルティング

ソフトウェア利用時の障壁は、何もトラブルだけであるとは限らない。ソフトウェアの規模が大きくなると、その分利用方法も難しくなってしまう。そのような場合、ソフトウェアが良好な性能を発揮するには様々なノウハウが必要なのである。特にサーバーサイドのソフトウェアでは、大量のトラフィック／トランザクションを捌くためにパフォーマンスチューニングは必須である。ユーザーがパフォーマンスチューニングなどのノウハウを持ち合わせていない場合、またはチューニングに時間を掛けたくない場合などは、それが障壁になると考えられる。そこで、対価を払って、高度なノウハウを持ったプロ＝コンサルタントに、チューニングなどの作業を任せようということになるわけである。このモデルを図に表すと次のようになる。

実は、ノウハウを提供するという意味では、技術解説書や有料コンテンツ、トレーニングなどもかなり似通ったビジネスモデルであると考えられる。以下は技術書のビジネスモデルを図に表したものであるが、文言が違うだけで形状は同じである。（ただし、コンサルタントはさらに高度な技術レベルを持っているという、質的な違いはある。）

移植作業

最近は移植性の高いソフトウェアを開発するためのノウハウが蓄積されてきたし、JavaやLLなど移植性の高いプラットフォームも幅広く利用されるようになってきたが、それでも限界はあるので他のプラットフォームへの移植が必要なときがある。目的のプラットフォームで利用出来ないということが、障壁となるパターンである。

OSSはソースコードが公開されているので、誰でも移植作業に取り組むことは可能である。従って、自分が使っているプラットフォームでOSSが動作しない場合には、移植すれば良いじゃないかと思ってしまいがちだが、話はそれほど単純ではない。移植作業は一回こっきりのコーディングをすればいいだけでなく、記述したソースコードは継続的にメンテナンスしなければならないからだ。バグが尽きることはないし、ソフトウェアに改良が加えられれば移植時に記述したコードを書き直さなければいけない場合もあるだろう。さらに悪いことに、OSSは一般的に更新のペースがとても早い。

そのソフトウェアを他のプラットフォームに移植し、継続的にメンテナンスするのに最も有効な方法は、そのソフトウェアの開発者に頼むことである。しかし、その開発者にとって「幅広いプラットフォームでソフトウェアが動作する」ということが重要でない場合、移植を依頼しても断られるだろう。ただし、移植作業にお金を払って貰えるとなれば話は違う。もちろん条件次第だろうが、金額が良ければOSSで収益を得たいと考えている開発者が断る理由はない。（むしろそのような依頼は大歓迎であろう。）

移植が必要なケースとしては、組み込み系での利用、Linuxだけで動作するものを商用UNIXで使う、UNIX系OSで動作するものをWindowsへ移植するなどが想定される。

パトロンを見付ける

OSSを活用してビジネスを為しているならば、OSSを応援してもっとビジネスに役立てたいと考えるのは自然なことである。世の中には完璧なソフトウェアというのは存在しないので、自分が活用しているOSSに機能を追加したい、改良したいといった要望は常にあるだろう。そうすると、OSS開発者にとって「ユーザーが要望する機能を優先的に追加するのにお金を払って貰う」というビジネスモデルが成り立つのである。ただし、このモデルで注意が必要なのは、資金提供がなくてもOSSを改良し続けないと、そのソフトウェアそのものの人気が凋落してしまうことだ。あまり「金・金・金！！」とがめつくならず、良いものを作ることを忘れないよう心がけたい。

もう一つ別の「パトロン」の形態として挙げられるのは、OSS開発者を企業が雇用してしまうケースである。最近、これを象徴する出来事があった。Drizzleの開発者3人を、クラウドプラットフォームを提供する企業であるRackspaceが雇用したのである。Drizzleはクラウドで必ず必要な存在になるから、RackspaceはDrizzleを応援したい、だから開発者を好待遇で雇ってしまおう、という寸法である。

広告

些細な収入源になってしまうかも知れないが、OSSを配布するホームページやWeb上のマニュアル、OSSそのものの中で広告を掲載するのも収入源となり得るだろう。プロプラエタリソフトウェアのホームページに広告を掲載するのはかなりウザいが、無料で手に入るOSSのホームページならたぶんセーフだ。特にそのOSSを解説する書籍や、関連する商品であれば広告を掲載していても何ら不自然ではない。最近Web上には広告が溢れかえっているし、そのため人々の広告に対する精神的な抵抗も薄れてきているように思う。アップルがiAdを展開しようとしているのも、広告に対する抵抗感が薄れてきたと判断しているからだろう。頑張ってOSSを開発して広めてトラフィックを稼いで、僅かながらの収入を広告で得よう。主収入源にはなり得ないだろうが、何らかの足しにはなるかも知れない。