[crazydiamond]

I know you were trying to be satirical, gisikw, but you could have offered some suggestions or solutions. For example, I've often commented that I do not know whether a gem runs on 1.9 or 1.8. I have to test it out.

There are many many ruby projects on the rubyforge site that have never released code. They still exist after years! and they come up in searches. There are those that are obsolete, broken, or with not one line of documentation that one has to download, go through source code to figure out what it does, and if it does anything at all.

When a person comes in to ruby he needs a starting page on ruby-lang.org that tells him the popular gems or frameworks for major uses: such as CLI programs, web dev, scientific computing etc. What some call a list of "blessed" gems/projects.

However, we cannot criticize ruby if everyone is writing his own framework, parser, templating engine etc. Its also hard to be critical that so much documentation and tutorials online are outdated/broken due to the constant rate of change. Either devs are not updating tutorials/articles, or google is bringing up older documents first.

When we see a high download count for a gem that still does not indicate that people are using it. It only means people have downloaded it to check out. DOwnload counts are deceiving. Gems that offer a very sketchy description and have NO webpage often get a high download count since that's the only hope of figuring out what it does.

[gisikw]

My solution was simply to recommend personalized tutoring via RailsMentors.org - as you can really learn from any development stack. It's just finding the right combination that can be very difficult for a new developer.

You bring up some very good suggestions - we need a better metric for whether things are stable, supported, etc. And you're absolutely right, Google won't work, and download counts won't work. I would be interested in seeing something like you've suggested though, essentially coming up with a "trust" system for different libraries.

At the same time, you have the experience available to test whether a gem runs on 1.8 or 1.9, where a new developer doesn't know how to read stack traces yet. Providing one-on-one support helps tackle this issue (RailsMentors.org), as would increased tutorials that try and _limit_ the range of choice, rather than overload the developer with too much.

Of course, these are just my own thoughts on how we can address the problem. I'm hopeful that by discussing it, people can come up with some additional solutions.