Things to keep from RubyForge

Executive summary: File uploads, mailing lists, and virtual hosts

Everyone knows that the RubyForge gem index is getting merged into the GemCutter gem index to form a single massive community gem index at rubygems.org. That leaves open the question of what happens to the other RubyForge services. We've been saying that most of the RubyForge services - the ones others can do better - are going away as we move towards the community hub concept that Rich outlined.

So, which RubyForge stuff do we keep? Based on feedback and further discussion, here are the services which are making the cut:

• mailing lists : these seem to be popular and alternatives seem to be not so good
• file uploads : these can be done elsewhere, but it seems like keeping them with the projects is worthwhile
• virtual hosts : these provide Ruby projects with a convenient place to have a home page
• projects: since we need something off of which to hang the other features

These features will be part of the new community hub, albeit in a much-improved format. Stay tuned... and comments welcome!

Comments

[Chad Fowler]

I think, aside from what you mention here, RubyForge has always been a kind of implicit social network. That's where "projects" comes into play. To that end, it's also a useful registry of what's happening in the Ruby world. Projects and their memberships are an example of that. I think of the future RubyForge as being a slimmed down interface to the features above plus a kind of RAA on steroids. A metadata repository.

[Shawn Anderson]

Chad, that may be the case, but you'd have to admit that other sites such as github do a far better job of allowing for the "implicit social network" aspects via project watchlists, ease of forking/merging etc.

[John Athayde]

If we're pushing these things out to other services, we should be able to talk to those services via APIs and link them together. Not that you would do these things through RubyForge, but that on the page there's one central locaiton that's easy to see what's happening in regards to a project.

[Chad Fowler]

Shawn, you're right that they probably do a better job of "implicit" by virtue of the kinds of activities that happen there. But I don't think that means that what RubyForge does or might do is not valuable. Also, I continue to value the idea of a project with members in addition to the implicit "membership" created by patches and forks. And projects with multiple products (for lack of a better term).

John, indeed.

[Nick Quaranto]

I'd be interested in first gathering some usage statistics on projects that were still going on at RubyForge and determine the features from that data.

Honestly, in 2 years of doing Ruby and Rails, I haven't seen any major projects that have been started and continue to gain traction stay in RubyForge. Please prove me wrong here :) Perhaps I'm a product of the GitHub era in that regard.

From what I can tell right now, it seems like the most popular projects that use RubyForge still are RubyGems and the Windows Ruby Installer.

[Tom Copeland]

@nick, yup, I agree, github is the place to do code these days; it does code stuff infinitely better than RubyForge does. I'd agree that RubyForge hasn't been the go-to place for new projects for at least a year or more. I think what we're doing now is extracting anything that does have value and moving it off an old and crufty platform.

Stat-wise, right now there are 50-60 new files released each day. It may well be that once the gem index moves off RubyForge (two weeks!) then other activity will drop to zero, though. For lists, hm, let me try to do some Mailman data mining. For virtual hosts, we aggregate the Apache logs... I could possibly split those up and get some activity stats there. And everything else will just go away.

[Aaron Patterson]

Any chance we can keep SCM repositories? I enjoy github, but at the same time, I like to mirror my code to servers controlled by a non-profit.

[Kieran P]

Github provides pages functionality for projects (which works quite well), and a downloads section for uploads. The only thing they lack is a mailing list, which google groups take care of just fine.

Save yourself time and money, make the whole of ruby forge read only, and have people move over to these newer, improved services.

[Tom Copeland]

@kieran, I had kind of thought about lists that way as well, although there's this http://ejohn.org/blog/google-groups-is-dead/. And also there's the pain of migration. It's a tricky decision.

Anyhow, as these comments show, there's a valid debate about what to take and what to leave.

[Eric]

Thank you very much Tom!

[Daniel]

As a user, I'd like to see the documentation at the same place where I can get the gem.

Please feel free to implement my spec ...

The way I see it is that gems and docs are likely to be used together. As nice as it is to be able to one shop stop for the gems, it would be equally good to have one central place for (most) ruby library documentation. If I'd like to contribute or hack, I'm more likely willing to put the effort into finding the home of the code than if I just wan't to use it.

Would it be possible and feasible to have gem publishing also mean automatic-if-it-exists rdoc-publising?

[Nick Quaranto]

@Daniel: We're working with the guys from rdoc.info on getting integration with Gemcutter baked in. Also, we're hoping for some metric_fu loving from the devver.net guys with Caliper. :)