Please keep in mind that the following points may not apply to the latest FogBugz / JIRA versions. We evaluated FogBugz and JIRA in the summer of 2006 before going with JIRA. At this time, we’re still on JIRA 3.x due to licensing changes in JIRA 4 and being trapped in interiorcad 2010′s release tornado.
- With JIRA, we got the source code – in a standard language we are vaguely familiar with using open-source technologies – capable of running on a variety of platforms, including MacOS X which we’re most familiar with (and, quite frankly, prefer)
- We could start without a separate database server. Plus, no need to license SQL server. Forums were quite clear at the time that FogBugz and MySQL didn’t play as well together as we needed
- Attachments in FogBugz were stored within the database (at the time). This was the showstopper for us. At least 50% of our 18000+ issues in JIRA have 5MB+ attachments to them. I don’t want these bytes in a relational database. Don’t tell me this is no problem with database server XYZ. I have been a database guy for a very long period of my professional life. No binary large objects in my databases as long as I can still breathe.
- We didn’t want to administer a Windows server machine – Although FogBugz could be run on Linux or MacOS X, the forums showed that the jury was still out (at the time) if this was a good idea
- Licensing – There was a unlimited users license of JIRA at the time, which was more affordable for a smaller company like us. This has changed with JIRA 4 (for the worse).
- Plug-ins – There was and still is a lively plug-in community for JIRA – I understand that the latest version of Fogbugz offers plug-ins, too
One area where FogBugz is way better suited to our needs is E-Mail integration. Basically, e-mail integration in JIRA sucks for us. Way too complicated to set-up & manage. Plus, the e-mails sent out by JIRA are basically unusable for end-user support (at least without a lot of tinkering).
Overall, we have been very happy with our choice. JIRA has been extremely reliable for us – which is requirement #1. We need to get our software done. We aren’t paid for fiddling around with third-party software (for set-up information go here, you will be amazed). Does its job well. JIRA 4 looks like a substantial step forward in terms of UI improvements. There are quite a few other products from Atlassian which play well with JIRA and which we’re looking very closely at, namely Confluence, Crucible and GreenHopper.
E-Mail integration / Using JIRA for technical support still sucks as far as we are concerned (Small company dealing with thousands of not-too-computer-savvy customers around the world). JIRA is quite enterprisey, and it shows – in terms of set-up, in terms of administration and in terms of features. Sometimes, less would be more as far as we are concerned.
Sounds like you made the right choice. I inherited a FogBugz installation, and found that it needed a serious dose of hacky scripts just to keep it running on a standard LAMP box. I recently replaced the old system with a fresh install and the latest build of FogBugz, and I can tell you that for as bad as it was before, it’s 10x worse with the release of FB7. Note that now they’re supplying their own build of Apache, statically linked against mono, so that they can render their ASP code. That’s right, ASP on Linux. This is in addition to piles of js code and crazy heartbeat scripts running in the background. Hardcore Windows shops might be happy with this arrangement, but everyone else should run for their lives.