オープンソースプロジェクトの生産準備はいつですか？

新しいオープンソースライブラリ/プロジェクトを見つけた場合、ソースベースに組み込む前にどのような基準を検討しますか。

• 答える必要がある法的質問はありますか？

• 一定の開発速度を求めていますか？

• コミュニティの話題は十分な理由ですか？

• あなたがプロジェクトのライン上にいる場合、あなたの決定は変わりますか？

• ドメインやコードの複雑さがあなたの考え方を変えますか？

プロジェクトの成熟度に関する私のチェックリストは次のとおりです。

プロジェクトは最初のマイルストーンに達しましたか？

自己記述型の最初のマイルストーンに達していない場合、コードを追加することは避けます。自分のプロジェクトが生産準備完了であると主張する開発者を常に信頼し、常にそのような主張を評価しようとすることはお勧めしません。アルファ、ベータ、リリース候補など。

適切なドキュメントはありますか？

完璧なプロジェクトが提供するもの：

• 例が満載のユーザーガイド
• ライブラリの場合、統合/拡張ガイド
• APIドキュメント
• 完全に文書化されたソースコード
• パブリック問題トラッカー

開発者はまだプロジェクトにコミットしていますか？

もちろん、それが基盤/会社支援プロジェクトでない限り、開発者が将来コミットし続けるかどうかは決してわかりません。ただし、次のことを確認することで、ほぼいつでもコミットされているかどうかを確認できます。

• 最近のコミットアクティビティ
• 最近の機能（バグ修正だけでなく）
• 最近のドキュメント活動（ドキュメントの更新、ブログ投稿など）

また、プロジェクトの成熟度の良い指標は、最初のマイルストーンの後に関与したアクティブな開発者の第2世代です。

開発者は到達可能ですか？

• 彼らはバグに対応していますか？
• 一般的な問題トラッカー以外に、他の連絡手段を提供していますか？これはチェックリストの小さな項目ですが、単一の開発者プロジェクトでは、「行方不明の開発者のケース」のような場合に代替の連絡手段が役立ちます。

次に、より具体的な質問について：

速度

パブリック問題トラッカーを使用したプロジェクトでは、問題が解決するまでにどれくらい時間がかかるかを確認する必要があります。もちろん、速度は必ずしも品質を意味するわけではないので、おそらくクローズドな問題を経験し、重要だと思ういくつかを選択して、開発者の応答時間と品質を評価します。

ライセンスの互換性

法的問題に関しては、オープンソースプロジェクトの使用がライセンスと互換性があることを100％確信がない場合は、コードベースに絶対に統合しないでください。疑わしい場合は、プロジェクトの開発者にいつでも問い合わせることができます。また、ここで問い合わせることもできます。

コミュニティの誇大広告

常に誇大広告を評価する必要があります。仲間の開発者からの推奨事項は、ほとんどの場合、プロジェクトの成熟度を示す十分な指標です。

ライセンスの互換性を除き、チェックリストのすべての項目はオプションです。私は自分のコードに多くのデッドプロジェクトやドキュメント化されていないプロジェクトを統合しましたが、それは常にあなたの特定のニーズが何であるか、そしてあなた自身のコードがどのように進化するかによって異なります。

Yannis Rizosが述べた答えに加えて、可能であれば短いプロジェクトまたはテストプロジェクトで試してみました。これにより、重要なものが危険にさらされる前に、製品の癖に慣れることができます。プロジェクトは小さすぎてはいけません。コードベースの多くが未探索のままになるからです。試してみて、あまり手間をかけずにあなたが望むものをできるかどうか確かめてください。ドキュメントやプロジェクトコミュニティへの質問の助けを借りて自分で基本を理解できない場合は、より適切にサポートされているコードベースを検討することを検討してください。最初のテストで問題がなければ、実際に使用を開始できます。過去にこの問題に対処しなければなりませんでしたが、最初の2回は実稼働に移す前に新しいことをテストすることを自分のルールにしました。

BP賢明：新しいものを導入することは、何らかの形の準備/学習段階なしには決して行わないでください。