JRuby is the latest, and possibly highest-profile open-source project, to migrate from SourceForge to Codehaus, where it joins its close cousin, fellow dynamic language on the JVM, Groovy. (Learn more about JRuby in the LinuxWorld interview published today.)
InfoQ asked JRuby leads Charles Nutter and Tom Enebo why they moved and their answers shed light on some of the recent problems plaguing SourceForge.
According to Charles, "SourceForge's downtime the week before JavaOne really burned me. CVS for both anon AND developers was completely down for several days right when we were trying to wrap up our changes for the conference. It took us a couple weeks to untangle what was good change and what was bad and get things settled down again."
Charles then added, "SourceForge is enormously big; we don't get the kind of support we need there. The Codehaus guys have been really helpful and responsive to problems", and most damning of all, "It was all downhill after the CVS downtimes. I don't care what great new servers they've got up; if the servers completely died once there's some serious mismanagement (or perhaps more likely, underfunding) going on and they're just treating a symptom."
Tom expounded on the CVS downtime, saying: "The developer downtime was right before JavaOne and was close to a week. The anonymous access was down around a month if I remember right."
Commenting on the reliability of SourceForge's offering, Tom added, "I was pretty shocked that SourceForge did not have high-availability for revision control (and seemingly had only one piece of hardware as a single point of failure somewhere in the chain). I made a bunch of assumptions about SourceForge that were not true and now my confidence in them has waned."
Charles also vented frustration about periodic outages plaguing SourceForge's mailing lists, which have been down for scheduled and unscheduled maintenance often lately. The move was more than just about reliability though, feature sets also proved to be a factor in the decision. Charles described SourceForge's bug tracker as "pretty primitive" whereas Codehaus offers a suite of tools including Confluence, Jira and Fisheye. Other differences? Codehaus allows project managers to set the structure and content of their project page, but SourceForge projects all have generic project homepages and no content authoring tools.
Charles and Tom were not entirely negative about SourceForge, and Tom expressed appreciation for the service along with some amount of regret that he was complaining about a free service. He told us, "I wish SF the best of luck. They provided a free place for us to host JRuby and they host many many many other projects. Hopefully, they have worked through their operational issues and also hopefully they continue to update their tools to provide a better service. It would truly be horrible if SourceForge went away since I think it would be tough to fill that gap in the near term."
A SourceForge representative told InfoQ that they are aware of the issues and working on improvements, but did not elaborate further.
Bob McWhirter, lead "despot" at Codehaus, expressed enthusiasm about the move and mentioned that Xircles, Codehaus' community management platform, is a Ruby on Rails application. That said, Codehaus is primarily for Java-related projects and the vast majority of open-source Ruby projects are hosted at RubyForge.
Community comments
Too bad they didn't consider CodePlex...
by Clinton Begin,
Re: Too bad they didn't consider CodePlex...
by Dan Diephouse,
Re: Too bad they didn't consider CodePlex...
by Clinton Begin,
Re: Too bad they didn't consider CodePlex...
by Charles Nutter,
Re: Too bad they didn't consider CodePlex...
by Korby Parnell,
Big Jumble of Parts
by Geoffrey Wiseman,
Jumble and such
by Bob McWhirter,
Too bad they didn't consider CodePlex...
by Clinton Begin,
Your message is awaiting moderation. Thank you for participating in the discussion.
Seriously, CodeHaus IMHO, is just a big jumble of disorganized parts. It's just a server with some software on it.
CodePlex would have been a nicer choice, since it has integrated components. And if they didn't like TFS as the source control, they could just separate out that one part (i.e. use a separate SVN server) and still use the rest of the integrated management tools (wiki, file releases, forums, issue tracking, team management, RSS aggregation and feeds...)
Too bad.
Re: Too bad they didn't consider CodePlex...
by Dan Diephouse,
Your message is awaiting moderation. Thank you for participating in the discussion.
Correction its just some servers with software on them. But so is Apache for that matter. Or Sourceforge. Whats your point? Are you saying everything should be a cohesive stack? Its a place to provide infrastructure for open source software, not a company. And its a damn good place. And if you haven't noticed, it has a good coomunity developers there as well. I believe that there are even some developers and projects from the company that you work for, ThoughtWorks!
Oh and its Codehaus, not CodeHaus :-).
Big Jumble of Parts
by Geoffrey Wiseman,
Your message is awaiting moderation. Thank you for participating in the discussion.
Really? I like that about Codehaus. They just select and use good tools, rather than trying to be everything to everyone. Confluence, Jira, Fisheye, SVN; these are tools that I'd choose to use on my own project. They integrate well enough for my taste. By comparison, the 'suite' offered by SF and CodePlex don't feel that much more integrated, but do feel less mature and less capable.
Jumble and such
by Bob McWhirter,
Your message is awaiting moderation. Thank you for participating in the discussion.
It's a jumble if you view it along the wrong axis. When viewed as a collection of things that caught Bob's interest for at least a few moments one day, it all makes sense. If you know me.
And I'm not a quote/unquote "despot". I truly am the despot of the Codehaus (no interCaps). I'm just a kinder gentler despot, who figures Darwinism is pretty effective, so I don't have to actively smite folks all that often.
Re: Too bad they didn't consider CodePlex...
by Charles Nutter,
Your message is awaiting moderation. Thank you for participating in the discussion.
Actually, I did consider CodePlex. I'm intrigued by the new Team Server stack, and I've suggested it to my employer as a complete solution for our rather disjointed config management plan. However there's a number of good reasons against CodePlex:
- CodePlex offers only the work item tracking and VCS capabilities of TFS, so it's not a full TFS stack.
- TFS is not free and we have never used it. We've used SVN and JIRA in the past.
- TFS Eclipse plugins are all either beta or non-free.
- CodePlex is extremely .NET-oriented; there are no Java projects hosted there I know of.
- CodePlex offers only Microsoft tools; Codehaus provides JIRA, Confluence, Fisheye, and a particular favorite of mine NetKit.
- CodePlex smells of marketing...TFS this and TFS that. I'm not really in the business of helping Microsoft sell software, even if it's great stuff.
In the end, Codehaus just represents a more appropriate community for JRuby. There are other JVM language projects there as well as some of the most compelling and impressive Java projects available today. We feel like we fit right in...and I don't think that would be the case at CodePlex.
Re: Too bad they didn't consider CodePlex...
by Korby Parnell,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'm happy that you found a new and more reliable home for your project, on CodeHaus. CodePlex isn't for everyone or every project. Neither are Sourceforge, Codehaus, or Collabnet. Recently, I had a chance to hang out with Vincent Massol at a mini-conference that we hosted for a group of uncustomers and sorta customers, here in Redmond. blogs.codehaus.org/people/vmassol/archives/0013... Vincent is a super-intelligent guy and he's passionate and knowledgeable about the needs, concerns, and desires of his customers.
At another conference recently, in Boston, I was talking with Eric Sink, the president of Sourcegear. We were reminiscing about the good ole days when he was rolling out Vault and I was blogging about VSS but working on VSTS behind the scenes. He shared a bit of wisdom with me that I think applies well to this situation. He said that he often advises potential customers to carefully evaluate multiple version control solutions, before buying his product, Vault. Why? Because he would much rather lose a few customers than create "customer terrorists" by convincing them to adopt a VCS solution that is a poor fit for their needs. It takes 2, 3, or even 4 satisfied customers to make up for the bad word of mouth that a totally unsatisfied customer can create.
WRT your comment that "CodePlex smells like marketing...", well, that stung enough that I felt compelled to write this long response. To be clear, I do not blame you for suspecting our motives with CodePlex. Microsoft is a big company. We make a lot of software and a lot money. It's natural to assume that there's a gob of money and marketing might behind every product, or a hidden angle. In many cases, that is true. In this case, I assure you, it's not.
I'm the closest thing to a dedicated "marketing" team that CodePlex has ever had. I'm one guy. I have no dedicated marketing budget that I know about. In fact, I'm shifting my focus from CodePlex to product planning on another project the non-CodePlex half of my team recently kicked off. CodePlex, like Codehaus I assume, has the luxury of relying upon the word of mouth marketing of great customer evangelists, like you and Clinton. True, I came to my new team from the Team Foundation team (where I wrote the command line documentation for TFS version control, a humble but interesting job ;-). However, there's no grand scheme to push VSTFS via CodePlex. VSTFS pushes itself. The CodePlex team is organizationally distinct from in no way related to or funded by the VSTS team. CodePlex project owners push CodePlex. We're on our own. Like any v1 product, our product integration and client set is bound to be limited. For now, we have prevailed upon my former team to release two TFS clients (Team Explorer and TF.exe)for free. In the future, there will be a wider array of free and not so free TFS clients that CodePlexers can use, including a couple for Eclipse.
Last, I'm honored that you considered CodePlex as a possible home for JRuby. Your observation that it is .NET-oriented, at this time, is accurate. Perhaps that will always be the case. However, I can assure you that we are determined to accomodate any and all projects, regardless of technology focus or platform. CodePlex is open in almost every sense of the word. We haven't open sourced our codebase yet but that's a discussion for another day. In the near future, you can expect to see increasing numbers of Ruby, Java, Mono, and other interesting projects on our site.
Great discussion! Have fun on Codehaus.
Korby Parnell
Product Manager
Microsoft.com Communities and Collaborative Development
Re: Too bad they didn't consider CodePlex...
by Clinton Begin,
Your message is awaiting moderation. Thank you for participating in the discussion.
>> But so is Apache for that matter
That's totally inaccurate. Apache is not about infrastructure. It's about community and largely the Apache License. Apache projects can host infrastructure anywhere if they want to, possibly even at CodePlex -- with the exception of source control (for legal reasons). For iBATIS Atlassian actually hosts our Confluence instance (for example).
That said, a really simple way to put it is this:
* I could recreate what Codehaus is in a week.
* Given a lifetime, I could not recreate what Apache is.
>> I believe that there are even some developers and projects
>> from the company that you work for, ThoughtWorks!
Yeah, it's amazing how us Fowlbots can have such different opinions eh? ;-)
Cheers,
Clinton