オープンソースプロジェクトが製品で使用できるほど成熟しているかどうかを知る方法は？

職場の製品に組み込みたいオープンソースプロジェクトがいくつかあります。私たちには、帯域幅も、専門知識もありません。Googleで検索してこれらを見つけました。私は、プロジェクトを利用する「主要なプレーヤー」を知りませんが、私が見ているものにかなり勇気づけられています。

今、私はjoe-blowのオープンソースプロジェクトを使用することでさらされているリスクの量について少し心配しています。そこから95％の距離が必要な場合、残りの5％は簡単に追加または修正できます。おそらく、それは重要なことです。

オープンソースプロジェクトが製品で使用できるほど成熟しているかどうかをどのように判断しますか？

これは趣味のプロジェクトではないため、安定性、保守性などが最重要です。

プロジェクトが私の要件に適合することを条件に、私が使用する基準：

1. 人々が支援を提供できる活発なコミュニティはありますか？
2. ライセンスは私の開発に適していますか？
3. 製品はまだ活発に開発されていますか？
4. 一般的に使用されているフレームワークですか？
5. 製品のレビュー/ブログ投稿/など、およびそれとの統合方法を見つけることができますか？

4と5は、あなたのプロジェクトのように思えるニッチなプロジェクトにはあまり役立ちません。

最も重要なことは、要件を満たしているかどうかです。もしそうだと思ったら、次にやるべきことは、プロジェクトをテストするためのハーネスを作成し、やりたいことをできるかどうかを確認することです。これにより、API（ライブラリの場合）とその動作の感覚が得られます。

1日の終わりに、あなたがしていることの90％を行うオープンソースがある場合は、それをフォークし、追加の機能を追加してコミュニティに返します。商用プロジェクトでこれをやったことがあります。

1. フレームワークについては、私は通常、多くの事前作成されたモジュールと大規模なコミュニティを持つ大規模で成熟したフレームワークのみを使用します。一般的に、あるフレームワークを他のフレームワークよりも選択しても、実際に自分のコードに費やす必要のある作業の量を大幅に減らすことはできません。総開発努力にほとんど違いはありません。ただし、一般的なフレームワークでは、事前に作成したモジュールをより多く利用できるため、通常はより多くの時間と労力を節約できます。
2. 小規模な非フレームワークライブラリの場合、通常、必要な場合は問題なく自分で変更を加えることができるため、通常はコミュニティを追加ボーナスとして考慮することを検討します。ほとんどの小さなライブラリは1人で管理されますが、自分で構築するよりも優れています。ただし、大規模なライブラリの場合、自分で簡単に変更を加えることができる可能性は低いため、成熟したアクティブなコミュニティとドキュメントが不可欠です。
3. ライセンスが不可欠です。一人用のライブラリの場合、ライブラリを変更する必要がある可能性が高いため、同意する条件でライセンスを許可することが不可欠です。

小さなライブラリの場合、フォークする必要があり、プロジェクトはすでに放棄されていると常に仮定する必要があります。これは通常、特にプロジェクトがGithubまたはBitBucketでホストされている場合、他の人のプロジェクトを愚かに簡単にフォークするため、問題にはなりません。小さなライブラリの場合、元のメンテナーがいなくなった場合や、行きたくない場所にプロジェクトの方向性をとる予定がある場合は、プロジェクトのメンテナンスをいつでも自分で引き継ぐことができます。

私はプロジェクトの活動にはあまり関心がなく、「完璧」という感覚を達成した成熟したライブラリは一般にバグ修正を行うだけでよいため、活動は遅くなりました。プロジェクトのアクティビティは、ライブラリに積極的に進化するターゲットが含まれる場合にのみ重要です。たとえば、外部サービスの進化に合わせて外部サービスのラッパーを絶えず更新する必要があるため、積極的な開発が不可欠ですが、数学ライブラリはあまり必要ありません必要なすべての機能を備えた新しい開発。

より大きなライブラリの場合、事態はより困難になります。引き継ぎははるかに複雑で、幸いなことに大規模なライブラリは一般的に成熟しているため、それほど速く移動しません。

@Samが彼の答えで言ったように、オープンソースライブラリを評価する上で最も重要なことは、それがあなたの要件にどの程度適合するかということです。ライセンスの問題が解決されたら、オープンソースライブラリを使用するのはめったに間違いではありません。事態が南に進んだ場合はいつでも分岐できるからです。

プロジェクトのバグトラッカーを見てください。多くの異なる人々によって提出された多くのチケットを見て、さまざまな人々からの返信もある場合、それは良い兆候です。バグチケットの増加==ユーザーコミュニティの拡大==本番で使用する準備ができている可能性が高くなります。

ニュースは良くないが、それはそれが間違っているという意味ではない：あなたは知らない。

本番環境に類似の実装があれば、それが実現可能であることはわかるでしょうが、あなたが言ったように、「主要なプレーヤー」はプロジェクトを使用しません。

あなたが社内で開発した場合、あなたは知っているでしょうが、あなたが言ったように、あなたはリソースを持っていません。

知りたいのは理にかなっていますが、そうではありません。

この答えが役立つことを願っています。なぜなら、あなたが依存しているが制御していない技術にプラグを引っ張るための緊急事態計画があるはずである...

質問は別の方法で入力する必要があります。あなたが本当に求めているのは、このオープンソースプロジェクトを使用して製品を開発する最良の方法ですか？

それには、問題のオープンソースプロジェクトだけでなく、他のオプションも含まれます。他の唯一のオプションがすべてを自分で書くことである場合、プロジェクトを変更するのに十分なコードであることが理解できるなら、プロジェクトを使用するほうがよいでしょう。

もちろん、プロジェクトが実行可能かどうかという疑問がもう1つあります。すなわち、オープンソースコードによって提供されることを期待する機能を修正または完了しなければならないリスクを含む努力を見積もる必要があります。プロジェクトが広く使用されていない場合は、そのためのコードを確認する必要があります。