免許
残念ながら、大企業は通常、GPL / LGPLおよびその他のライセンスを明示的に禁止しています。 この禁止は通常、知的財産と特許の部門から来ており、それを克服することはほとんど不可能です。 場合によっては、デュアルライセンス（GPL / LGPLおよび商用の有料ライセンス）がソリューションになる場合がありますが、多くの場合、別のオプションを探す方が簡単です。
お金
ガレージのスタートアップであろうと巨大企業であろうと関係ありません-時は金なりです。 開発者に、同じ機能をゼロから作成する場合と比較して、新しいライブラリを統合するのにかかる時間を把握するよう依頼してください。
代替案
開発者に、提案されたコンポーネントの少なくとも2つの選択肢と、その長所/短所の分析を要求します。 各機能について3つの異なるライブラリを知っている人はほとんどいないため、これにより人々は互いに通信できます。 このコミュニケーションの過程で、以前のプロジェクトからいくつかのことが発見されたり、より好ましい代替案が提示されたりします。
コミュニティ
このコンポーネントの開発者のコミュニティがどれだけ活発であるかを確認してください。 これが大企業または人気のあるオープンソースプロジェクトである場合は、それに特化したブログやその他の出版物を探し、日付を調べてください。 これは、ユーザーと開発者の両方にとってライブラリまたはコンポーネントがいかに興味深いか、そして彼らがどのように開発しているかを理解するのに役立ちます。
サポート
前の段落を続けると、公式サポート（無料と有料の両方）があります。 コンポーネントの統合でも、コンパイルせずにいくつかのトリッキーなスクリプトを実行するのにどのバージョンのPythonが必要なのかを戸惑うのではなく、数時間のサポートで作成者の1人に100〜200ドルを支払う方が簡単です。
コード
オープンソースの場合-コードを見て、少なくとも単純な静的アナライザーでチェックしてください。 コードが読めない場合、構造が悪い場合、コメントがない場合、またはアナライザーが複数の問題を誓う場合、すぐに拒否することをお勧めします。
同じ段階で、コードの可用性が一般的にチェックされます-GitHubにある場合、大学のホームページでは完全に異なります。
何かを追加する場合は、そのソースコードをすべて保存し、ビルドされてこれらのソースコードから機能することを確認します。 5つの互換性のないフォークを備えた.NETのライブラリを知っていて、それらのバージョン番号は同じです。
責任者
追加されたコードの責任者とその方法は？ これは、それを追加した特定の人、彼のスクラムチーム全体、救急車勤務チーム、または他の誰かかもしれません-しかし、他の開発者のマシンでコードの統合、テスト、またはその後の更新で「何かがうまくいかない」場合、誰に連絡するかを知っておいてください。
設計とドキュメント
各コンポーネントまたはライブラリについて、その使用に関する基本的な合意を説明する少なくとも1ページのドキュメントが必要です。 これが何らかの種類のフレームワークではない場合、「ラッパー」以外のデータ型の使用を明示的に禁止すると便利です。 たとえば、HTTPクライアントは戻りステータスの定数を定義するのが好きです。アプリケーションのロジックで「そのまま」使用する場合、ライブラリを変更するときにクラスの束を変更する必要があります。
技術文書と期限
多くの企業は、各ライブラリがIPおよび特許部門によってチェックされ、セキュリティコードアナライザーによってスキャンされることを必要としています。その後、正式な使用許可が発行されます。 それらのいくつかは人気のあるコンポーネントのアーカイブを持っています-しかし、原則として特定のバージョンのみがそれらに保存されます。 また、一部のライセンスでは、適切なライブラリを使用しているという事実を製品ドキュメントに示す必要があります。一部のライセンスでは、そのようなリンクを禁止しています。
何らかの方法-それをすべて振り落とすにはかなりの時間がかかる可能性があるため、リリースが鼻にかかっている場合は、間に合うように保証される新しいコンポーネントを追加する期限を導入することをお勧めします。
このチェックリストが、情報に基づいた決定を下し、本当に意味のある場合にのみ「車輪の再発明」に役立つことを願っています。