casperfabricius.com

In Denmark, this song is always put on TV just after the clock has struck midnight. On TV, it is a large girl’s choir performing, but I thought it was time for a change.

So here it is, my way of wishing you a fantastic 2008!

I’m currently working on a report comparing the Linux Kernel, KDE, Dokuwiki and Ruby on Rails in terms of how they work and perform as open source projects. We have collected data from the mailing lists, issue tracking systems and source control systems of each project (October 2006 – September 2007), and while I don’t have anything groundbreaking to report, I do have some food for thought for the Ruby on Rails community.

These four pies clearly show that Linux – not surprisingly – is the largest projects in terms of changesets (patches committed to the code base), messages (emails sent to the core mailing list) and individual senders (different people who has sent messages to the mailing list). But in that same year, almost twice as many issues (which is our neutral term for what is called tickets in Trac) has been opened in the Ruby on Rails Trac system as in the Linux Kernel Bugzilla system, despite the fact more than 10 ten time as many changes has been accepted into the Linux code base.

“Wait a minute!” you’ll probably object if you know a bit about how things roll in Linux-land, “they use mailing lists for that stuff on the Linux Kernel, so issues are only used by a few to report bugs.” And that’s absolutely true. The activity level of the Linux Kernel mailing list is more than 30 times the one on the Rails Core mailing list, and one out four messages either contain a patch or is directly related to one.

So okay, the Linux-community handles changes in one way, and the Rails-community in another – big deal, it seems to work out for both communities. Now, web-based issue tracking systems like Trac or Bugzilla are supposed to be the “new” way to manage open source projects, right? Linux is just stuck in the old mailing list workflow, but surely that must Linux much less efficient than Rails, because there is no overview of open issues and patches, no reports and no statistics? Well, not really.

The bar chart above shows the mean time to change for each of the projects. It is calculated as the average time span elapsing from an issue is opened in the issue tracking system till it is closed again. On average, it takes a patch 74 days to get into Linux code base and distributed as part of the worlds most popular operating system for servers. For Ruby on Rails, it “only” takes 54 days, so clearly the Rails-communities way of doing thing is more efficient. Or is it?

It is almost twice as fast to get a patch into the Dokuwiki code base as into the one of Rails. “Well, that’s a fairly small project with the creator also being the main contributor, so that’s not so strange” you might say in an attempt to defend your favourite open source community. Okay, but how about KDE? You can get a patch into the KDE core more than three times as fast. Now, to be fair, this is not the entire KDE suite of applications, but only the core of KDE, so most of the contributors has direct commit access themselves. But KDE and Dokuwiki aside, shouldn’t it still be faster than 54 days on average to a patch into the Ruby on Rails framework?

“Okay, so the average is 54 days, but that’s just because a few issues are left there like forever distorting the average” you might say. Well, first of all only issues that has been opened within the year and closed with a resolution if fixed is included the metric. Second, as the histogram above shows, around half of the issues are fixed within 12 days (the cumulative percentage is almost 50 at the first high bar, and that’s 12 days, not 24 as Excel insist on putting below the bar), but the other half takes close to forever to get closed.

So food for thought I said. I’m not pointing fingers at the Ruby on Rails community, of which I consider myself to be a part, only saying that we might want to think about if using Trac for everything and only having 12 people with commit rights is the best approach? Think about it, and if you have comments, critique, ideas, please do post them here so that we might use them in the final report.

PS: The period of time ends a short while after the whole Report #12 procedure was announced, so hey, that might fix everything …

Benjamin Quorning gave a great tip at the Copenhagen Ruby Brigade mailing list the other day: How to run (Windows) Internet Explorer on your (Intel-based) Mac without having to boot up Parallels, VMWare, or any other kind of time-consuming PC-emulation software. This is made possible by the IEs 4 Linux project (no, that’s no IE 4 on Linux, it’s IEs for Linux, and IE 4 is not supported, just 6, 5.5 and 5) which provides a simple way to run IE on Linux and, as it turns out, OS X on Intel-based Macs.

While the article on the IEs 4 Linux provides one method for getting this up and running, I tend to like Benjamin’s more as it uses MacPorts, so I’m going to repeat it here for reference. A prerequisite for the tutorial is to have X11 installed, which is part of the optional developer tools that comes with OS X, and you also need MacPorts, which seems to be the best package system for Darwin at the moment.

To install IEs4Linux and its dependencies, execute these commands in your terminal of choice:

sudo port install cabextract wget wine
wget http://www.tatanka.com.br/ies4linux/downloads/ies4linux-latest.tar.gz
tar zxvf ies4linux-latest.tar.gz
cd ies4linux-*
./ies4linux

The first line installs several components required to run IEs4Linux, most importantly Wine, a framework allowing many Windows applications to run on Unix-based systems, including OS X. The other lines download and start the impressively user-friendly installation of IEs4Linux. After completing the installation, Benjamin explains that to run Internet Explorer, you must startup the X11 console (/Applications/Utilities/X11.app) and execute these commands:

export PATH="/opt/local/bin:/opt/local/sbin:$PATH"
~/bin/ie6

That’s a bit too inconvenient for my taste, since want to be able to place a link to IE directly in my Dock, or run it by executing a simple command in Quicksilver. So I have created a shell script in my home directory (you could also place it in the Applications directory if you like that better) called ie6 with the following contents:

#!/bin/sh
open-x11 .ies4linux/bin/ie6

I also need to make it executable by running chmod +x ie6 in the terminal. Now this gives me the ability to execute the shell script from terminal, to call it from Quicksilver (by writing ie6), and to drag it to the right/lower part of the Dock (the part with the trash can in it) with an ugly generic document icon. I want it in my Dock with a nice high quality Internet Explorer icon so I can start just like any other application, and for that purpose I wrapped the shell script as an application:

Download IE6 application

• Requires IEs4Win to be installed in the default location (~/.ies4win)
• Must be dragged to the Applications directory in your home directory (create one if you don’t have one), not to the general Applications directory (this is due to my limited shell scripting / X11 abilities, ~ didn’t seem to work as a reference to the home directory in X11).