＃6：ドキュメントの整備状況は？
ドキュメントがほとんど整備されていないオープンソースプロジェクトもある。オープンソースプロジェクトを率いるソフトウェアエンジニアは製品の開発に集中するあまり、ドキュメントを後回しにすることがしばしばあるのである。製品には少なくともユーザーマニュアルと管理者用マニュアルが必要だ。こういったマニュアルはWikiによるオンライン形式や、チュートリアルとして提供される場合もある。もちろん、製品の普及度合いを見ることで、ドキュメントの品質をある程度推し量ることはできるものの、自社での使用形態に適したドキュメントが提供されているかどうかについて、必ず確認しておくべきだろう。
＃7：自社の要件に合致させるためのカスタマイズは容易に行えるか？
オープンソース製品はプロプライエタリな製品とは異なり、自社の要件に合わせてコードを自らでカスタマイズすることができる。しかし、カスタマイズのためのコストはシステムのアーキテクチャや拡張性、コードの美しさ、製品のAPIドキュメントの充実ぶりによって変わってくる。
優れたオープンソースプロジェクトはいずれも、製品のカスタマイズに利用できる、拡張可能なプラグインアーキテクチャを備えており、そのドキュメントも充実している。また通常の場合、こういったカスタマイズを有料で請け負うベンダーも存在しているはずである。しかしながら、複数の選択肢を用意しておく（可能であれば社内でのカスタマイズという選択肢も含めて）ことが重要である。さもなければ、オープンソースに移行してもベンダーのロックインから完全に脱却できたとは言えないはずだ。
＃8：該当プロジェクトではどういったガバナンス手法が採用されているか、そして製品のロードマップに影響を与えることがどの程度容易であるか？
オープンソースプロジェクトの運営方法や意志決定方法は、プロジェクトによってさまざまである。最善のガバナンスモデルは、利害関係者（開発者やユーザー、ベンダー）全員が透明度の高い意志決定プロセスに参加できるというものである。また、規模の大きなオープンソースプロジェクトであれば、適切な法的支援の提供や知的財産の的確な管理を担当する専門家集団の存在も重要なポイントとなる。最終的には、ユーザーとして開発者コミュニティーに参加し、影響を及ぼすことのできる度合いが高いほど、そのプロジェクトの自社ニーズに対する応答性も高くなるはずだ。
