• Can we just have git, please?
• …oh, and bug tracking, too!
• Moving houses
• Don't forget the gems!
• The present
• The future?

Back when I wrote my 10 reasons to learn Ruby article, I mentioned RubyGems in Reason #1 as one of they key features of the Ruby programming languages.
Indeed, gems make getting Ruby programs as easy as typing gem install <something> from the command line. When you want to distribute something new in Ruby, there's no need to give people download links, zip files or setup programs, just tell them to get the gem. That's perfectly normal, and extremely cool.

Gems are normally stored on RubyForge, so all you have to do is uploading your gem there, and it will be available to the rest of the universe. It's a nice feeling. I remember when I first uploaded RawLine and then tried gem install rawline just for the hell of it: it downloaded and installed the gem, as expected.

Back in the day, if you wanted to find something written in Ruby, all you had to do is search through RubyForge, and you'd eventually find it, with a bit of luck.

Can we just have git, please? ⇈

RubyForge had, until recently, one major problem: it only allowed CVS and SVN repositories, and you had to make your choice when creating the project, once and for all. So when the cool guys at GitHub rolled out their social code hosting web site, most of the créme de la créme of RubyForge flocked there in mass migration: Rails, Merb, RSpec… you name it.
Once the big guys made the switch, a lot jumped on the GitHub bandwagon of course. Result: we have a lot of projects still on RubyForge, but quite a few (and important ones) on GitHub.

Why did people move there? Well, at first it was because they wanted a sleek-looking git host, and RubyForge didn't offer git at the time. But git is now available on RubyForge, so why don't people use it?
I'd like to know how many people use git on RubyForge. Apparently you can have your old SVN repository manually migrated to git, if you ask nicely (and RubyForge people are very helpful always, anyway). Still, I don't think many people use git there, and hardly anyone (if any) moved back from GitHub.

What's so special about this new “social code hosting” site then? I guess just a few key features:

• Fast and reliable git hosting
• The ability to “watch” other people's repositories and interact with them “the git way”, also by forking.
• There's a whole new and fresh community feeling to it: you can follow people, message them, etc.
• The interface is much more neat than RubyForge's (OK, granted, it doesn't take much)
• Really cool stats and graphs
• A basic, but functional, wiki

…oh, and bug tracking, too! ⇈

GitHub has no bug tracking features. It tracks an awful lot of stuff about your repositories and people working on them, but “batteries are sold separately”. You can get batteries here, for example. Apparently, GitHub and LightHouse are seamlessly integrated.

So now you can sign up to two cool brand new web applications with neat interfaces instead of sticking with the old-looking RubyForge (which comes with “batteries included”, after all).
Personally I'm very confused now. Fortunately I don't have any extremely cool projects used by thousands of people, so jumping from one source code hosting solution from another is not really an issue for me, but I imagine it would be for others! Correct?

So, as far as I know, if you are a Rubyist, here's what you can do:

1. Stick with RubyForge: it's not so bad after all.
2. Embrace GitHub (and Lighthouse): it's extremely nice to use. Some people are not too convinced that this is the best choice though.
3. Go for something in between, like Assembla, which actually has an impressive list of features and is powered by Rails too, so you'll feel at home. Google Code used to be another common choice, but sadly they don't offer git yet.
4. Do-it-yourself, maybe using something like Gitorius and some open source bug tracking/project management solution.

So… what choice did you make or are you planning to make?

Moving houses ⇈

There's one simple issue to consider when moving your code to a new place: what happens to your old place. If have a relatively popular project, a lot of people may have bookmarked your project page on RubyForge, or the RubyForge subdomain which you may have used as the “home page” for your project (in truth, most of the ones who moved away still use it).

You may setup a redirection to the new home page or put a notice saying that the project moved somewhere else and point visitors to GitHub and LightHouse, or to another web site, if you wish. When Rails moved to GitHub, that wasn't much of a problem as Rails has its own web site.

What may become a problem is your old repository. In Rails' case, they left the old SVN repository available on sourceforge for a while and then removed it altogether. Other project owners have just abandoned their old repositories, occasionally resulting in someone else deciding to leave a note as their last SVN commit.

These solutions all work (you eventually drive people to the new home of your project), but it's not very nice, that's all. What happens if someone comes up with something cooler than GitHub? In all honesty, you may end up moving house over and over again.

Don't forget the gems! ⇈

One thing I liked about RubyForge, as I wrote at the beginning, was that if you uploaded a gem there, it was immediately available to everyone typing gem install <something>.
Luckily, GitHub supports gems, too! We're saved. The page they put up is utterly awful, but it does the job: you can have your gems hosted on GitHub.

Good! So surely I can get Rails now, right? Yup: gem install rails will get the latest version of Rails for you, straight from GitHub.

Actually, no. It doesn't seem to work that way: sure you can get the latest rails in that way, but it will actually be downloaded from RubyForge (go check the downloads, you'll see it there).
So even if technically you got Rails, you got it from RubyForge. If you want to get gem from GitHub, you have to add it as gem source first (that's an una tantum operation, luckily): gem sources -a http://gems.github.com.

So, yes, you can move to GitHub and you'll also get gem support: but please remind the users that they have to add GitHub as gem source. Or, better, you should always remember to upload your latest gems to GitHub and to RubyForge as well.

The present ⇈

To sum up:

• If you want, you can stay on RubyForge. It has git, it has gems, it's probably not nearly as prettier than competitors and is not as social, but it works.
• You can opt for GitHub+LightHouse, have a slick interface, plenty of features and your project will be scattered in 2 different places + your home page, and you'll also have to keep uploading your gems to RubyForge.
• At this point, you may even go for something completely different, like Assembla or your own setup, but still upload your gems to RubyForge.

The obvious solutions at this point would be that the folks who craft rubygems (the gem which makes the gems, to be clear) add GitHub as default source. Sure as hell when that happens other people will want that too (hey, I'll have gems.h3rald.com setup by then!). Is this the future? I hope not.

The future? ⇈

You know there's a domain called www.rubygems.org? It's where the gem manuals are!
As much as I love documentation, there's nothing wrong in moving all those documents and books to something like docs.rubygems.org, right?
Then they could make RubyGems.org the only official gem server and tell people they should upload their gems there if they want to distribute them efficiently (after manual approval, if necessary, like there is on RubyForge).

In this way:

• You wouldn't have to upload stuff to RubyForge anymore
• You could have the clever folks at GitHub to create a simple script to automate the upload
• You'd have virtually all the gems in one place
• You'd put a good domain name (currently almost forgotten) to good use

While they are at it, the clever folks at RubyGems.org could also setup a proper gem directory with a proper search. I'm sure there would be plenty of people who could help, too!

It's not impossible, right? They said that making Rails/Ruby/RSpec documentation more accurate and accessible was impossible, but now there's APIdock, correct?

Personally I'd like it to be a collaborative effort of the Ruby community (like ruby-lang.org), rather than one private company showing off, but I think everyone will be happy as long as it works.
I'm sure people will contribute, I would try at least (after finishing the Italian translation of ruby-lang.org, that is… erhm, well, that's another story…).

Thoughts?