|
プロジェクトが持続可能であるためには、自らのコストを賄うことができなければなりません。これらのコストには、インフラストラクチャコスト（ホスティングや付随サービスなど）に加え、コードベースの開発、更新、保守にかかるコストが含まれます。さらに、プロジェクトによって発生するガバナンス、マーケティング、コミュニケーションにかかるコストも含まれます。 多くのプロジェクトの初期コストは、親組織、スポンサー、投資家、または創設開発者からの初期投資によって賄われます。 しかし、このお金とリソースがすべて使い果たされたらどうなるのでしょうか? 初期資金調達は実行可能な選択肢ですが、無期限ではありません。いずれは収益の増加かコストの削減が必要になります。持続可能なオープンソースプロジェクトを実現するには、収益またはコスト削減が継続的なサポートと開発にかかるコストを上回らなければなりません。 ソフトウェア開発の厳しい現実は、ほとんどのプロジェクトが持続可能ではないということです。これはオープンソースプロジェクトにもクローズドソースプロジェクトにも当てはまります。実際、資金を必要とするあらゆる活動に当てはまります。現実は、創造的なアイデアの大部分は持続不可能であり、持続可能なのはほんのわずかであることを証明しています。 したがって、プロジェクトが持続可能性を達成できない理由を探る必要があります。場合によっては、プロジェクトが当初の目標を達成できなかったことが原因となることがあります。その結果、人々はプロジェクトが中止されると予想します。しかし、懸念すべきことに、多くのプロジェクトは、当初の目標を達成したものであっても、依然として持続可能ではありません。これは特に公的資金によるプロジェクトに当てはまります。このような失敗は、多くの場合、計画不足が原因です。つまり、当初の資金が枯渇した後、どのようにプロジェクトを持続させるかについての計画が当初に存在せず、持続可能性を達成するためのリソースが割り当てられていなかったのです。 したがって、結論は明白です。持続可能性を達成するには、プロジェクトの初期目標に持続可能性計画の実施を含める必要があります。つまり、持続可能性計画はプロジェクトサイクルの最初から策定されるべきです。そして、この計画を策定するには、利用可能な選択肢を理解しなければなりません。 持続可能性の選択肢は数多く存在するため、ここですべてを列挙することは不可能です。以下では、オープンソースソフトウェアに共通する持続可能性モデルを簡単に紹介します。 これらのモデルのいずれかに厳密に分類できるプロジェクトはごくわずかです。ほとんどのプロジェクトは、様々なモデルの要素を様々な方法で組み合わせることで持続可能性を実現しています。同様に、様々なモデル間にも共通点があります。以下のセクションは、持続可能性計画の策定を開始する際の参考としてのみ提供されています。この情報は、OSS Watchのような、お客様にとって利用可能な機会を理解しているアドバイザーとのつながりを築くのに役立ちます。 オープンソース製品の開発に携わる企業は、他の企業と何ら変わりません。つまり、収益の一部を製品開発に投資する必要があるということです。商用オープンソースソフトウェアを開発できる企業には、主に4つの種類があります。 サポート、トレーニング、カスタマイズ、検索エンジン、電子商取引などの有料製品の市場シェアを最大化しようとしているオープンソースソフトウェアサービス企業、プリンターや携帯電話メーカーなどの潜在的なハードウェア市場への拡大を模索しているハードウェア企業、オープンソースコンポーネントを使用し、デュアルライセンスモデルを採用して自社製品の独自バージョンとオープンソースバージョンの両方をリリースしているソフトウェア企業。 企業の活動は上記のいずれかに限定されず、同様に、各オープンソース プロジェクトの商業化は複数の企業によって実現できます。 サービス企業やハードウェア企業にとって、主な収益源はソフトウェアそのものではありません。そのため、これらの企業は、第三者からの貢献から利益を得るために、オープンソースライセンスの下でソフトウェアをリリースできる可能性があります。 サービス指向の企業にとって、ソフトウェアをオープンソース化する動機は同じです。コンサルティングやカスタマイズサービスを提供する企業は、自社サービスの需要を最大化したいと考えているため、コア製品のオープンソース版をリリースすることは市場育成策となります。さらに、ソフトウェア主導型サービス（検索エンジン、Web 2.0サービス、eコマースなど）を提供する企業には、自社のソフトウェアスイートのうち競合関係にない部分をオープンソース化する強い理由があります。これにより、開発コストを共有することで、初期開発、運用開発、そして継続的な保守にかかるコストを削減できます。例えば、Amazon、IBM、Yahoo!、eBay、Facebookなど、ますます多くの企業がApache HTTPDウェブサーバーとGNU/Linuxを活用し、貢献しています。 ハードウェア企業にとって、オープンソース化の動機は、ハードウェア市場の拡大や製品開発コストの削減にあると考えられます。例えば、プリンターメーカーはドライバーをオープンソース化し、様々なプラットフォーム向けにカスタマイズすることで、ハードウェア市場を拡大する可能性があります。同様に、携帯電話メーカーは、共通機能の開発コストを他社と共有するために、オープンソースソフトウェアをコアOSとして採用する可能性があります。 ソフトウェア販売で利益を上げるソフトウェア企業には、2つのモデルがあります。ただし、それぞれのモデルは特定のオープンソースライセンスの下でのみ有効です。オープンソースソフトウェアを自社のプロプライエタリ製品に組み込みたい企業は、いわゆる「パーミッシブ」オープンソースライセンス（一般的にBSDライセンスとして知られています）を使用することでこれを実現できます。一方、デュアルライセンスモデルを採用している企業もあります。つまり、いわゆる「パブリック」ライセンス（GPLなど）とプロプライエタリライセンスの両方でソフトウェアを販売するのです。 組織が開発したソフトウェアは、それ自体では収益を生み出さないことがよくあります。そのような場合、組織はソースコードを公開することで開発コストを削減できます。このような状況では、ソフトウェア開発を管理する非営利団体を設立することが検討できます。これには2つのメリットがあります。1つ目は、インフラと管理コストの大部分をこの非営利団体が負担できることです。これらのコストは、非営利団体が管理する製品を使用する企業によって賄われます。2つ目は、より多くの組織がプロジェクトに参加するようになることです。なぜなら、彼らは常にプロジェクトの製品を使用し、すべての貢献者に利益をもたらす方法で管理できると確信するからです。つまり、プロジェクト戦略と「衝突」する商業的利益や、開発を支配する「買収」は発生しません。 おそらく、そのような組織の最も良い例は、Apache Software Foundation（ASF）でしょう。これは、Apache Web Server（HTTPD）をはじめとする多くのXMLおよびJavaベースのプロジェクトを主導する非営利団体です。企業や個人からの慈善的な資金援助を受け、ASFはApacheプロジェクトの開発者が作業を行うために必要なインフラストラクチャを提供しています。ASFでの作業は個人によって行われ、その多くはApacheコードを社内開発やカスタムバージョンの販売に使用している企業の従業員です。 例えば、Apache Raveポータルフレームワークは、当初は学術機関やビジネスパートナーによってApacheインキュベータのプロジェクトとして提案されました。その後、多くの開発者の関心を集め、2012年にはASFのトップレベルプロジェクトに昇格しました。 その他の非営利財団の例としては、以下のものがあります。 フリーソフトウェア財団 アライアンス 組織のコアチームがプロジェクトで協力する場合、ソフトウェアメンテナンス連盟が形成されることがあります。これは、非営利団体の設立（上記参照）に似ています。連盟と非営利団体の主な違いは、連盟のメンバーは非営利団体の創設者よりもプロジェクトに対する権限が強いことです。非営利団体は全員に利益をもたらす方法でソフトウェアを管理しますが、連盟はメンバー（および利害関係者）に利益をもたらす方法でソフトウェアを管理します。 連合モデルの利点の一つは、リソース（時間と資金）の使い方を決定できるため、プロジェクトをより細かく管理できることです。しかし、この事実は、コアチームメンバー以外の人々にとってプロジェクトの魅力を低下させてしまいます。今日のユーザーは将来の開発者となるため、早期のユーザー参加を促すことは非常に重要です。しかし残念なことに、連合モデルでは、プロジェクトメンバーではないという理由で疎外感を抱くユーザーが少なくありません。 興味深いことに、シード資金で設立された多くのプロジェクトは、善意の独裁制や連邦制モデルで立ち上げられることが多いものの、シード資金が枯渇すると他のモデルに切り替えざるを得なくなります。この移行は非常に困難です。 DSpaceプロジェクトは、教育システムにおけるフェデレーションプロジェクトの成功例です。フェデレーションモデルの他の例としては、Apereo FoundationとKuali Foundationが挙げられます。DSpaceとApereoはどちらも、よりオープンなモデルへの移行を進めています。 組織がオープンソースソフトウェア製品を選択する理由は様々です。新しいプロセスの導入、既存プロセスの効率化、ソフトウェアライセンスコストの削減などが挙げられます。また、既にオープンソースソフトウェア製品を導入している組織は、さらなるメリットを得るためにオープンソースプロジェクトにコードを提供することもあります。例えば、新機能を追加して社内プロセスをさらに効率化したり、バグを修正して従業員の生産性を向上させたりすることが挙げられます。 この文脈において、フィードバック・プロジェクトには主に2つの目的があります。1つ目は、フィードバックを提供することで、組織が依存するソフトウェアがアクティブな状態を維持していることを保証できることです。2つ目は、フィードバックを提供することで、組織は将来のアップグレードを可能な限りスムーズに実行し、アップグレード後にローカルな変更を加える必要がないようにできることです。 たとえば、APLAWS オープンソース コンテンツ管理システムは、英国の地方自治体がオンライン サービスを提供できるようにするために開発されました。 英国をはじめとする多くの国では、教育機関によるオープンソースライセンスに基づくソフトウェア開発が奨励されています。高等教育機関におけるオープンソースプロジェクトへの資金提供は、投資会社や大学自身から提供される場合があります。教育機関が直接的な利益を得られる限り、たとえ全額でなくても、投資は継続される可能性が高いでしょう。 教育機関は様々な形で恩恵を受けることができます。おそらく最大のメリットは、内部コストの削減と、教育コミュニティ全体への貢献に対する評価の向上でしょう。そのようなプロジェクトの一例として、ケンブリッジ大学のEximプロジェクトが挙げられます。フィリップ・ヘイゼル氏は1995年の開始当初からEximプロジェクトを率い、ケンブリッジ大学コンピュータサイエンス学部在職中、2007年に退職するまで継続的にプロジェクトに携わりました。もう一つの例は、サウサンプトン大学のMailScannerプロジェクトです。同プロジェクトでは、大学職員のジュリアン・フィールド氏が「賢明なる君主」として活躍しました。 オープン開発は、特にオープンソースソフトウェア開発において、異なる利害関係や専門知識を持つ関係者が協力するための効果的な方法であることが証明されています。ビジネスの世界では、「オープンイノベーション」という概念が広く関心を集めており、これは新製品および既存製品の開発における効果的な手法と捉えられています。綿密な計画と管理を通じて、オープンイノベーションは、商業開発と社会貢献を促進する、管理しやすく制御可能なプロセスを提供し、プロジェクトの学術研究開発チームがビジネスプランではなく具体的な問題に集中することを可能にします。例えば、ボルトン大学が開発したApache Wookieは、学術分野以外の多くの開発者を惹きつけ、2012年にはApacheのトップレベルプロジェクトとなりました。 いくつかの慈善団体がオープンソースプロジェクトに多額の投資を行っています。これらの団体には以下が含まれます。 メロン財団 – 主に図書館分野における重要な活動に資金を提供します。 ボランティア オープンソースソフトウェアプロジェクトへの参加は、楽しいだけでなく、非常に教育的です。そのため、余暇にオープンソースに貢献する人は珍しくありません。上記のモデルに加えて、ボランティア活動も非常に重要であり、ほとんどのオープンソースプロジェクトにはボランティアの参加があります。 現在、プロジェクトはSourceForgeやGitHubといった様々な無料インフラを通じて、ホスティングや関連機能（課題追跡やコミュニティへの参加など）にアクセスできます。つまり、信頼できるコミュニティから開発とリリースのサポートを受けている限り、プロジェクトはゼロコストで持続的に運営できるということです。 （ボランティアの）ユーザーは、フィードバックを提供し、テストを実施するため、オープンソースプロジェクトにとって同様に重要です。特定のバージョンに対するユーザーの期待を管理できれば、オープンソースソフトウェアのトライアル版やアーリーアダプター版をテスト用にリリースすることができ、安定リリースまでのコストを大幅に削減できます。 オープンソース コミュニティの構築に関する OSS Watch ドキュメントには、包括的で多様性のあるオープンソース コミュニティを作成する方法に関する実践的なガイドが記載されています。 |
