Lenz Grimmer's blog

This blog post is a by-product of my preparation work for an upcoming talk titled "Why you should be using a distributed version control system (DVCS) for your project" at SAPO Codebits in Lisbon (December 3-5, 2009). Publishing these thoughts prior to the conference serves two purposes: getting some peer review on my findings and acting as a teaser for the actual talk. So please let me know — did I cover the relevant aspects or did I miss anything? What's your take on DVCS vs. the centralized approach? Why do you prefer one over the other? I'm looking forward to your comments!

Even though there are several distributed alternatives available for some years now (with Bazaar, git and Mercurial being the most prominent representatives here), many large and popular Open Source projects still use centralized systems like Subversion or even CVS to maintain their source code. While Subversion has eased some of the pains of CVS (e.g. better remote access, renaming/moving of files and directories, easy branching), the centralized approach by itself poses some disadvantages compared to distributed systems. So what are these? Let me give you a few examples of the limitations that a centralized system like Subversion has and how these affect the possible workflows and development practices.

While Colin beat me in blogging about Project Kenai, I think I can still provide some additional background information about this new project hosting service from Sun.

If you are a maintainer of an Open Source project, you currently have plenty of choice when it comes to getting your project hosted for free. One criterion could be your software configuration management system (SCM) of choice.

Some of the hosting services that I am currently aware of and the choice of SCM they offer include:

• BitBucket (Mercurial)
• Collab.net (Subversion)
• github (Git)
• GoogleCode (Subversion)
• Launchpad (Bazaar)
• Sourceforge.net (CVS, Subversion)

As disclosed by Tim Bray some days ago, there now is another option - Kenai is open for project hosting (currently by invitation only)! In his blog post, he interviews Nick Sieger, one of the developers behind this project about their motivation and intentions:

We need to demonstrate credibility in building on top of more traditional LAMP/SAMP web stacks (not just Java EE); and we need to show viability of Sun technologies and hardware for next-generation web applications.

In a nutshell, Kenai is a platform for:

• Developer collaboration
• Communities of connected developers
• Integrated collaboration services stack

Some of the features that are currently available include:

• SCM services using Subversion and Mercurial
• Bug Tracking (Bugzilla)
• Forums
• Wikis
• Mailing Lists (using Sympa)

Reading the interview with Nick and looking at some presentations slides for RailsConf from Fernando Castano (a jRuby and Database performance engineer at Sun and another member of the project team),  I was able to gather a list of the tools and technologies they used to build Kenai:

• Apache2, mod_proxy_balancer
• Ruby on Rails (running on jRuby)
• Glassfish Java application server
• MySQL 5.0
• Apache Solr for search
• memcached

I found it interesting that they decided to deploy and run the Rails application as a war file within the Glassfish application server (using Warbler). By the way, the fabolous OpenSUSE Build Service is a Rails application, too! So far, the entire site is powered by a single MySQL instance with query cache enabled.

The project is hosted on the following infrastructure:

• Sun Fire T2000 for (for web and application serving)
• Sun Fire X4500 for Storage
• OpenSolaris Nevada (Zones/Containers, SMF)
• ZFS (9.7 TB RAIDz, Snapshots, NFS)
• Coolstack & Blastwave packages

You should check out Fernando's presentation for more technical details, tuning info and how they benchmarked the setup - it contains a number of useful tuning hints and performance graphs.

Last time I checked, 27 Projects have joined so far (e.g. jRuby, xVM Server). Kenai itself is developed on Kenai. It's going to be interesting what other projects will find their home there.

Nick also talked a bit about their future near term plans: to improve the usability and feature set, incrementally improve the site navigation and layout and adding support for hosting files/release downloads. They also consider offering Jira as an option to Bugzilla for bug tracking and Git as another SCM option.

There is an IRC channel #projectkenai on freenode.net, to get in touch with the developers directly. The mailing list for the Project Kenai site itself, is users@help.kenai.com - you can subscribe to this list here.