When I signed up to demo FogBugz, the FogBugz folks followed up and that lead to one of them reading my review of FogBugz and emailing a response. They've said it's ok for me to post it here:
(From Dan at FogBugz)
Thanks for the nice comments about FogBugz in your article.
The main point I would make with respect to your post is primarily a matter of emphasis. I don't
think a feature by feature comparison captures the true scope of what FogBugz does for project
management, software development and customer support. FogBugz aims to be a complete solution for
all phases of project management--a goal we're working on constantly, and one which FogBugz 6 comes
much closer to realizing.
FogBugz 6 can be used to develop specifications and technical documentation using the wiki. In
fact, much of the conversation that needs to happen around the development of the technical
specifications can occur right inside discussion groups inside your FogBugz installation.
Of course FogBugz does bug tracking, as it always has, but we've also added a ground-breaking way
to think about and manage projects with Evidence Based Scheduling. Cases can be used as the
various tasks and features of a development project. You can estimate the amount of time the task will
take and charge time against it for actual development. FogBugz learns how good the developer is
at making estimates and then uses that information to make probability estimates about when you
will finish your projects. Rather than trying to force a project into some arbitrary deadline (we
must be done by Christmas!) you can now get a real sense of when the project has the best chance
of wrapping up.
Once a project is complete and it now has clients that need support, FogBugz can fill that niche
as well. Between discussion forums and email handling (with Spam filtering and Bayesian sorting,
two life savers on a mail queue), there is a complete solution. One allows for direct support of
clients and the other one helps foster the development of community experts around your project.
You've taken an admirably even tone, but I think you've missed part of the larger picture that
I've tried to lay out, namely that FogBugz offers a solution for all phases of product development
that few other products can even come close to matching.
FogBugz is certainly not the answer for everyone's needs, but it goes a long way beyond just being
a bug tracker. It's grown a lot since its inception and, to be fair, your article might be more
balanced if it reflected the scope of some of these changes.
My response to Dan would be, I understand what he is saying and buy into a lot of it.
I wonder, though, about this: In some organizations it's enough of a challenge just to get an organization to change culturally so that folks use an issue tracker consistently instead of relying on email. It's hard to get people to change old habits. It's hard to get people to use their car seat belts despite the rational, statistical, life-and-death reasons for them to use them. So, about the Wiki, especially the Wiki, getting people to switch over from creating tech docs using, say, MS Word to using the FogBugz Wiki seems like it it would be a long frustrating struggle in many organizations.
None of what I wrote here is meant to conflict with what Dan wrote above. I guess I'm just reacting to his enthusiasm with reflexive reaction to pour rain on his parade, based on my experiences with trying to get organizations to adopt new cultural practice. I don't give up, but I don't expect much either.