Slashdot Mirror


Ticket Tracking and Customer Management?

An anonymous reader writes "Like many Slashdot readers, I'm sure, I run a small side business doing IT consulting in addition to my day job. I'm looking for a good open-source ticket tracking system that I can run under Linux, preferably one that also has some customer management features. I'd like to be able to maintain a separate record for each job, along with time tracking, work logs, and information about the customer. Much of what I see on Sourceforge is, as usual, pre-pre-pre-alpha with no actual code. Does anyone have any suggestions for a project that might fit my needs?"

3 of 236 comments (clear)

  1. Eventum by Lordrashmi · · Score: 4, Interesting

    A bit of shameless self promotion (since I am the lead developer), check out Eventum.

    It might not be the perfect fit for you, but it is stable and customizable. Right now it is lacking built in customer management features, instead it relies on a Customer API to integrate with other systems. Right now I am working on integration with Sugar CRM but do not yet have an ETA on when it will be released.

  2. Re:RT For sure by yarbel · · Score: 4, Interesting

    RT does not scale well at all however. We have had to make major modifications to the source in order to support 200,000+ tickets.

  3. Re:RT by zeath · · Score: 4, Interesting

    When researching a ticket tracking system to implement at my workplace I came with no experience in any non-proprietary system. I compared RT and trac side-by-side and found trac to be much more readable and user-friendly. Even for me, when setting it up, I spent an entire day trying to make heads or tails of the RT interface, while in a day I already had trac up and running and I was showing others how to log in and use it. Now that it is in production, what surprises me the most is the ease with which the non-IT department managers use it for tracking their tickets and project progress.

    The irony of the situation is that I do specialize in Perl, which is why I went toward RT first. I assumed it would have been the better choice for making any changes to the underlying system, but in the process of working with trac I've learned Python enough to hack together a number of custom solutions for our needs.

    Since I didn't go any further with RT after that first day, I can't say how well that would have worked, but in my case RT did leave a bad taste in my mouth.