The Beginning of the End for Rubyforge

Jamis Buck is abandoning development of SQLite/Ruby, SQLite3/Ruby, Net::SSH and Capistrano. I do not say this derogatorily; Jamis owes us Capistrano like George R. R. Martin owes us A Dance with Dragons.

In the comments to that post, Dr Nic asked,

… were there ever “core contributors” who could be all added to the rubyforge project’s admin so they can start releasing new versions? Or did you ask all of them and no one said they’d take over the project?

Jamis replied:

“[T]here are no other core contributors. I tried once to create something like that, but no one else seemed to have the “passion” or “vision”. Lots of people submitting patches (many of them quite good!), but no one demonstrating a real, general desire to dig into the internals. That’s kind of why I left it like I did—there really wasn’t any heir-apparent that the keys could be left to.

“That said, if someone steps forward and seems to be getting community support (for any of the projects) behind them, I’ll be happy to give them admin access to the appropriate rubyforge pages.”

Rubyforge served a purpose for several years, and served it well. But Rubyforge is a bottleneck in the distribution of code, and this is exacerbated by the Ruby community’s reliance not only on RubyGems, but on the idea of the canonical, official version of a project. The increased popularity of distributed version control releases some of the pressue. GitHub has substantially reduced the friction involved in collaboration. Even so, the idea still holds that once a line of work is ready, you release it on Rubyforge, so that it’s official.

Good coders, even those not afflicted with a love of novelty, will eventually grow bored with their projects. The distribution model represented by Rubyforge cannot, or at least should not, long survive this human tendency.

Leave a comment



     /  February 25, 2009

    You’ve made a good case for the problem. Is there a solution? Is anyone working on anything to address the problems associated with centralized distribution of projects?

  2. Matthew King

     /  February 25, 2009

    I’m working on it, or at least worrying on it.Yesterday I joked with some colleagues on IRC that RubyGems should have an –im-feeling-lucky flag that installs the gem from the GitHub repo with the most recent commit. Listing off the reasons why that’s a bad idea is a good introduction to the problem.Other questions:What other criteria are important in determining which incarnation of a project one should use? How do we distinguish between forks and collaborations in the age of distributed version control?Some ideas:Only canonize the test suite. This still requires some Benevolent Dictatorship, but the duties will be less onerous.For GitHub, treat the fork network as a graph, not a tree. Find some way to determine which forks directly use commits from other forks. Allow each forker to set a “primary” node preference other than the repo they forked from.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: