RubyForge on Rails

Since I've been doing a lot of Rails lately, I've been talking with Rich Kilmer and Ryan Owens about porting RubyForge to Rails.  Right now RubyForge runs on a somewhat customized version of GForge.  Some noodlings on what a rewrite would involve:

• One cost would be that we would have our own codebase that we'd then have to support.  And one benefit is that we'd have our own codebase that we'd then be more able to support :-)  The performance would probably be about the same; the current site is pretty snappy. 
• We're currently running GForge 4.0.2.  It would make sense to upgrade to the newest release (4.5.x or even 4.6 beta) in case anyone other GForge users wanted to follow suit.
• We could probably port to Rails by doing an ActiveRecord model on the existing schema.  Doing an AR model first would let us do some of the peripheral parts - like the RSS feeds and the cronjobs and such - without affecting the core code.
• This would take a fair bit of effort, and a lot of the work would be stuff that I'm not good at - user interface, layouts, CSS.   Maybe we could make the job simpler by just supporting one theme and then re-adding the other themes as we had time.  Ryan could do this stuff better than I, but it'd be in his spare time, which is already in high demand.

A rewrite would mean a lot of work in people's spare time and no one would see any initial benefit.  But it make it easier for us to add more AJAXy niftiness and other features as needed.   But also.... it would probably be fun.  That might tip the balance :-)

Comments

[Joseph Method]

What if something could be done with Retrospectiva? This is a great Rails Trac clone that already has most of the features a project needs.

[Ashley Moran]

I may be misattributing and I'm certainly paraphrasing badly, but I think Eric Evans said you when you rewrite it's for insight. There's no better way to find out what a project really needs than building one. Then you realise there was a better way so you rewrite it again...

I don't think he mentioned fun anywhere in there, but anything useful AND fun has gotta be worth considering.

[Ken Wronkiewicz]

I would tend to think that a RubyForge on Rails would be only worth it if it could bring some real change to the "GForge/SourceForge/etc" model.

Like... could one re-invent the "open source project page" software in some sort of fundamentally *different* and *ruby/rails* sort of way, given that we all kinda think different.

[Daniel Berger]

I've mentioned in the past that you might want to use Redmine and customize it as needed, instead of starting from scratch.

http://redmine.rubyforge.org/ :)

Regards,

Dan

[Jason L Perry]

When my team posed the question this summer about a possible "RailsForge" a lot of people cried out for a better RubyForge.

Our vision for "RailsForge" (I keep using quotes because we've abandoned that name for the project) doesn't have a lot of overlap with
RubyForge, and is pretty much just complimentary. We've been working on other things, so progress on that is slowed. I'm not sure what I'm rambling on about here... but, I am definitely on board to get involved improving RubyForge!

[Evan]

Don't forget that tools like Hoe are designed to work with GForge, so replacing it will require maintenance by their authors too.

IMO it's probably not worth it. There are some features in the latest GForge that would be nice to have though.

[Geoffrey Grosenbach]

While this could be a benefit to the community, it would be a lot of work. GForge was developed and enhanced by many people over the course of several years.

I think we would need to have a specific list of reasons why RubyForge/GForge is insufficient before we start this project.

I would also suggest narrowing down the feature set to keep it manageable. For example, there are many free wikis, public mailing list providers, and even source code hosters. Could we afford to narrow down the set of features offered by RubyForge?

I think it would take at least a team of 4-6 people to implement it, and they would have to be very dedicated to the project. There would need to be a project manager and an architect who guides the project and makes the tough decisions. Maybe the new RubyCentral grant program could even be involved to enable a few people to take off work and dedicate a few months to the project.

RubyForge/GForge may have some shortcomings, but it works. What are the real problems that justify such an extensive project?

[shingara]

Why doesn't start with an existing project of Management project hosted by Rubyforge, like redmine or retrospectiva ?

[Bill Davenport]

Tom,

I've been thinking about your idea. I'm all for doing things better if they meet your needs.

Would re-writing the site help align the goals of the site with the Rubyforge's vision? I see a lot of cool RoR sites out there doing amazing things with SVN [http://www.roundhaus.com], ticket tracking [http://www.rousette.org.uk/projects/] and even an online coding site for Rails[http://heroku.com/].

Thanks, Bill

[tomcopeland]

All - sorry, the "new comment" notifications from TypePad were getting lost somehow, so I only approved these comments just today. Doh!

Ashley - quite right!

Joe, Daniel, shingara - yup, there are existing frameworks; the tricky bit there is doing the data migration.

Geoffrey - yup, it'd be a lot of work and could take quite a while. As you say, narrowing down the feature list would help - e.g., is anyone really using the "skills" stuff on RubyForge?

Bill - Yeah, it'd be nice to have RubyForge in Rails... as other folks pointed out, it'd be quite a bit of work, though. It's a tough one.

Evan - Yup, those screenscrapers would be broken. We'd need to work together to get things going. Perhaps that'd be a good thing, though, as maybe we could do up a real API for doing releases and whatnot. As you say, it might be good to upgrade to the latest GForge at the very least.

Jason - Yeah, the tricky bit here is the data migration. GForge has around 150 tables... ack.