I previously told you we moved from Trac to Redmine for project management (issue/ticket tracking, milestones, source control management). In this post i will tell you what i like about Redmine and compare it to our previous Trac setup.

From what i understand from the Trac mailing list & some discussions in some of the ticket comments (by core developers) the main goal of  Trac is to create a stable (and basic) system (or groundlayer) that can be extended by using plugins. Thats a great mission statement…But (and there is a but) if you are managing several Trac installations this vision turns against you rather quickly, below some of the main things i miss in Trac.

Multiple Projects

The initial reason for moving to Redmine was the lack of support for multiple projects in Trac. I know you can hack Trac (see track-hacks) to include multi-project support, but i don’t like hacking. There were several discussions how (and if) Trac should implement multi-project support fact is : there is no “out-of-the-box” solution. I read something about Trac v2.0 supporting this, so i guess we’ll see that in 2015 then..

Redmine does support multiple projects. The integration throughout the entire system is excellent. You can create nested subprojects and move issues/tickets from one project to another. For each project you are able to assign different users and turn certain functionality (milestones, time tracking, source control,..) on and off.

Batch Issue/Ticket editing

I have to agree Trac ticketing system is very powerful and flexible. Without a doubt Trac is one of the most common and stable tools for project management & issue tracking for a very good reason. You can easily search and filter tickets by severity, project component, version or owner, and then store those. Great.

What i really miss using Trac is the ability to do a “mass update” (edit/close/move) on several tickets at the same time. This is where the ajax powered “batch edit” feature of Redmine comes in quite handy.

User / Role Management

The user management in Redmine is great ! Besides normal user management it supports (custom) roles. You are able to set different user roles for different projects.

Trac doesn’t support “user management” out-of-the-box. Unlike other bug-tracking systems that simply have a table for storing the users, Trac took the approach of allowing users to leverage the numerous authentication modules available for their web server. This means system administrators are able to hook Trac into something like LDAP, Active Directory, or whatever centralized user system that they already have in place.

So which one is better ?  Difficult question. I am a great supporter of working software out of the box. Not too much configuration, easy to install. This doesn’t mean the software has to be “simple” : flexible and easy-to-configure can go along hand in  hand. That being said i think Redmine took the best approach in having good user management right after installation. If you need something more centralized they still have LDAP support.

A lot of updates/ new features

I am sure Trac is more stable then Redmine. So if you need a stable product, use Trac But as we are a small webdesign company, the stability of the development environment isn’t really that critical to us.

What i am looking for in project management software are new features/idea’s to improve the way our team is working together. I keep an eye on the Redmine timeline/activity to see how other people are using the Redmine platform. Some of their comments/ideas inspire us to change the way we are working or start using a specific feature we haven’t paid attention to.

Anything else ?

Yes, there are some things Trac does alot better. First of all Trac has a large community with multiple core developers, redmine is built around one (maybe a few) persons. Then the source repository browser in Trac is alot more powerful and intuitive.

I have been using Trac for along time now and i have a great deal of respect for all the guys that are working on this rocksolid project. But as i said before, Trac’s strengths is also it’s weakness. By trying to keep the system as lightweight as possible, discussions about possible features mostly result in the “not for core” decision.