一連のクローズド ソース アプリケーションとライブラリがあり、ソース コードを公開することは理にかなっていると考えています。
これまでのところ、コード ベースをクリーンアップし、公開する前にソースを文書化するために必要な作業が妨げられていました。
プロジェクトが成功する合理的な可能性がある場合、つまり貢献者がいる場合にのみ、ソースを公開したいと考えています。このコードは、多くの開発者にとって興味深いものになると確信しています。
プロジェクトの「面白さ」と「有用性」以外に、オープンソース プロジェクトの成功を左右する要因は何ですか?
例:
コードの成功を左右する要素がいくつかあります。採用される可能性を最小限に抑えるには、これらすべてを達成する必要があります。
これらの問題を検討するにあたり、カリフォルニア大学バークレー校で開催されているオープン ソースに関するオンライン バージョンのコース(「デジタル情報のオープン ソース開発と配布: 技術的、経済的、社会的、および法的観点」)をチェックしてみることに興味があるかもしれません。Mitch Kapur (Lotus の創設者) とロースクールの教授である Paula Samuelson が共同で教えています。通勤時間が長いので、昨年はコースの音声を iPod に保存しました。彼らは、非常に広い (明らかに学問的ではありますが) 観点から、何が機能し、何が機能しないのか、そしてその理由について多くのことを話しました。
最も重要なことは、プログラムが優れていることです。良くなければ誰も使わない。ニワトリが先か卵が先かという状況が逆転し、それが良くなるまで人々がそれを当たり前だと思ってくれることを期待することはできません。
もちろん、「良い」というのは単に「かなりの数の人々にとって、他のどの実用的な選択肢よりも優れている」という意味であり、それが厳密に最高であることを意味するのではなく、多くの人にとってより優れた機能を備えていることだけを意味します。その他のオプション。場合によっては、プログラムに同等のものが他にないことがあります。その場合、この点に関してはほとんど要件がありません。
プログラムが優れている場合、人々はそれを使用します。明らかに、それはユーザーの間で市場を持たなければなりません - 誰も望んでいないことをする良いプログラムは、どんなにうまく設計されていても、本当に良いとは言えません。マーケティングについて主張することはできますが、真に優れた製品は、ある程度までは、それ自体を売り込む傾向があります。よくないものを宣伝するのははるかに難しいので、製品を宣伝するのではなく、製品自体を最優先にすべきであることは明らかです。
本当の問題は、どうやってそれを良くするかということです。その答えは、献身的で熟練した開発チームです。1 人の人が自分で良い製品を作成できることはめったにありません。彼らが他の開発者よりはるかに優れていたとしても、複数の視点はプロジェクトに信じられないほど有益な効果をもたらします。これが、企業のスポンサーを持つことが非常に有用な理由です。それは、(企業の) 他の開発者の考えを問題に向けさせ、彼ら自身の意見を与えるためです。これは、プログラムの開発にコミュニティでは一般的に利用できない重要な専門知識が必要な場合に特に役立ちます。
もちろん、私はこれをすべて経験から言っています。私は、最も人気のあるビデオ エンコーダーの 1 つである x264 (現在最も活発な開発者) の主要な開発者の 1 人です。私たちには 2 人の主要な開発者、パッチを提供するコミュニティ内のさまざまなマイナーな開発者、および Joost (ratecontrol アルゴリズムを維持している Gabriel Bouvigne) からの企業スポンサー、Avail Media (私が時々契約で働いており、現在は契約でコーダーを雇っている) からの企業スポンサーがいます。 MBAFF インターレース サポートを追加する)、および時々ポップアップするいくつかの他のものから。
1 人の優れた開発者がプロジェクトを作成するわけではありません。多くの優れた開発者が作成します。そして、この最終結果は、非常に膨大な開発予算を持つ競合他社のハードウェアやソフトウェアでさえも、ビデオをより速く、はるかに優れた品質でエンコードするプログラムです。
このテーマについて本が書かれています。実際、ここで無料の本を見つけることができます: オープンソース ソフトウェアの作成
最も重要な要因は、プロジェクトを使用しているユーザーの数だと思います。それ以外の場合は、非常によく書かれており、有用で、よく文書化された、サーバー上にあるものの束であり、あまり機能していません...
貢献者を獲得するには、まずユーザーが必要で、次に不完全さが必要です。「これはクールだけど、これがあったらいいのに、またはこのように違っていたらいいのに」というトリガーが必要です。明らかな機能が欠けている場合、ユーザーがそれを追加する貢献者になる可能性が非常に高くなります。
オープンソースにするだけです。おそらく、まだ誰も貢献し始めないでしょう。しかし、少なくともあなたはあなたの製品がGPLか何かであるとプレスリリースに書くことができます。
最初のステップは、人々がそれを使い始めることです...
そして、おそらく、ユーザーが快適になった後、彼らは貢献し始めるでしょう。
本当に、答えは「プロジェクトをどのように実行するか」だと思います。
はい、あなたの例はすべて重要ですが、重要なことは、開発者間のやり取りがどのように管理されるか、パッチなどがどのように処理/受け入れられるか、誰が「責任者」であり、その責任をどのように処理するかなどです。
Perl での Class::DBI と DBIx::Class の開発管理を比較対照してください (歴史を追跡するのは難しくありません!)。
私は今夜、成功したオープンソース プロジェクトと失敗したオープン ソース プロジェクトのユーザビリティの側面に関する優れた投稿を読んでいました。
抜粋：
オープンソース ソフトウェア/フリー ソフトウェア (以降、「OSS」) の使いやすさの欠如について議論するために、多くの帯域幅が浪費されてきました。現時点では、ブログ、フォーラム、および Slashdot のコメント スレッドで議論が続いています。悪いユーザビリティは OSS の世界全体に固有のものであると言う人もいれば、OSS のユーザビリティは素晴らしいが、本当の問題はすべてのプログラムが Microsoft のクローンを作成することを期待している偏狭なユーザーだと言う人もいます。UI の問題は一時的な成長痛だと主張する人もいれば、OSS 開発モデルが体系的に悪い UI を生み出すと言う人もいます。一部の人々は、GPL が間接的に使いにくいソフトウェアに報いるとさえ主張しています! （記録として、私は同意しません。）
これまでのところ、全員の回答は良好ですが、1 つ欠けていることがあり、それは見落としです。なんらかのプロジェクト管理を行わないことほど、オープンソース プロジェクトを早く終わらせるものはありません。何をすべきかを人々に伝えるのではなく、あなたが惹きつけたい開発者のために何らかの構造とタスクを追加するだけです。
まとまりのないプロジェクトはすぐに崩壊します。それはただ放して飛んでいくのを見るだけの鳥ではありません。