という質問を後輩から受けたので回答したのですが、口頭ということもあって、あまりまとまっていなかったと思うのと、自分のためにも雑ではありますが文章に書き起こしておこうと思います。

なお、今回の記述内容は個人的な判断基準でなおかつ業務で採用する場合で、個人開発では(一部を除いて)好き勝手やったらいいと思います。

参考にする情報


だいたい下記のあたりを参考にします。

  • 企業が開発しているかどうか
  • 組織で開発しているかどうか
  • オフィシャルかどうか
  • コントリビューターの数
  • コミット数
  • Star数
  • どこが使用しているのか
  • スポンサーがついているか
  • 検索時の情報量
    • 英語・日本語
  • PRが処理されているか
  • 公式ドキュメント
  • READMEやリリースノートが記述されているか
  • ライセンス

雑に順番に説明します。

企業が開発しているかどうか

どのOSSもメンテナが不足(&疲弊)している傾向にあると思われるので、最近はこれを優先するようにしてます。もちろん、これはこれでリスクはある[1]とはおもうのですが、個人的に今のところ次に挙げる項目と同じくらいの優先度です。

組織で開発しているかどうか、コントリビュータ数、コミット数

この辺りで開発が活発であるかどうかと、コミュニティが盤石かどうか判断します。コミット数が減っている理由は安定してきているなど良い方向に捉えることもできます。

個人的にはStar数が多いライブラリでも個人開発(あるいは極端に少人数に依存している)ライブラリは避けたほうがよい(個人開発の人には本当に申し訳ないんですが…)と思ってます。以前記事で書いたpredisなどはこのリスク(という言い方は悪いかもしれませんが)がもろに出ていると思います。もし、個人開発のライブラリである場合は、その人のGitHubのコミット量や他のライブラリのメンテ状況も参考にするようにしています。

難しい問題として、組織にそこそこの数のメンバーがいても実際に活動している人がどれくらいいるのかはなかなか解り辛いです。そもそもOSSのほとんどのライブラリでおそらくメンテナが圧倒的に不足しているとおもいます。

余談ですが、このあたりだけで判断するとwebpackとかも微妙なラインだと思いますが、実際選定する際はもちろんこれ以外の後述する要素も加味するべきです

後は、組織の場合リポジトリが複数存在するケースがほとんどなので、コアのリポジトリだけで判断するのでなく、他のリポジトリも参考にします。

オフィシャルかどうか

プラグインなどを採用する場合は、オフィシャルのものを優先するようにしています。特にコアな処理に近ければ近いほどそうします。多くの場合でオフィシャルかどうかでメンテの継続率が大きく違うように思えます。もし、オフィシャルでないものを採用する場合は前述のとおり、その人のGitHubコミット量やその他のライブラリのメンテ状況も参考にします。

ユーザと情報量

Starの数が多いと基本的にはそれだけ利用者数が多いので、採用するうえでの重要な判断要素になると思います。加えて利用者にビッグな企業がついていたりスポンサーがいると安心感がありますね。

これに加えてGoogle Trendやダウンロード数(npmやReleaseのダウンロード量)、後は検索結果とかを用いています。特に直近1年間とかでどれくらいの記事があるかやその内容を参考にします。また、この際に日本語だけでなく英語の検索結果も参考にします。これは日本語の情報がなくても英語で情報があれば、それなりに使用されており大丈夫であろうと判断するためにそうやってます。

これらの検索結果でそのライブラリ含めた周りの流行りの状況も雑に判断して、将来にわたって使えそうかも判断します。

PRが処理されているか

これは開発が活発かどうかと重複しますが、PRが処理されている(マージされているかどうかではない)とメンテナがみているというのはわかるので、そちらも確認します。個人的にIssueの処理状況はほとんど参考にしません。理由は後述します。

公式ドキュメントなど

公式ドキュメントがちゃんと記述されているかどうかというのは、そのコミュニティのマネジメントというか開発の強さ的な側面(適切な言葉が見当たらん)が出ていると思うので、ここがキッチリできているかどうかは結構重要なんじゃないかと思ってます。また、公式ドキュメント(のなかでも主にサンプル)で自分の用途を満たせるかどうかわかると思います。

READMEやリリースノートも同様です。この辺りがキッチリしていないと、特にBreaking Changeな変更が入ったときの追随が難しくなります。どうでもいいんですが、npmのライブラリは結構この辺り雑なのが多い印象で、もっとちゃんと書いてくれないかなぁ?といつも思います。

ライセンス

見落としがちですが、一番重要なところです。違反がないようにしないといけないんですが、専門家でもないのでなかなか難しい…。とにかく細心の注意を払うようにはしてます。

余談ですが、ライセンスに関してはminifyの時などにも削除しないようにするなどしないといけません。

逆に参考にしないもの


参考にしない情報についても少し書いておきたいと思います。

Issueの数

以前はIssueの数が多いと「放置されているので危ういのでは」と思っていたのですが、そこそこ開発が活発だったりメジャーなものでも大量に放置されていたりするので、PRが処理されているようであればIssueの数が多くても大丈夫だと思うようになりました。

Issueが放置される理由は個人的な予想である上にあんまり大きな声でいいにくいのですが、Issueの質が低いからだと思っています。いろんなリポジトリで結構な数でどうなのかとおもうようなIssueがいっぱい挙がってます。これらはだいたいリポジトリに関係ない内容か、調べたら解決可能であるなど、その他さまざまで、放置されるIssueはそういう傾向にあるのではないかと思います。もちろんメンテナが見る余裕がないというのもあると思います。

するべきみたいなタイトルの記事

(技術的なものに限った話ではないですが)バズを意識してつけられたと思わしきタイトルはだいたい9割かそれ以上くらいがポジショントークか、タイトルに見合うだけの内容が書かれていないので記事を開く必要すらないです。[2]

追記


そもそも、ライブラリの導入以前にその実装本当に要るんかどうかの検討が必要だと思います。特に細かいような機能であればライブラリ使ってまで実装する必要があるのかどうか。

余談


今までも何度か言及していますし、記事の初めの方にかいているんですが、最近はバックに(そこそこ大きい)企業がついている、あるいはそういった企業が開発しているものでないと(存続的観点で)先が危ういんじゃないかと思ってます。

あと、雑に書くとかいって文量多くなってしまった…。おわり。


  1. Facebookの時のライセンス的なやつとか ↩︎

  2. あとこういうの書く人はだいたいそういう傾向にあるのでそういう人物としてなにかしらの方法でフィルターすると平和になります。もちろん、そういうタイトルでちゃんとした内容のものもありますが、それらを初見で区別するのはムリです。 ↩︎