はじめに

オープンソース・ソフトウェアにより、起業家や技術者は革新的なソリューションを市場に投入することができます。この記事では、3650 万米ドルで買収された新興企業を設立する際、なぜ私達がオープンソース・ソフトウェアを採用し、どのようにオープンソース・ソフトウェアを使用したのかを説明します。

私達は第一級のビデオ・プロダクション・プラットフォームを世界に提供すべく、StudioNow を設立しました。StudioNow は、Yellow Pages、Citysearch、そして音楽レーベルなどの顧客を対象としたコンテンツをプロデュースするために、ビデオ撮影者と、編集者、グラフィック・アーティスト、声優、その他のビデオ制作に関わる人々を結び付けます。StudioNow の Web サイトと、クラウド・ベースのデリバリーおよびトランスコード・プラットフォームを通じ、大規模なビデオの制作が実現され、個々のビデオのコストを下げることができます。

StudioNow が設立された当初、私と同僚達に突き付けられた課題として、どんな技術を使用するのかを決定すること、新しい一連のスキルを身に付けると同時にスキルを高めていくにはどのような方法が最善であるかを判断すること、スケーリングの難題に対応すること、十分な情報に基づいてアーキテクチャー上の決定を下すことなどがありました。私達はこの経験をとおして、これから説明する技術を使用することがビジネスを構築する上で非常にメリットがあるということを学びました。皆さんにとっての結果は異なるかもしれませんが、皆さんのプロジェクトにオープンソースを使用することを検討しているのであれば、以下の推奨事項に従うことをお勧めします。

• コミュニティーの強力さと深さを基準に技術を選択する
• 採用対象のソフトウェアに関係するコミュニティーに参加する
• スケーリングのためにクラウドの使用を検討する (インフラストラクチャーとしてクラウドを導入することに関係するオープンソース (厳密にはオープンソースではないかもしれませんが) は、数多くあります)
• GPL (General Public License) を避ける

上に戻る

プラットフォームを選択する: Ruby それとも Python？

新しい技術スタックをベースにしたソリューションの構築は困難な作業となりますが、その新しい技術を基軸とした会社を立ち上げることは、それとはまったくレベルの異なる作業となります。私達は初期の戦略的決定事項として、どのプラットフォームを採用するかを選択する必要がありました。選択を誤った場合には、成功するはずのものが失敗に終わる恐れがありました。もし選択を誤り、選択した技術が非常に難解なものであったなら、StudioNow が買収されることはなかったかもしれません。また、コミュニティーが貧弱であったり、コミュニティー自体が存在していなかったりした場合には、私達は短時間で学習することができなかったかもしれません。ではどのプラットフォームを選択すれば、最初からより多くのコードが生成され、基礎となる部分を作成する代わりにコアとなる機能を作成することに専念できるのでしょうか？

私達はそれまで、主にエンタープライズ・ソフトウェア (つまり Microsoft .NET と C#、また Oracle と Java 技術など) を経験してきたため、それらとは異なる何かを選択する必要があることは明らかでした。ライセンス・フィーやライセンス準拠の管理に費用を使いたいと思う人はいません。そのため、最終的には、Ruby on Rails による Ruby、あるいは Django による Python のいずれかを選ぶという判断になりました。この 2 つの選択肢に絞り込まれた理由は、Web アプリケーションを作成するためのオープンソースの選択肢として、この 2 つが広く一般的に認められているためです。

2006年の初めに、私が裏で StudioNow を設立するための準備に勤しんでいたころ、StudioNow の共同設立者で CTO となった Adam Solesby は 2 つのプラットフォームを評価し、どちらを選択するかを決断しようとしていました。彼は 2 つの重要な要素を理由に、Django を選択しました。第一に、とにかく Python 言語は芸術的な美しさの点で、より満足が行くもののように思えたのです。しかしもっと重要な点として、Python と Django はドキュメントが豊富でコミュニティーが強力でした。さまざまな事項を明確に説明したドキュメントは読みやすく、例を探すのも簡単でした。この点は、採用する技術を決定する上で、極めて重要な要素でした。オンライン書籍の『Dive into Python』、Freenode の #django IRC (Internet Relay Chat) チャネル、そして Python と Django のドキュメントを利用することで (「参考文献」を参照)、Python と Django を習得するのは容易な作業となりました。

上に戻る

コミュニティーの力

それぞれのオープンソース・プロジェクトには、明示的な (あるいは暗黙的に理解された) 一連のルールがあります。これは、そのプロジェクトを取り巻くコミュニティーにもある程度言えることです。 オープンソースを採用して成功するためには、以下の点を考慮することが重要です。

• コミュニティーに対しては貢献として何かを返す態度で接する。
• コミュニティーの人々がボランティアであり、皆さんに対して何らかの義務があるわけではないことを理解する。
• 自分自身で答えを見つけようと努力する。何かが明確ではなく、その答えを見つけるために長い時間がかかる場合には、ブログ記事、ドキュメント、FAQ 作成などの形で自分自身の知識をコミュニティーへの貢献として返し、次の人が同じように答えを見つけようとする場合に作業の時間を短縮できるようにします。
• 一匹オオカミであろうとせず、そのコミュニティーのエチケットを早い段階で判断し、そのコミュニティーに同化しようと心がける。そのコミュニティーの主なコミュニケーション手段は E メール・リストでしょうか、それとも IRC チャネルでしょうか。その両方かもしれず、それぞれ雰囲気が異なるかもしれません。
• 積極的であること。

上に戻る

スケーリングの方法を学ぶ

StudioNow が設立されて間もない頃、私達はビデオのトランスコードについて、あまりよく理解していませんでした。その当時、私達はまだ学習中であり、ビデオを Sorenson FLV フォーマットにエクスポートして私達の Web サイトで再生し、チェックを行っていました。私達のプロジェクトにおけるビデオの制作コストを引き下げ、編集者自身が作業を行うよりも私達のプロジェクトを利用した方がコストがかからず採用する価値があると編集者に確信させるには、編集者が嫌う非創造的な繰り返し作業の負担を私達が負わざるを得ませんでした。私達のプロジェクトのセールスポイントは、顧客がターゲットのフォーマットを気にする必要がない点でした。

当初はこのモデルで続けることができましたが、やがて作業量が膨大になりました。私達はワークステーションと専従のスタッフを大量に動員して手動でエクスポートを行いました。また、プロセスを半自動化するために即興で作られたスクリプトもありました。この半自動化の対象となったプロセスは、編集者がアップロードしたそのままの素材をダウンロードしてトランスコードを行い、それを再度クライアントのプロジェクト・ページにアップロードしたものを顧客がチェックするというプロセスです。

このプロセスではスケーリングが不可能なことは最初から明白であり、私達は可能な限り多くの資金を確保しつつ、この問題を解決する必要がありました。次回の資金調達ができるかどうかは常に不確定であり、私達は無駄に資金を使いたくはありませんでした。

クラウドへの移行

AWS (Amazon Web Services) がまだ比較的新しかった 2006年の中頃、私達は同じ場所に置かれた比較的古い 2 台のサーバーで、サイト全体をホスト (Web サイトとビデオ・ファイルのホスティング) しているような状態でした。このため、AWS が登場した当初、安価で無制限のストレージを利用でき、規模が拡大するのにあわせてコストも増大していく Amazon S3 (Amazon Simple Storage Service) に魅力を感じていました。私達はトランスコードのスケーリングが必要なことを理解していましたが、Amazon S3 を利用する最も重要なポイントは、私達の Web サーバー上にある、あまり余裕のないハードディスクが一杯になることを心配せずにすむことでした。

私達は、社内にあるトランスコード・ソリューションを Amazon S3 に接続し、Amazon S3 上にトランスコード結果を格納し、私達の Web サイトへの API 呼び出しを利用して格納場所を記録することに決めました。このソリューションにより、トランスコードのスケーリングの問題への対応方法を考えるための時間を少し得ることができました。

私は独自の Python インターフェースを作成することで、Amazon S3 API とインターフェースを取るための作業を開始しました。しかし私はすぐに、Mitch Garnaat による boto プロジェクト (「参考文献」を参照) の存在に気付きました。Mitch が直接支援してくれたおかげで、私達の生産性は大幅に向上しました。このライブラリー自体は StudioNow のために必要な作業と時間を減らすために大いに役立ちましたが、それ以外にも boto ユーザーと開発者のコミュニティーは、技術ソリューションを設計するための新しい形式を理解する上で、大きな助けになりました。ある意味で、boto プロジェクトへの参加は、オープンソース・ソフトウェアへの参加と言うよりも、むしろオープン・アーキテクチャーへの参加でした。

boto プロジェクトでの協力の経験のおかげで、社内で 1 つのコーデックを使用してビデオを作成するという限定的な手法から、Amazon EC2 (Amazon Elastic Compute Cloud) を使用した、大規模なスケーリングが可能なエンコーディング・プラットフォームによる手法へと無事に転換することができました。このプラットフォームは今や、多様な機器やプラットフォームを対象としたさまざまなサイズの文字どおり何万本ものビデオ、そしてコーデックを、1 本のビデオを 1 度エンコードする場合と同じ時間でトランスコードすることができます。

振り返ってみると、私達は (当社の COO の助言により) Java ベースでクローズドソースのソリューションを使うことを検討していました。そのソリューションは実績のある技術であり、その技術によって上記と同じトランスコード・サービスがポストプロダクション・ハウスに提供されていました。COO の助言は賢明であると同時に保守的なものでしたが、ハードウェアの購入、データ・センター・スペースの構築またはレンタル、ソフトウェアのライセンスのために高額の設備投資が必要であり、しかもハードウェアを管理するためのスタッフを追加で雇用する必要がありました。しかしそのソリューションは、少なくとも短期間であればスケーリングが可能なソリューションでした。

このブラックボックスのソリューションに設備投資する前に、私達は boto コミュニティーでの経験とクラウドでの「対象を使用した分だけ支払う」という契約から、クラウド・ベースのソリューションを追い求めることに決めました。当時、他の人達が似たようなことをしている例はほとんどありませんでしたが、必要な要素は十分に揃っていました。boto ライブラリーにはオンデマンドでノードを起動するインターフェースがありました。Amazon にはコンピューティング・リソースがあり、私達にとって必要なことをする上で、リソースの価格は適切でした (私達に必要なリソースは、常時実行されていながら大半の時間はアイドル状態になっているマシンではなく、オンデマンドで水平スケーリングされるコンピューティング・リソースでした)。Mitch はさらに、FFmpeg を使用してビデオをトランスコードし、Apple iPod で再生する方法を解説した記事も執筆しました。

これはつまり、プロトタイプの作成が必要ということでした。このプロトタイプはイメージを起動し、トランスコード対象のビデオ・ファイルの情報を取得し、私達が既に作成した API を呼び出し、その結果を Amazon S3 に格納して終了します。ほんの何週間かでプロトタイプを完成できると、私達は AWS とオープンソース・ソフトウェアをベースとするソリューションを構築する自信が湧いてきました。また、そのプロトタイプのおかげで、より詳細にプラットフォームを制御できるようになりました。私達は FFmpeg やビデオのトランスコードなど、ビジネスの中核となる技術の習得に集中することができました。つまり私達には、ソフトウェア製品のベンダーへのロックインや、物理的なハードウェアや予算による制約はなかったのです。私達はプロジェクト当たりのコンピューティング・リソースとストレージ・リソースの正確なコストを知ることができ、それらのコストを価格体系に反映させることができました。

このプラットフォームを構築する上で非常に重要なことは、ビデオのトランスコードについて学ぶことと、主要な作業ツールである FFmpeg について学ぶことでした。このプロジェクトは boto のような純粋な Python ライブラリーよりも、はるかに技術的で混乱しやすいものであることがわかりました。当時の私にとって、ビデオ・コーデックは外国語の奇妙な方言のように思えました。そのため私は、ツールの理解に関する問題なのか、ツールで使用されているライブラリーの問題なのか、あるいはビデオの仕様一般に関する問題なのかを判断することができませんでした。

私は Freenode の IRC チャネル #ffmpeg を見たり、ドキュメントを読んだり、さらには C で作成されたソース・コードの勉強まで試み始めました。IRC チャネルは非常に役立つということはわかりましたが、自分で調べられたり、ドキュメントを読むことで答えを見つけられたりするような質問をする人に対し、IRC チャネルは非常に手厳しいものでした。私は最初、それに恐れをなしましたが、しばらくすると、それが品の悪さではなく、余分なことをしないためであることに気付きました。このコミュニティーのエチケットは、まず FAQ やドキュメントで答えを探し、そして IRC チャネルで質問をする場合には、このプロジェクトに関係のある有用な情報またはコンテキストを取得してから質問をする、ということのようでした。そうしたエチケットを習得できると、さまざまな質問に対する答えを無事に得られるようになりました。

上に戻る

買収: ライセンスに関する考慮事項

初期の立ち上げに関わった誰もが願っていた日がやって来ました。私達の会社の買収に関心を持つ人が現れたのです。最初の興奮がさめると、デュー・ディリジェンスに関する一連のチェックがありました。チェックの 1 つはソフトウェアのライセンスのチェックで、対象となったのはかつて StudioNow の作成に使用していたソフトウェアで、そのチェックのときにも使用していたソフトウェアでした。AOL の法務担当者達は、GPL 関連のコードが使用された痕跡がないかを非常に念入りにチェックしました。GPL には、GPL コードの派生物も GPL でなければならず、またソース・コードを配布しなければならない、という条項があります。さらに、GPL ライセンスのライブラリーに (静的または動的に) リンクすることが、GPL ライセンスの持つ「ウィルスのような」性質の元凶かどうか、非常に曖昧です。

私達は、ほとんどの部分で問題ありませんでした。しかし私達が使用している FFmpeg にはリンクされたライブラリーがあり、それは LGPL (Lesser General Public License) ではなく GPL が強制されることを意味しました。私達はソース・コードの再配布や変更をしたわけではなく、単にコンパイルされたライブラリーを使用してビデオをトランスコードしているだけでしたが、この問題を回避する方法を見つける必要がありました。幸いなことに、私達のトランスコード・サービスには GPL を必要とする部分が使われていませんでした。そのため、別のコンパイル・フラグを使用して新しい FFmpeg ライブラリーを再コンパイルするだけで済みました。

上に戻る

まとめ

オープンソース・ソフトウェアを使用したソリューションを市場に導入して成功するためには、単に無料のソース・コードを使用すればよいわけではありません。オープンソース・ソフトウェアはエコシステムであり、コミュニティーでもあります。関心対象のさまざまなコミュニティーに深く関わり、積極的なメンバーになることで、多くを得ることができます。また、そのソフトウェアを使用するということは、ぜひともそのプロジェクトに貢献する必要があるということです。最後に、使用されているさまざまなオープンソース・ソフトウェアのライセンスに注意してください。後で、それらのライセンスが非常に重要になる場合があります。

オープンソース・ソフトウェアを使用して皆さんの次期ベンチャーを構築し、その自由さと楽しさを満喫してください。

参考文献

学ぶために

• 『Dive into Python』: この Mark Pilgrim 著による本は Python 言語の入門書として好適です。
  
  
• 「Discover Python」(developerWorks、2006年): この連載記事を読んでください。変数、コンテナー・オブジェクト、複合文など、Python プログラム初心者のためのトピックが解説されています。
  
  
• Safari bookstore: 特定の技術リソースを見つけるための E リファレンス・ライブラリーを訪れてください。
  
  
• 関心のあるイベント: IBM オープンソース開発者にとって関心のある、今後開催される会議や業界展示会、ウェブキャスト、その他のイベントについて調べてみてください。
  
  
• developerWorks の Open source ゾーン: オープンソース技術を使用した開発や、IBM 製品でオープンソース技術を使用するためのハウ・ツー情報やツール、プロジェクトの更新情報など、豊富な情報が用意されています。
  
  

製品や技術を入手するために

• FFmpeg: 音声と動画の記録、変換、ストリーミングのためのクロスプラットフォームのソリューションについて学んでください。
  
  
• boto: この Python パッケージのメインのソース・コード・リポジトリーを調べてみてください。boto は Amazon Web Services に対するインターフェースです。
  
  
• Django: この上位レベルの Python Web フレームワークに関して学んでください。
  
  
• Pinax: Django の上に構築されたプラットフォームに関する情報を調べてみてください。
  
  
• IBM ソフトウェアの試用版: 皆さんの次期オープンソース開発プロジェクトを IBM ソフトウェアの試用版を使って革新してください。ダウンロードあるいは DVD で入手することができます。
  
  

議論するために

• developerWorks コミュニティー: 開発者向けのブログ、フォーラム、グループ、ウィキなどを利用しながら、他の developerWorks ユーザーとやり取りしてください。
  
  
• Real world open source: オープンソースに焦点を絞った developerWorks のコミュニティーの構築を支援してください。
  
  

著者について

Patrick Altman は Pinax の中核的な開発者であり、他にも多くのオープンソース・プロジェクトを作成し、それらに貢献しています。彼は現在、Eldarionの VP of Engineering です。それ以前には、後に AOL に買収された StudioNow の Principal Software Engineer でした。彼は現在テネシー州ナッシュビルに住んでおり、妻と 3 人の子供がいます。

この記事を評価する

コメント

上に戻る

目次

• はじめに
• プラットフォームを選択する: Ruby それとも Python？
• コミュニティーの力
• スケーリングの方法を学ぶ
• 買収: ライセンスに関する考慮事項
• まとめ
• 参考文献
• 著者について
• コメント