Are there any unhappy users of FogBugz?

Question

Are there any unhappy FogBugz user? Or someone that evaluated it and decided that it lacks some essential features?

Edit:

We are evaluating FogBugz and I would like to know if there is something that might hurt us.

Answer 1

We've been using it for years. It's an excellent bug tracking solution.

In all that time no problems with it at all.

Answer 2

It does a pretty excellent job for us. FB is a really simple experience which has many advantages.

I don't like the fact you can't specify dependencies, cos that's important for us.

Answer 3

@Yaakov, re:

I suggest that you check out the FogBugz Tech Support forum or support for FB-related issues.

To try and find deeper criticism of a tool, I think Michael's doing the right thing by looking further afield than the product's own forum.

I use fogBugz and really like it. I wish all software was as well designed.

Answer 4

Our project evaluated it years ago and rejected it because of price(!). I also think there were political issues and people didn't like the name. We're stuck with Bugzilla for the moment, which isn't really successful. I hope to have it in the mix on future projects, but it will need to be more carefully presented. In particular, it fails the standard "feature matrix" test that we used for evaluation. It looks like there are a ton of new features now that will help for next time. Now if only it had a less annoying name...

Answer 5

For pure bug tracking, I favor bugzilla, but if you already don't like it, then it probably does not suite your culture. My observation is that you might not be a Perl/hacking type of place (which is okay.)

Fogbugz is a very good package, esp. w/ the critical mass of modules in FB6. However, there are two things I found problematic:

1- No dependencies. The product is a very strong reflection of Joel's vision of development. He doesn't believe in dependencies. I come from "lots of bugs in bugzilla" environment, and tracking bugs, dependencies, and blocks are critical to the effort to land a big release.

2- When something is closed, it is un-editable. This means that doing routine cleanup, re-organizing old projects that other people messed up, etc... can be very painful. If you are going to insert this into a multi-group environment, get everyone on the same page process-wise.

So, it really depends. If you were mozilla I wouldn't recommend it. :) I haven't looked at other popular trackers like Jira, but I've used a couple obscure bug trackers, and they were really bad (so I won't name names). I can't say "FB6" is the best, but you should give it a serious look because of it's strong-generalist dev/beta_support/discussion/wiki/scheduling story.

Answer 6

My team uses it, at my recommendation. Most of them like it, but one fellow complains about it endlessly, primarily because of what is (to the rest of us) a very obscure technical decision. If I remember correctly, it was: when you close a case, it replaces the name of the last person the case was assigned to. (This person wanted to have closed cases automatically reassigned to the last person that touched them if they get re-opened.)

Frankly, I don't see the problem with it. One thing to note, the *NIX version of it has caused us a little grief -- as much as I hate to ever advise people to use a Windows server, the Windows version of FogBUGZ is less problematic. Or it was when we started using it a few years ago anyway, I think Joel Spolsky hired a guy specifically to improve the *NIX version a little while ago.

Answer 7

I like FogBugz a lot. There are a few features I would like it to have that seem to be missing, however.

First, it would be nice if you could make dependencies between cases. Many times one case will block another and it's pointless to have one engineer work a problem only to find that they cannot complete it because another engineer needs to finish their work first.

Second, there doesn't seem to be any "cc" functionality in which people can get notified when things change with a case if they are not either working the case or requesting the case.

Lastly, when a case is resolved, the person working on it no longer owns the case. We usually would like to look at engineer productivity and it would be nice to see how many cases were resolved by engineer X last week, e.g. There is no simple way to formulate that query using FogBugz alone. You can write an application to look at resolved tickets and then look at the last owner in the history for the case, but it's not possible to just ask for the cases resolved by X.

Answer 8

Ours works fantastic. We've got challenges with some folks who aren't used to how FogBugz works in comparison to our old system which was running a package called Remedy but slowly adoption is taking favour.

I love it because I can organize the development projects for my team easily and effectively. I break down my projects into smaller more manageable chunks and easily assign them to the various team members. Even better, I like how you can create Wikis that sort of tie everything together via linked cases and otherwise.

I'll commonly create a Project Wiki in which I can keep track of all project related information including:

• Meeting Minutes
• System Requirements
• Functional Specifications
• Planning Cases
• Development Cases
• Q/A Cases
• User Documentation
• Beta Site Candidates

As well as any other sort of project related correspondence. Even better, all of that stuff is indexed which means it'll come back in your search 8 months down the road when you forgot which spec had that wicked new feature in it.

EBS is excellent too. When the Director asks me where I'm at on a project with my team, it's an easy answer. When he needs it sooner, I can easily scale features based on priority.

That being said some flexibility I'd like to have would include:

• The ability for an Admin to delete comments in cases.
• The ability for the person who opens a case or makes a comment to edit or delete that comment after it has been made.
• The ability to delete global releases if you've set some up by mistake. (instead of just making them "not viewable").

Hope that helps... And to answer your question, nope, not that I've heard!

Answer 9

We at Fog Creek are not afraid of (constructive) criticism. You are well within your rights to look farther afield for criticisms. You can also just ask us! We know we've got a great product and that nothing is ever perfect, and would much rather have you know the shortcomings going in than get your data into the system and find it won't work for your specific needs. (It happens!)

The support forum is not a love-in by any means. In fact, some of our harshest critics are active participants. I encourage you to post.

A few direct replies:

• We call it the great bug tracking tool with the stupid name. Sorry that's getting in the way of your selling it.
• Head Geek's workflow deal will be getting addressed.
• A lot of our *NIX issues are around PHP, and we're walking away from PHP in our next major version.
• We've heard the dependencies complaints very clearly. While we're not planning on delivering pure blocking (1234 blocks 2345), we are planning on addressing this in our next release

Answer 10

I'll chime in as a "not happy". We did test it out online for a while (which I highly recommend you do), but somehow, we missed all the small problems that annoy us to this day.

I'd compare them to Apple in that they have a very specific worldview, and if you worldview is the same or you can deal with that worldview, fine, the product is nice, but if you don't agree with all points in their worldview, you will find some of their choices maddening.

• It is impossible for an inhouse user to report a bug and then keep up with its progress (ie, no support for "free" read-only access). You have to either buy additional licenses for these sorts of people, or burn a license on a general user (which then makes it more difficult to communicate with the original bug reporter).
• Many small things that seem reasonable are not done (see their support forum for the vast list). Some you can do with your own perl hacking or java scripting. For the ones that are java scripting, you have to ask why it isn't in the interface to begin with (like cloning cases).
• They have wiki integration and forums... but why? Neither of these items are well integrated into the case reporting system, and there are much better wikis and forums out there. These two features just seem a giant waste of time to me.
• The biggest annoyance is that they have a policy of not telling anyone what they are working on. As a programmer, I understand why you don't want to be specific, but they really give absolutely no idea of where they are going. This makes it very difficult to justify buying a continuing support contract. The only thing I really know about FogBugz 7 is that it supports "plug-ins". I know this because almost every feature request posted to the support board is now answered with, "You can do this in 7 with plug-ins". AKA, you'll probably be writing it yourself.
• Another big disappointment is their handling of email. They don't support HTML mail at all. So basically, all formatting is lost, as well as inline snapshots. They don't consider this a big deal (a lot of work for a small payoff they say), but unfortunately, that's the way we do things around here. This is part of what's keeping our support staff from transitioning from a simple global support email box to FogBugz.
• There's no way to add people to a list of those who get notified when a bug changes, like the CC: field of Bugzilla. Only the assigned programmer gets notified of changes, until the case reaches the resolved state.
• There's no "Next Page" when a large number of results appear. It normally only shows 45 results or so, then you hit a button at the bottom if you want to see them all (and this can be really slow to display everything).
• You can make as many "community accounts" as you like, but when a community account submits a bug report from the website portal, it is posted anonymously so you don't know the reporter. This makes "community accounts" completely useless.

My personal feeling is that if you are running a small shop (10 or fewer programmers), and you are running the shop pretty loose, you will be better served with Bugzilla. Certainly if you are currently on Bugzilla, you should beware the transition. We migrated from Bugzilla to FogBugz, and the bugs transferred easily enough. But I am seeing gripes about FogBugz from my team tacked onto the ends of cases with much swearing because there are many simple things Bugzilla does (like the CC: field thing mentioned above) that somehow violate FogBugz philosophy.

So be careful about evaluating FogBugz, especially if you are a fan of "Joel on Software" - don't let that color your decision like I did. It is my opinion now that the FogBugz team is not being run in the fashion you'd expect after reading Joel's columns.

Answer 11

We've been using FogBugz for over a year now, and by and large I like it. My only real problem with it is that comments on cases all go in as plain text - you can't do lists, can't emphasise points, and code pasted in is impossible to read.

It just seems strange to me that such a fundamental feature is missing, especially since the exact same thing has already been developed for the wiki feature...

Answer 12

We've used FogBugz for four years and have always considered switching to something else. There are a few critical things it does not do well.

1. Management. Management and reporting features are in general lacking, particularly compared to other applications like Jira. There are third party applications that provide reporting on top of FogBugz, but even with that it never gets us the kind of big picture we want.

2. Flexibility. Fogbugz is not really flexible at all. It allows you to rename two fields and customize a few things, but compared to most bug trackers it is very rigid. When we've e-mailed support about this and the general feeling is that it's never going to change. Joel has blogged about how flexibility is bad, and unfortunately we don't agree. Examples of things we'd like to change are workflow: every case is always assigned back to the person that created it. We'd like cases assigned to a tester for verification when resolved, not whoever happened to find it (we have support, management, and sales all create cases, but they don't do follow up testing).

3. Inability to edit. You cannot edit the text of a case. The text of a case is just a running tally of comments. This works well most of the time, but often enough there is a real need to edit a comment and it's not possible. Therefore if a case starts out with a question, there is a discussion, and then a final decision, it can be easy to implement or test it incorrectly since there is no way to differentiate earlier specifications. We generally work around this when we know a case is going to require discussion by creating a discussion case, and once a decision is made we open a new case and close and reference the original. There are other times when inability to edit is bad though, like if someone mistakenly puts confidential info in a case.

4. Customer portal. There is no customer-facing portal.

5. Support attitude. FogBugz support has a very open-source style attitude where requests are always responded to with a suggestion that we make the changes ourselves. They think just 'cause it's written in ASP and it's possible for customers to make changes, we should. It's ridiculous. Changing the source code for your FogBugz installation will make updates a nightmare. Besides people buy commercial software to get a certain level of quality and ongoing maintenance.

6. Minimal changes. We've used FogBugz through the last two major upgrades and were extremely disappointed in both. 5 added some ajax but no major features, and 6 added a crappy wiki and very advanced time tracking. 7 is in beta now but FogCreek is totally silent on what new features are being added.

7. Price. After a few dozen users, FogBugz gets very expensive compared to good commercial alternatives. Particularly important is they doubled the cost of support contracts with the last release and we were told they'll be increasing it another 50% along with the next release. Couple this with the fact that an existing customer cannot buy a new support contract without paying for the entire time an account has been out of support, and it can be very expensive.

After all that, we still use it on a daily bases for bug tracking, customer support, and HR (resumes/interviews/etc). It works extremely well for day-to-day work--working through a list of assigned cases, triaging cases, tracking customer e-mail. The search stuff added in 6 is great.

HTH,

Sam

Answer 13

Just for fun, I'm going to rebut mpbk's points from the point of view of a very satisfied user:

1. We use full licenses on people that need to know that the state of a bug is changing. What we decided early on was that we don't need that much access to our case tracking system. We want to have openness in our work but we don't need to give 100% of the detail to everyone who might possibly care. The fact that their price list is right on the website is hugely important to our purchasing process as well. At this point, I'm recommending against all software where the price question is answered with "call this number to speak to one of our sales personnel." No thanks.
2. With respect to small features missing and interface issues, we actually changed our software process to match the tool. In fact, we found it as an interesting source of new ideas to refining and removing ceremony from the process.
3. The wikis are huge. I am currently working on training material for an upcoming delivery using the wiki to develop the text in a collaborative environment. The discussion groups are also critical to our work. Every piece of text can be linked to / from the cases as well.
4. With respect to Fogcreek's future development efforts, I really don't care very much. That said, Fogbugz 6 completely floored me. It was an enormous lever for me to use as I pried some of the older software processes off of the team. It's quick, easy and our team uses it.
5. In terms of the lack of HTML mail, we can't use integrated HTML mail at work so it's a non-issue for us.
6. Everyone on the team who's really interested in a particular case currently either subscribes to it via email, the RSS of the specific document or the RSS feed of the whole project (group of cases).
7. We never use community accounts so that's a non-issue for us.

In terms of team size, the active pool of people that was using Fogbugz on our team when we switched was 6-10 people and we took to it like ants to sugar. Our software process shrunk down to less than a sheet of paper. It integrates well with our configuration management. We even use it to communicate directly to our remote customer sites.

Answer 14

Seems like people are being a bit hard on the product. I can see a fairly obvious reason why Cases don't support wiki formatting. It just didn't make the Fogbugz 6.0 release. The wiki was first released in 6.0.

It's a good idea to integrate a ticketing system with a wiki - other bug trackers do it.

No doubt they'll put wiki editing into Cases in 7.0 since it's probably an easy obvious feature to put in.

In terms of pricing Fogbugz is not expensive. Unless you hire monkeys to do your coding it's not going to a serious cost compared to salaries.

Answer 15

We've been using FB 5, 6 and now 7. My primary reason for choosing it was cost and simplicity. The simplicity was critical not for myself but rather to get the other people that are less tech savvy and unfamiliar with any bug tracking system on board with the concept. For the same reason, the Wiki was huge. We had a (superior IMO) wiki prior to FB 6 and no one used it. It is simply too difficult to convince everyone to use it. However, now that it is integrated, along with constant hounding "it's on the Wiki!", I have gotten buy-in. There are other bug tracking systems out there and other Wikis and frankly, the wiki editor drives me up the wall but it is good enough to put something in place and get people used to bug tracking. I've seen JIRA and I like the customer management elements which are superior to FB but I know that culturally we still have too many people still getting used to the idea of doing all tracking online that switching would be too difficult.

Answer 16

I'm much happier now it is better at supporting Scrum.

http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx

My only grip right now is that I am getting an email everytime a bug occurs in v7. In v6 I got an email the first time the bug occured, and then FogBugz would track the number of occurences. We loved this.

We had an error with a hotfix the other day and my integration framework experienced lots of errors in the space of a couple of minutes..... I got 767 emails....!!!

Answer 17

Well, I finally have 2 things about FB:

• No code coloring
• And not posibility to do single sing-on. So, the user need to register in both system (my website and the forums) or deny the possibility to myself of manage the user database. With not easy way to integrate the forums/wiki to my own website, the usefullness to me is almost zero. :(

Answer 18

We have been using Fogbugz for over 2 years. It was initially chosen as a compromise between features/complexity. It doesn't do everything, but it is also really simply to use.

After two years I have to say that what we have seen is a constant refinement of Fogbugz. It just keeps getting better and better. Or perhaps we just keep adjusting to it. I don't know. But we use it heavily every day, by people scattered across the globe. Using some of the plug-ins (workflow, Perforce) we have been able to get Fogbugz to suit our process/workflow very well.

It was a marginal product when we started using it. It has evolved to be a product that is on the short-list with things like Perforce that we see a must-haves for development teams.