I would still like to see a more social gem discovery system. I want to find all the popular gems, but neither gemcutter, rubyforge, nor github has a way to do this (past say the top 30-40 gems).
We'd be more than happy to set up a free account on our recommendations engine to track / recommend gems for folks. I think for the social discovery element of things to work though either gemcutter would need some sort of tracking element that it associated with clients that were pulling down gems (on the server side) or the gem client would need to communicate directly with the recommendations server. Hmm...
I don't know how useful this is, in the case of gems, but you can see the 30 (I think) most popular projects on github, based on number of forks or watchers:
That's where I got the idea from. I was really excited to see what the most popular projects on github were, but this is just the tip of the iceberg b/c they refuse to show the complete leaderboard breakdown.
* That the username-gemname thing from github disappears. I want to have one official gem. Genuine forks in the sense of people deciding to develop the project in a different direction should have to pick a new name.
This is great an all, but it's too bad they didn't just decide to do away with gems and everyone switch to rip.
But since they didn't, I'm glad they have decided to effectively move hosting to S3 (which is essentially what this change is about). There seems to be a tangible difference between the old hosting speed and s3's bandwidth (especially for people hosting their apps on EC2).
I love the ideas behind rip, but I think even Chris would say it's not quite ready to replace gems yet. For one thing, it depends on specific bash-isms.
One of the nice things about Rip is that it supports RubyGems so, to an extent, you can have your cake and eat it too. The collective investment Ruby developers have in Rubygems is pretty large, so if it gets replaced by something else, it's not going to happen overnight.
Definitely. I see Rip as a superset, of sorts, of Gems. That is, Rip is great for managing both Gems and in-development code, and doing so in swappable environments. Gems, on the other hand, tend to represent mostly mature code.
"We’ll be merging user accounts from RubyForge, so you’ll be able to log into RubyGems.org with your RubyForge login credentials. Your gem ownerships will also be transferred over."
I have gems and and an account on rubyforge.org. Do I get a say in this being replicated? Can I opt out?
Were people with accounts on rubyforge.org notified and asked about this? Maybe I missed the mail, but this is the first I'm hearing about it.
There may be no reason for me to care one way or another, but there's an off-putting aspect to all this that I can't quite put my finger on. It mostly feels like Yet Another Ruby Flavor of the Month, something quietly decided off someplace and then declared as The Way It Is.
That's no doubt unfair to people working on gemcutter, but at one time RAA was the way to go with code, then it was rubyforge.org, then gem hosting on GitHub was teh hawtness, but then suddenly it wasn't, but now we have gemcutter.
I liked the all around ease of github hosting, but with the gem option gone I'm now hosting my own gems, and see less and less reason to count on anyone else for that.
I'll probably now fetch whatever code I have on rubyforge (most of it quite old and near forgotten, with current code hosted elsewhere), delete the projects, and close the account.
Major props to Tom and gang, their efforts made a giant difference to the Ruby crowd, but centralized anything is less and less appealing to me.
I really like the Ruby community's willingness to embrace new platforms and evolve. (sorry, that sentence has way to many buzzwords).
The rubyforge guys need to be congratulated for willing to give up their role as the official gem hosters and not let their egos get in the way of progress that benefits the whole community.
