Atalaya is currently hosted on SourceForge and, back when we were setting things up, it seemed perfectly reasonable to use the built-in SF tracker.
Now, after about an year of operations, it’s becoming evident that most of us find it cumbersome, at best. This wouldn’t be a problem by itself, if only it didn’t cause a slight resistance at the hour of using it; which is a problem instead.
Don’t get me wrong, I think SourceForge is a great place to be hosted on, and they have built an impressive infrastructure for OS projects. I love it.
The problem is that the interface is struggling. Slow to use, it feels like being in the 90s: it takes way to long for someone which is only moderately interested in reporting a bug to actually do it. From a maintanier point of view instead, it’s hard to get a bird’s eye view (does this rings you any bell?) over the overall status of the project (*).
Having seen or used a number of alternatives we have come up with a list of alternatives among which pick our new tracker. Being an OS project our requirements is just for it to be either OS itself, to be free to use by OS projects, or to provide an OS license. On the feature side a plus would be to be able to import our current ticket database from SF.
Currently our list is made of
Now, here goes a digression about each of them
JIRA
If you have seen it, and most of you are likely to have done so, you’ll agree that it’s massive. Powerful yet reasonably easy to operate. It’s a commercial product which provide an OS license which would do the job. Furthermore Atlassian is well respected among the OS community.
Also, it seems that it’s possible to import SF’s tracker backup into it, although it’s not an official feature. Nevermind, as long as it works.
Trac
An OS project, which I must say I haven’t used seriously. Nevertheless it has an important feature that doesn’t ship with JIRA, a code browser. I wonder why Atalassian doesn’t do something like that…ah no, they do indeed:)
Beside that it also provides a wiki, which we have already. We might consider migrating it as well but not at first.
On the downside the setup is more complex than for JIRA and it has some more restrictive requirements. Our server setup supports them but we might move to an hosted service which might not.
Launchpad
Ok, this is not really a fair comparison, as we should compare the whole SourceForge hosting with it, but for the sake of this post I’ll limit myself to their tracker.
First of all, it’s not an issue tracker, it’s a bug tracker. Launchpad supports feature tracking through a Blueprints section, which supports task tracking and workflows though. Ok, we don’t use workflows for our tickets here:)
The UI feels much like JIRA, I haven’t tested it if not for browsing others’ tickets. It has the big advantage for us of being an hosted instance.
Launchpad itself might need a post itself. I like their approach but I’d need to document a bit more over their vision, as if we’re moving I’d like for our new place to be still there in a few years time at least.
Roundup
You might have noticed that there is a notable absent in this list. I haven’t included Google’s code for various reasons. It’s strange to say this while being a GMail addict but I just don’t feel like hosting Atalaya on Google. I know they are already harvesting the same information but still. Call me paranoid.
I don’t think we’ll make a decision during this post. Here I’ve just aimed at writing down some pros and cons that I’ve found for each option.
(*) These arguments are in fact not limited to the tracker, similar arguments can be used for release management, but for the sake of this post I’ll just talk about this piece.

