Helpdesk Software Beaten with An Ugly Stick
(Background - I'm writing some ticketing software and am comparing my stuff to other packages.)
I looked at Request Tracker (RT) and Cerberus Helpdesk. Both are Linux-based and can be downloaded (in slightly crippled form) for free. Both can be hooked up to email such that an email gets filtered and routed to the appropriate queue and processed. Cerberus also has the advantage of spam filtering, it claims.
RT looks fairly easy to setup and with few dependencies, but it's interface is really, really ugly and sort of confusing. Most of the code is probably only built by one person (I would reason to bet), and I think this person needs to go to some sort of application beauty school, sad to say. The application looks like it's been beaten with an ugly stick.
Cerberus Helpdesk. This looks like a spaghetti code nightmare. It's got like every feature in the book thrown in there (and perhaps missing some critical ones that exist in many higher end products). The app also tries to come off as being this good looking app too, but again, it's been beating with an ugly stick. The interface is also extremely confusing and non-intuitive. Last, it looks like a nightmare to install and configure this thing. The footprint requirements are probably steeper than they let on from the website. Imagine being in the testing department for this kind of app -- you have to spend hours and hours of regression testing to see what new feature change you made that probably broke a hundred other features.
However, two things to know with any of these ticketing systems are that everyone, eventually, will want to customize it or redo a feature that completely aggravates their workflow or what they are used to. One size does not fit all -- you can only try to hit some of it. One way to solve this problem is by throwing all the features in the sun in. Another way is to throw all the features in and provide a universal and individual set of customizable, web-clickable options to turn off this or that feature. However, yet another way to solve this is to make something simple that people can build upon.
My package that I'm building is much better than this. First, I don't throw everything in because not everyone needs the most amount of features -- they just need much of the basics. I've spent a lot of long nights thinking over what's the lowest common denominator without going so low as to not be usable, out of box. Second, by not throwing everything in, it's easier to customize a piece of software because you don't have miles and miles of code to wade through to get something done. Third, by not throwing everything, it's easier to install because the server requirements are smaller. For instance, if you don't include email hookup, but provide a FAQ on how that's coded and performed, you don't have to worry about writing something that hooks up to each and every type of email server out there. Fourth, by not throwing everything in, it's easier to use and is quite intuitive. Fifth, it's easier to customize with a "skin" (theme) and grow a web application that doesn't have miles and miles of code and features -- providing a doorway for OEM reselling opportunities. Sixth, my software will be both a standalone product and an SDK -- you choose which way you want to take it. This widens my customer base. If you were a programmer wanting an SDK, the product potentially appeals to you. if you were an IT manager and just want to get something easy to install and start using, then this could appeal to you as well.
Personally, if I had to put a solution in and was told I could purch