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.