Introduction

I have been using trac now to run a software aintenance and development project for a public sector client for over 2 years now. I work in one of the big Danish providers of IT and it's an area where this kind of job is normally done either by leviathans like HP Quality Center or BMC Remedy, or that other popular software lifecycle management suite, Microsoft Office.

It's a little atypical to be using trac in this environment. It doesn't cost 6 digits and it doesn't require several gigabytes of disk space, which probably disqualifies it from serious consideration more often than one would hope or believe. As mentioned above, other more "enterprisey" systems are prevalent in this area.

I chose trac for several reasons. The big one is that I know trac has such a huge userbase and community that the risk of serious problems is virtually non-existent. I also know python; this makes tacking any issues more feasible. trac is quite light and runs happily on a laptop; a third reason.

The good

This won't come as a surprise to anyone who is used to working with open technology, but trac is a far better tool for managing software development than the horrors normally seen like HP and BMC's suites. The age-old approach of having tickets organised into releases is very stark and simple in trac; it probably exists also in more enterprisey software lifecycle systems, but they are so full of cruft, procedure, process, and over-engineering that this basic model of tickets and releases becomes ipractical to use because of all the administrative overhead.

The linking between wiki pages and ticket text fields (descriptions, comments, etc.) was seen as a form of black magic. It's really useful for linking designs to tickets.

trac's workflow capability is what I would call adequate. That is a compliment. It is capable enough that I could write a custom workflow which I found satisfying and included about 5-6 people in various roles, and it isn't so fancy that you need a doctorate to write a workflow. Yet, it is sophisticated enough that I was able to suck statistics out of the system summarising which people in which parts of the workflow were taking the longest to complete their bit.

The reporting facilities are like the workflow: certainly good enough. It isn't over-engineered, but you can reasonably quickly create a report answering about 95% of the information needs stakeholders might have of the technical side of software projects. A big perceived plus of using trac which isn't unique to trac is that - if used diligently - the reports it generates can be quite long especially if you tick the checkbox to show summaries underneath tickets in the listing page; this turned out to be a useful way to demonstrate progress and hard work to the demanding client who likely doesn't read it but appreciates 60 pages of documentation for work done.

If you're using the sqlite backend and the built-in http server then trac migration becomes trivial; given that the trac instance I was using moved twice, this is very useful.

trac out of the box is perfectly usable on most modern smartphones. This is a bit of a party trick sure, but party tricks generate more mileage than we like to admit.

The bad

The authentication and access features in vanilla trac are intentionally (I think) a bit spartan. I ended up using the account manager plugin naturally which relieves some of the pain. I have not tried the LDAP integration because LDAP is my personal nemesis; also because linking up to the corporate AD for authentication and access control is a task for less mortal nerds than I. As with all things LDAP, it probably works but I have prioritised my sanity over login convenience and have left that avenue unexplored.

The workflow has an initial unassigned state, "new" from where you have to manually accept a ticket into the system. This wouldn't be the biggest deal, but the fact that tickets by default are unassigned seems illogical.

The fact that an issue is called a "ticket" in trac created a stupid but minor problem: in a world used to BMC Remedy, "ticket" is a thing for service desks. I kid you not, the confusion in the beginning was monumental. I even wrote an ugly patch to make the naming of issues in trac configurable, but the patch sucked so I stuck with "ticket" and waited the confusion out.

One of the most popular reasons some people choose redmine over trac is that trac does not do multiple projects yet. I think another reason is that Ruby people - just like Java people - can't just use a system if it's in some other language; they have to reimplement it in Ruby. I digress; this should count against trac even if it didn't cause me any specific problems: lack of multiple project support in the same trac instance.

Conclusion

It works. It's more a reflection on proper issue tracking systems in general than trac in particular, but I'd hate to think what the last two years would have been like using a more traditional "enterprise-grade" system. Still, trac is just about the simplest example of what I consider a "proper issue tracker" which still does most of what I need, so let this count as a recommendation for trac.

Use trac if you're stuck on something expensive, proprietary, and crazy. If on the other hand you're on something like bugzilla, redmine, or jira then you might still like trac, but there's going to have to be a more specific reason for you to make the switch.

trac (or other choice of proper issue tracker) will be alien to the large bureaucracies specialising in change management and ITIL and such, but it will help drive development faster to release. Keep it on the periphery and you will get away with it.