A little while back, I described my search for a issue tracking tool to use on my personal projects. I think I’ve finally found one that I like in Collaboa. Collaboa is a simple, lightweight, and relatively easy to set-up issue tracker and Subversion repository viewer written with Ruby On Rails.
Collaboa has a lot of features that make it great for managing issues on smaller projects. The best feature is that it’s really simple. You only need to visit one screen to create an issue, give it a milestone, and assign it to someone. It’s the same screen to close it out. The same thing on our Jira install took about 3 page reloads and a couple flips between tabs. It really took a few minutes to create an issue in Jira, only a few second to do it Collaboa. It occasionally took longer to document the issue than it took to fix it. That’s just not a good use of anybody’s time.
In addition to repository browsing. Collaboa provides wiki-like syntax to linking tickets to changeset and vice-versa. No svn-hook magic and configuration required. Installation and configuration on a modern Linux distro is a breeze. The only problem I ran into was getting the Ruby-subversion bindings on Opensuse. However, this was solved simply by just compiling them myself. After that, it was as easy to get running as any other rails app.
Not surprisingly, Collaboa lacks some features that managment oriented people would like to have. There’s no support for Jira-style bulk changes in the interface. This is more minor than it would seem, since the interface is responsive and simple. Also unlike Jira, Collaboa, doesn’t feature hundreds of different reports, pretty charts and time tracking.
On the other hand Collaboa, is completely open source, and Ruby based so if there’s a feature that you just really need, you’re just some programmer time from having it. A cursory look shows the code is clean and pretty standard Rails. Adding new features should be straight forward.
There’s a lot to like about Collaboa, especially for smaller in-house teams and open source projects. A lot of the extra features that more prevalent products, like Jira, have are unneeded cruft in these cases. If the team has a core competency in Rails, then it becomes an even easier choice.
