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:
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:
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.