http://oss-watch.ac.uk/resources/businessofopensource
で マシュー・ランガム、Indiginox 2009年2月3日に、最後の2012年9月9日を更新
今日でも、同じ文章中の単語のビジネス」と「オープンソース」を言及することは確かにオープンソースソフトウェアの周りに大きなビジネスの経済があるという事実にまだ慣れていない観客から奇妙な発言を求めることができます。これは、オープンソースソフトウェアを使用している企業は、一般的に「無料」のソフトウェアの周りのサポートや他のサービスのいずれかの種類にも無償で利用可能であるべきと考えていることそのずっと前にではありません。無料サポートが期待されていなかった一方で、それは広く専門家のサポートが利用できなかったと仮定しました。同時に、オープンソースコミュニティは、時にはそれが困難営利団体と公然と相互作用することが見出さ。
しかし、物事は変化しており、これらの日、私たちは、これらのコミュニティによって生成ソフトウェアを商用化、オープンソースコミュニティと企業間のオープン婚約を見ることができます。また、企業は、コミュニティやプロジェクトに戻って何かを与えていないしながら、オープンソースソフトウェアからお金を稼ぐことは、最終的にする可能性があることを認識し始めている 故障の原因となります 彼らのオープンソース関連製品の。ごく最近まで、このようMozilla Foundationは、Linux Foundationの、エクリプス財団およびApache Software Foundationのオープンソース・プロジェクト、周りに確立されている組織では、両側の間の係合を促進するために懸命に働いてきたし、これは持っているだろういくつかの結果を生産しています「不可能」とみなされて。たとえば、Microsoft、オープンソース開発モデルの歴史的に最も猛烈な異議申立は、された に貢献し、そしてスポンサー 2008年以来、主要なオープンソースソフトウェア開発コミュニティのいくつかを。
ここ数年、多くの異なるビジネスモデルが周りのオープンソースソフトウェアを進化させてきたので、それは問題の製品とターゲット市場を維持するために最も適している可能性があるビジネスモデルについて慎重に検討する可能性、オープンソースベンダーのために重要になっています。
この記事では、オープンソースのビジネスモデルのさまざまなコンポーネントの概要を説明します。補足文書は、探究 持続可能性の問題 、オープンソース・プロジェクトを中心にビジネスモデルの構築に関連付けられています。
オープンソースのビジネスモデルではありません
指摘した最初の、そしておそらく最も明白な、事は、オープンソース自体がないということです、そして、ビジネスモデルとなってはありませんでした。それがビジネスを行う方法であるかのように、ベンダーは用語オープンソースを使用しての警戒する必要があります。オープンソースは、単純にそれを置くために、ソフトウェアを開発し、配布する方法です。
より多くの商業組織は、オープンソースで使用し、魅力の利点を理解し始めたとして、それはまた、障壁、彼らは実際に自社製品との確立エンタープライズソリューションを置き換えるために始めることができる前に克服するために必要なオープンソースベンダーがあったことが明らかになりました。
- 他のソフトウェアコンポーネントと困難なインストール・メカニズムには不明の依存関係
- ソフトウェアの統合と適応周りの商用グレードのサポートとサービスの欠如
- 不明確なロードマップと、多くの場合、非常に「動的」プロジェクト
- 必要なスキルセット企業内の欠如
- トレーニング、ドキュメント、および教育の必要性
これらの障壁を克服するために、オープンソースベンダーは、商業顧客のニーズを満たしてビジネスモデルを確立し始めました。これらのビジネスモデルは、オープンソースソフトウェアを中心に構築されており、収益の流れが生成される方法によって定義されています。生成可能なストリームのどのような種類の選択が問題となっているオープンソースソフトウェアに大きく依存し、このために、それは「オープンソースのビジネスモデル」または「最高のオープンソースのビジネスモデルのようなものは存在しないと述べている必要があります」。持続可能なビジネスモデルを構築することは、あなたが販売し、どのような市場が期待しているもの、あなたが販売している人によって異なります。
収益ストリーム
さまざまな方法 収入を生成するには、 大きく以下の領域に分割することができます。
- パッケージングおよび配布
- オープンソース製品への代替支払われたライセンスを提供
- オープンソース製品を中心にサービスとサポートを提供
収益創出に加えて、コア・ソフトウェア・コンポーネントの共有開発によるコスト削減のための機会があるかもしれません。このトピックの更なる検査は、この記事の範囲外です。
パッケージングおよび配布
人気となった最初のオープンソースのビジネスモデルは、包装のものだったし、インストールして使用を開始することを容易にする方法で、オープンソースソフトウェアを配布します。Linuxでは、オープンソースのオペレーティングシステムのさまざまなディストリビューションは、このビジネスモデルの例です。
相反に該当してもソフトウェア1つの GNUパブリックライセンス（GPL）はまだ有料で販売することができる2 。通常、企業は、DVDなどのパッケージやメディア上のソフトウェアを配布するための手数料を請求します。
オープンソースソフトウェアをパッケージ化する他の方法は次のとおりです。
- アプライアンスとソフトウェアをバンドル
- オープンソースコンポーネントの完全な「スタック」を構築し、配布します
アプライアンスのアプローチの例としては、一般的なLinuxベースのネットワーク・ルータです。基盤となるソフトウェアは、GPLなどの逆数ライセンスの下でライセンスされているケースでは、ベンダーが顧客に利用可能なソフトウェアのソースコードを作成する必要があります-追加料金なしで。これを行うに失敗すると、ベンダーは、最終的に法廷で自分自身を見つけることができますことを意味します3。
「スタック」モデルでは、ベンダーは、特定のビジネスドメインの必要性を満たすために、オープンソースソフトウェアの完全なパッケージをコンパイルします。これは、例えば、企業の文書管理システムをインストールして実行するために必要なオープンソースコンポーネントのコンパイルである可能性があります。このモデルはまた、我々は後で見るように、サービスからの収入を生成するために使用されます。
包装、流通モデルのすべてがオープンソースの採用が直面している5つの懸念の2に対処しようと、特に（セクション1を参照してください）：
- 他のソフトウェアコンポーネントと困難なインストール・メカニズムには不明の依存関係
- 不明確なロードマップと、多くの場合、非常に「動的」プロジェクト
商業代替
ベンダーは、オープンソースプロジェクトの完全なIP（知的財産）を所有している場合は、その後、彼はソフトウェアを顧客に提供する方法を自由に選択することができます。同時に同じソフトウェアの商用版（または「エンタープライズ版」）を提供しながら、多くの場合、ベンダーは、（しばしば「コミュニティ版」と呼ばれる）の逆数のオープンソースライセンスの下でソフトウェアのバージョンを提供します4。これは、一般的「と呼ばれるデュアルライセンス」とMySQLのような企業で人気の行われています。商業、コミュニティ版との違いは、次のようになります。
- バグ修正は、より頻繁に適用され、ソフトウェアはより頻繁にリリースされます
- コミュニティ版の特定のモジュールは、「より良い」選択肢に置き換えられます
- 商業環境への統合を可能にするソフトウェアパッケージに含まれている追加コンポーネント
- 商用版は、付属のサポートパッケージが付属しています
オープンソースベンダーは、したがって、潜在的な顧客にも適応し、個人的な使用のためのソフトウェアを拡張することができ、ソフトウェアのコードへのアクセスを提供します。顧客は、コミュニティ版で「間に合わせる」ことができれば、その後（内部的に製品をサポートすることができることによって）、コミュニティ版は十分かもしれません。そうでない場合には、顧客はサポートが付属して商用版を購入することを選ぶことができます。
このようにApacheソフトウェアライセンスとして許容ライセンスの下でライセンスのオープンソースプロジェクトは、商用ライセンスを含め、他のライセンスの下でソフトウェアの再ライセンスを許可します。これはpermissivelyライセンスのプロジェクトを取ると商用ライセンスの下でコードを配布する商用ベンダーができます。これは、ソフトウェアベンダーが大きく、商用製品にオープンソースコンポーネントが組み込まれたときに、例えば、発生する可能性があります。例えば、IBMはその商用製品のWebSphereにApacheプロジェクトのXalan、XSLTプロセッサを、統合しました。
サービスの提供
オープンソース製品を中心にサービスを提供することは、収益を生成する一般的な方法です。提供可能なサービスの範囲は広く、ベンダーのスキルに応じて異なります。
顧客に提供することができます潜在的なサービスが含まれます：
- コンサルティング（すなわち、顧客が特定の製品の利点とリスクを理解する手助け）
- 統合作業（つまり、既存の環境にオープンソースのソリューションを統合します）
- トレーニング（すなわち、顧客が問題になっているオープンソース製品に速度まで得るのを助けるためのワークショップ、および/またはオンサイトトレーニングを提供します）
- 開発（つまり、新しい機能を追加したり、特定のバグを修正）
そのため、オープンソース製品の性質上、顧客はサービスのベンダーが根底にあるプロジェクトに係合すると、ソフトウェアの周りに関連する知識を持つように見えることを期待しています。ベンダーは、オープンソースプロジェクトへの積極的な参加により、関連する出版物でのブログや記事をボーカルであることによって、彼の専門知識を強調することができます。
商業化のサービスモデルは、オープンソースの採用が持つ残りの懸念に対処しようとする具体的には、（セクション1を参照してください）：
- ソフトウェアの統合と適応周りの商用グレードのサポートとサービスの欠如
- 必要なスキルセット企業内の欠如
- トレーニング、文書化、および教育の必要性
- プロジェクトにコードを直接貢献する顧客の無力
コミュニティへの影響
かかわらず、実際のオープンソース製品のオリジネーターの、それぞれが前方の製品を駆動人々の「コミュニティ」に何らかの形で依存しています。そのコミュニティは、多様な人々のセットまたは別の会社から数の従業員に限定することができます。しかし、関係なく、コミュニティが作られているかの、各メンバーは、現在の位置にオープンソース製品を駆動するに時間と労力を入れています。
オープンソースソフトウェアを中心に構築された任意のビジネス・モデルは、したがって、何らかの方法で、社会に影響を与えます。ソフトウェアを中心にビジネスを構築することを考え、任意のベンダーは、インターネットを介して彼のビジネス提案をスプラッシュを急いで前にこれを考慮に入れる必要があります。コミュニティは、彼はベンダーが積極的にこの時点までプロジェクトのアップに従事されていない場合は特に、プロジェクトとそのコミュニティを制御したり、所有しようとしていると考える場合、それはすぐに裏目に出ることができました。オープンソースコミュニティの強さは、それが潜在的にソフトウェアを中心に構築された任意のビジネス・モデルにダメージを与える、徒歩、オープンソースプロジェクトのフォークを使用して別のプロジェクトを開始することを選択できることを意味し、「その足で投票」ことができるということです。オープンソースプロジェクトに従事どのようなビジネスは、それゆえに敏感でなければなりません 地域社会のニーズ や要望に出来る限り、すべての利益との懸念が満たされている、それを確実にするために、コミュニティと協力。
追加のアドバイスを見つけます
私たちは、この記事で見てきたように、持続可能なオープンソースのビジネスモデルを選択すると、単にソフトウェアのライセンスを選択するよりも複雑です。オープンソースのビジネスモデルは、ソフトウェアや消費者のニーズに応じて、異なるコンポーネントで構成することができます。そのため、ベンダーは、各コンポーネントとそれらがどのように問題になっているオープンソースソフトウェアに適用することもできるの意味を理解する必要があります。
ビジネスモデルを選択する際に、オープンソース版では、製品をリリースするために探して、ベンダーにとっては、追加のコンサルティングおよび指導を得ることが理にかなっています。
2009年1月には、OSSウォッチは無料とオープンソースソフトウェアの周りにビジネスと持続可能性のモデルと題した1日のワークショップを開催しました。 ワークショップの報告書は 、商業ビジネスモデルに関する詳細な情報を提供します。
参考文献
リンク：
- Mozilla Foundationは[ http://www.mozilla.org/foundation/ ]
- Linux Foundationの[ http://www.linuxfoundation.org/ ]
- エクリプス財団[ http://www.eclipse.org/org/ ]
- Apache Software Foundationの[ http://www.apache.org/ ]
- MySQLの[ http://www.mysql.com ]
- WebSphere [ http://www-01.ibm.com/software/websphere/ ]
- フリーソフトウェア財団[ http://www.fsf.org/ ]
OSSウォッチからの関連情報：