Rubyforge, overshadowed by GitHub

Rubyforge is becoming increasingly outdated and less useful, thanks to GitHub. Rubyforge is mainly used as service for hoe/echoe and rubygems, not as a website or SCM. The days of manually uploading libraries or configuring a completely separate library to release your library (Hoe/Echoe) are over. Everything is starting to revolve around SCMs and become automatic.

Take Githubs gem resource. It’s extremely easy to use, you don’t have to do anything except commit your code, which you are already doing. They handle the rest.

Yes, I know you can add GitHub as a gem source, but this presents A LOT of problems and frankly I am very surprised that this feature was added considering the downfalls. Rubygems is not an OS package manager, nor do I think it ever should be. Ruby is all about keeping things simple and intuitive. Adding multiple gem sources, that aren’t structured the same, completely ruins that statement. If the naming scheme for sources is different, they don’t play nice with each other. Even the creators of github, rubyforge, and rubygems know this! So I’m lost as to why this was added in rubygems 1.2. They need to come up with a standard for naming gems that all channels must adhere to.

To many people, creating a rubygem and adding it to rubyforge is a daunting task. And i don’t blame them. Let’s compare GitHub vs RubyForge:

The process of adding your first gem on rubyforge:

1. Create a project and wait 3 days for it to get approved.
2. Read a tutorial on how to properly build a gem and submit it to rubyforge.
3. Realize that manually doing this is time consuming, so you need to use the Hoe library.
4. Realize that Hoe requires itself as a dependency and that you need to use Echoe.
5. Read a suggestion that states you should “register one project with RubyForge, then publish multiple gems to it”. This way you don’t have to wait for approval for every project.
6. Now read another suggestion that tells you to do the opposite.
7. Be confused and start thinking of ways to avoid rubyforge. Such as using github and then making a blog post about it.
8. Realize you have no choice and wait 3 days for the email of approval from rubyforge so you can add your project.

The process for adding your fist gem on GitHub:

1. Go into your project and check off that its a gem
2. Add a gemspec
3. Commit your code

Done! Github is the wave of the future when it comes to SCM and making your code available to the public. The missing piece of the puzzle for them is proper integration with rubygems. Right now it is not feasible to use github. But it can be with the following very simple changes:

1. Change the “rails-rails” naming scheme to use a separator not allowed in original gem names. Such as “/”.
2. Allow people to reserve gem names. Like “rails” instead of prefixing them with their username like “rails-rails”. But still making “rails-rails” available. This let’s people use forks of the project if they want, but also getting the “official” gem by only using it’s name. Also enforcing “rails” is reserved by the official “rails” project. This can easily be done with public information from RubyForge’s channel.

If GitHub makes those minor changes, I believe you would see a rush of gems being hosted on there and eventually it would be the preferred channel for getting your gems. Leaving RubyForge in the dust. Not that I want to see them in the dust, but if I could use github for everything, it just makes my life that much simpler.