多分同じような記事を書いている人もいると思うし，そっちの方が僕の書いたものより良くまとまっていると思うけど，自分の考えを整理する上で書いておきます．
あと，別にRailsに限った話ではないです．
基本は，安定した保守・運用が可能であるかという軸と，本当にそのライブラリを使うべきか，の二つです．
安定した保守・運用が可能であるか
gemやcpan，pear等でインストール可能なOSSライブラリの多くは日曜プログラミングの成果だったり，どこかの組織のコードの一部分だったりします．なので，常に
- ある日を境にメンテされなくなる（Rails等のバージョンアップに追随しなくなる）
- ある日突然仕様変更でインターフェースがごっそり入れ替わる
というリスクがつきまといます．他にも最近のOracle
MySQL問題みたいに，企業がOSSプロジェクトを買い上げて囲い込んでしまうなんてリスクもあります．
この辺り，100%回避する手段は無いので，リスクを低減する方法はあります．
- githubなら，fork/watchされている数，commitの周期などを見て活発なプロジェクトであるかを確認する．活発なプロジェクトの場合，最悪元の開発者がサポートしなくなっても，forkから誰かがどうにかすることが期待できる．
- 「英語圏のサイトを」ぐぐってどれくらい利用されているかをチェックする．直近1年以内に記事があるか無いかで世の中的に使われているかどうかの判断基準の一つとなり得る
- ざっくりソースコードを眺めておき，いざというときに自分で不具合修正できるかどうかを確認しておく．不具合修正したらgithubの自分のforkで公開したり，pull request出すのが理想
メジャーなライブラリを使うことは非常に重要です．日本人が日本でしか使っていないオレオレライブラリを使うときは，常にリスクがあるので注意しましょう．一時期乱発されたPHPにおける国産Webアプリケーションフレームワークが良い例です．
# もちろんリスクを勘案した上で採用するのは問題無いです
本当にそのライブラリを使うべきか
Railsでdeviseを使ったことがある人は分かると思いますが，高機能，多機能なライブラリは使い方を覚えるのにそれなりの習熟期間を必要とします．ドキュメントがちゃんと書いてあるライブラリだとしても，大抵は英語だったりするので，英語を読む速度が遅い人にとっては負担になります（なので最低限の英語readingは必須スキル）．
元々そのライブラリにさせたかった機能（会員登録など）に立ち返り，本当にそのライブラリでないとできないのか，そのライブラリの習熟期間を加味しても速度・機能的メリットがあるのかを考えましょう．場合によっては時前実装の方が早く確実だったりします．
ただ，他人が素性良く書いたコードを読むというのは良い勉強になるので，上記リスクを恐れるあまりに何でもかんでもレガシーなライブラリやオレオレライブラリを使うのもまた良くないです．安全方面に倒しすぎると自分の成長の機会を逃してしまうことにもなってしまうので，バランスが大事です．
最後に，迷ったときは他の人にも相談するのが大事です．特に高機能なライブラリはサイトのコア機能に深く根ざす可能性があるので，慎重に選びましょう．最後は自分でケツを拭く覚悟で冒険するのがスキルアップのコツです．