オープンソースソフトウェアのリリースが早すぎる[終了]

オープンソースソフトウェアをすぐにリリースすることの道徳的責任は何ですか？たとえば、完全にテストされていない、完成に近い製品です。

プログラマーに期待することは何ですか？完全にテストされるまで待つか、オープンソースにリリースしてから、さらに開発、テスト、および進歩を続けますか？

恐れは、ソフトウェアがオープンソースであり、潜在的に消費者の問題につながる可能性があるということです。

これは根拠のない恐怖ですか？

それどころか、できるだけ早くオープンソースソフトウェアをリリースすべきだと思います。そのための「早すぎる」ことはありません（ただし、コンパイルする必要があります）。

^{または、正式なリリースを行わずに、少なくともソースコードを非常に早く継続的に公開します（たとえば、githubを頻繁にプッシュすることにより）。}

ただし、アルファ段階またはベータ段階としてフラグを立てることが非常に重要であり、可能であれば、欠落しているもの、テストされていないもの、または形状が悪いものを（たとえば、READMEor TODOファイルやブログなどで）伝えることが重要です。このような情報を伝えるためにバージョン番号も使用する必要があります。

フリーソフトウェア、起こるべきことは、最高のソースコードに誰かの視線で、あなたにそれを改善する小さなパッチを提案しています。これがソフトウェアを無料にする理由です！

^{したがって、あなたはあなたのフリーソフトウェアであなたの毎日の仕事を見えるようにする必要があります！外部の貢献者は、パッチがあなたの最近のソフトウェアソースコードで動作しないか、あなたの最近のソフトウェアソースコードの複製である場合、腹を立てます。}

あなたが恐れるべきなのは、あなたのソフトウェアに誰も興味を持たないことです（そしてそれに貢献します）。外部ソフトウェアをフリーソフトウェアに引き付けること（特に、外部の貢献者を引き付けること）は長い道のりです。

TL; DR：

早期リリース。頻繁にリリース。

個人的な逸話：

私が取り組んでいるプロジェクトに本当に興奮しました。本当に興奮しています 夜興奮して眠れませんでした。そこで、共同開発者に、彼が望んでいたよりも早くv1.0をリリースするようにプッシュしました。

ひどかった。想定どおりに機能しませんでした。毎回バグがありましたが、ログに記録して修正しました。私たちは、発見しなかったかもしれないバグをいくつかの早期導入者に提出させました。1、2週間後、多くの問題に対処した新しいリリースをリリースし、新しい機能の構築に戻りました。

早めにリリースすることは、私たちが成し得た最善のことでした。実際のユーザーの前に製品を配置しました。このバグを公開することで、プロジェクトが改善された可能性があります。また、このプロジェクトに真剣に取り組んでいることを早期導入者に知らせています。さらなるリリースと積極的な開発が予定されています。

しかし、それは簡単に他の方法で行ったかもしれません。これらのバグレポートは無視できたでしょう。または、すぐに反応しなかったかもしれません。数週間ではなくv1.1をリリースするのに3か月かかった場合は、別の話だったかもしれません。

クローズドソースソフトウェアと同じです。コミュニケーションは重要です。

ユーザーにソフトウェアの状態とダウンロードの理由を知らせます。

ソフトウェアは、完全にテストされているかどうかに関係なく、常に顧客の問題につながります。ほとんどのお客様はその事実を受け入れますが、一部のお客様は決して受け入れません。しかし、ソフトウェアが合理的に予想されるよりも多くの問題につながる場合、顧客が取っているリスクを知らせる道徳的義務があります。情報は短い形式（「Alpha / Beta / EarlyAccess」ラベル）*と詳細の両方である必要があります。既知の問題、回避策、および特別な考慮事項のリスト（データが破損する可能性がある場合など）。

*ユーザーは、いくつかの大手ソフトウェア会社によって「ベータ」をソフトウェアがかなり堅固な状態であると考えるように訓練されているため、ソフトウェアが「ベータ」であることをユーザーに伝えるだけでは十分な情報ではないことに注意してください。

道徳的責任は一切ありません。誰もあなたの中途半端なソフトウェアを使用することを余儀なくされていません。

心配する唯一のものはあなたの信頼性です。

私の経験では、達成すべきバランスがあります。

現在、私は自分の書いたコードを利用した非常にエキサイティングなFOSSプロジェクトのように見えるものを作成している開発者と（コードに触れることなく、質問に答え、開発提案を提供するという意味で）働いています。パブリックリリースは、長期的にプロジェクトを大幅に改善する設計変更の実現により繰り返し延期されてきましたが、既に記述されていて既に「機能している」コードの大幅な書き直しが必要です。私の見解では、機能するが不完全なリリースが表示されるようになってすぐに行われた場合、変更（および実際のパッチ）のアイデアは、このプロジェクトに関心のあるより広範なコミュニティからもたらされ、問題は1つずつゆっくりと表面化します。開発者がそれらについて考え、自分自身やコミュニティの他の関心のあるメンバーからの設計フィードバックを求めます。したがって、この観点から、私は「早期リリース、頻繁にリリース」を強く推奨しています。

一方、低品質のリリースは、新しいプロジェクトが着手する前に見た目を悪くする可能性があります。私が見たいくつかの落とし穴は次のとおりです。

• インターフェイス定義はあるがコードはないスケルトンツリー。
• 開発者以外の人のために正常にコンパイルされないコード。
• プログラムのビルド/実行方法に関する指示はありません。
• どの側面が機能すると期待できるかについての文書はありません。
• プログラムが何をするか、何をするかについての不明確な説明。
• 有用性のデモンストレーションの欠如。

最後のポイントとして、私は次のようなことを考えています：

• hello-worldタイプのプログラムをコンパイル/実行することさえできないコンパイラー/インタープリター。
• 少なくとも、ある種のサンプルプログラムを実行できない、または何かを実行していることを実証できないエミュレーター。
• 変更されていない画像をロードして再保存する以外に何もできない画像処理ツール。
• タイトル画面のみのゲーム。

これらの種類の問題は、最初に動作するコードの不足について非常にオープンでない限り、揺れにくいハードウェアイメージにつながります。

最後に、バージョン番号を意味のあるものにします。プロジェクトがクラッシュすることなくユーザーが期待することを実行するまで、プロジェクトを「1.0」と呼ばないでください。私は常に、最初のパブリックリリースに「0.5」前後のバージョン番号を使用してそこから行くことに成功していましたが、意味のある「0.1」や「0.10」なども見ました。

フリーソフトウェアをリリースすると、マイナスの結果が生じる場合があります。一部の仕様は、一般に配布されるすべての実装が最初に公開されたときに仕様に完全に準拠することを条件に、一般にライセンスされています。出版社は、仕様の進行中の実装を配布することを法的に禁止しています。仕様の発行者から特定の交渉済みライセンスがなければ、すべてのテストに合格するまで誰とでも共有する必要があります。これにより、仕様の実装に「カテドラルモデル」（Eric S. Raymondが呼んだように）が強制されます。

そのようなライセンスの下での1つの仕様は、Java言語仕様です。この制限は、JVMと互換性のある仮想マシンの開発者に適用されますが、幸い、JVMで実行されるアプリケーションの開発者には適用されません。

Liu Qihao＆Ciaran O'Riordanによる記事「4 Shifty Details About Microsoft's 'Open Source' .NET」は、同様の方法でCLRの不完全な実装を除外するために、.NETライブラリおよびランタイムコンポーネントに対するMicrosoft Patent Promiseを解釈する可能性について言及しています。 。ただし、これもCLRで実行されるアプリケーションには適用されません。