Trackers - a Rough Overview

I've been asked to compare various issue trackers. While I don't really feel qualified do to so, I have an opinion nonetheless. So here are my two cents about it:

  • There are trackers for various use cases, various technologies, and licenses (eg. Jira is imho mostly commercial software).

  • I've not yet found a package which is equally suitable for handling customer (self-?) support tasks outside of software development, and software development tasks.

  • I don't have real experience with Jira, and only a very cursory impression about eg. OTRS (Perl) and Mantis (PHP).

  • From all trackers I have seen so far, OTRS, RT (Perl) and roundup (Python) are basically suitable to customer support tasks, but less suitable to software development tasks.

  • OTOH, Trac and Redmine seem to support software development tasks much better (and Redmine, written with RoR, much better than Trac, written in Python, imho).

For me, so far only Roundup and RT mattered for the customer-support space, but I intend to take a look at OTRS, now that they claim to support ITIL-conformant processes (whatever that means, but it's a requirement of some potential customers). When I talk about RT, I mean RT 3.x, not RT 4.x. I also ignore all PHP stuff for principal reasons.

  • Roundup's advantage, compared to RT, is that it is very lightweight.

  • Roundup's permission system seems to be more flexible than RT's, but all-in-all, changing anything requires rolling out a new revision of the installation (eg. to include the new permissions). This stuff is highly intertwined with the rest of roundup, and I've yet to see (didn't try) how to eg. migrate the database from one version of the software to the next.

  • RT's advantage is the much larger functionality out of the box, and esp. support for distributed workflows, with auto-escalation, re-assignment, hierarchical tickets with dependencies, statistics, multiple external authentication sources and what-not. It's much more heavy-weight, though, and the UI is clumsier, too. RT can be scripted, and the scripts seem to end up in the database, making it comparatively easy to migrate an instance. It's Perl, though, and the main author(s) are afaik on the forefront of Perl development themselves, so you frequently find that you have to pull in brand-new versions of modules from CPAN that you've never heard of, and that have had little exposure.

  • OOTB, RT's permission system is much more powerful than what is distributed with Roundup, though.

  • Roundup seems to be much more geared towards a "one customer project, one tracker" situation, where eg. general access control is of not very high importance.

In the software development space, integrating a tracker, a wiki, and a repository browser was popularized probably by SourceForge, and has led to the creation of packages like Trac and Redmine, the latter allegedly being a clone of Trac (imho it isn't, if you run the two side-by-side).

  • Roundup has no integration with either a wiki or a repository browser out of the box, so one would have to do manual work to use it in that manner. One also has to find suitable wiki and repository browser software to integrate with, first, and except for the wiki (MoinMoin), there are imho no obvious candidates.

  • Of the remaining two, Redmine imho has much better support for multi-project scenarios, seems to support a broader range of databases, and also provides much more functionality.

  • It can also be much easier extended by Joe Average User because of a plethora of plugins, supporting popular use cases.

  • Redmine appears to be easier to host than Roundup, using thin.

Links:

Comments