How do you choose the right Ruby gem for your next project? [closed]

Question

Suppose you spent the last six months on a legacy system project, large corp obsolete web platform, integrating alien data structures.

Now you are finally off and you can go with a brand new startup project in Ruby.

The application will be built from scratch and is up to you to decide which gem you are going to use.

The question can be extended to the various aspects of building a brand new web application, but for semplicity, just suppose you need an authentication system.

Now, the last time you put in place that in Rails, was "authlogic" and it was so cool compared whith "authentication_fu", but while you where "in the cave" you just heard about several other way to authenticate, something like clearance, device, omniauth, warden, sorcery, twitter-auth, open_id_authentication and may others.

Even worst, suppose you can "just imagine" Ruby community is not sleeping and in six months, she was blowing up new ideas and paradigms about "authentication pattern" but you didn't find the time to be updated.

You just want to go outside there, having a look at what's going on, finding all the new gem arising and deciding what fill better your next project.

How do you do it ?

Thanks in advance Luca G. Soave

UPDATE Sep 18 10:36

Ruby toolbox compares gems in the same category by the metrics described - by Andrew Grimm

UPDATE Sep 17 02:09 

Several people tried to clarify the process to discover and choose the right Ruby gem for "the next brand new Ruby project". I'd like to summarize what I learned from everyone by listing what in my comprension are the main steps :

About the process of deciding between gems in the same field:

1. try a few of them yourself - by semperos

2. give them each a test drive, make sure there is heavy activity on github, watching last commits - by ealdent

3. choose the the Loosely Coupled Gems vs Monolitic Frameworks, giving priority to agile and fast implementation and continuous refactoring - by Craig Stuntz

4. getting expert of a gem/domain field, in order to be able to decide between gems - by james_schorr

5. don’t choose “WOW-things and Cool Fresh releases” for your production client projects, but test it daily on minor and private testing projets - by mikhailov

About the process to discover & choose the right gem, the last one by jeremiahd, is a deep, clear and very useful description of the process :

• search around for what seem like the most commonly installed libraries that cover my use case

• take a look at their documentation, to see how complete and readable it seems

• look at the activity in their community : updates - mailing lists - wiki - IRC - commits - mood

• look at their code : test suites - clean code - documents - useful comments -

• use their code

• quality of the community and code

• do it as a learning process, get a better programmer and give back to your community

  END UPDATE Sep 17 02:09

Feel free to add more, ... share your point of view.

Answer 1

What I do (when this problem rears it's head in any language) is I search around for what seem like the most commonly installed libraries that cover my use case. I then take a look at their documentation, to see how complete and readable it seems.

Next I look at the activity in their community -- are projects actively updated? Are there easily accessible mailing lists / a wiki/ IRC? How active are they? What's the general tone?

Next I look at their code. Are there test suites? Are they test suites that help me understand the library? Is the code clean? Documented? Commented usefully? Does it look like a ridiculous mess, or like it's had thought put into it at every point?

Next I use their code in a simplified, but similar, manner to how I actually need to use it. Did I run into any major stumbling blocks?

Screw flipping a coin and sticking with it. Sooner or later, whatever lib you're using isn't going to serve your needs, and you'll want to modify it's behavior. When that time comes, the quality of the community and the quality of the code are what make libraries stand out from one another.

This is, of course, a bit fuzzy. And it can be a challenging thing to do, but you'll be a better programmer for it, and assuming you do it enough, you'll probably be contributing back upstream to the libraries you use at some point, which is pretty awesome.