No matter what bug tracker a project uses, some developers always like to complain about it. This seems to be more true of bug trackers than of any other standard development tool. I think it's because bug trackers are so visual and so interactive that it's easy to imagine the improvements one would make (if one only had the time), and to describe those improvements out loud. Take the inevitable complaints with a grain of salt—many of the trackers below are pretty good.
Note: This survey was first done in 2005, and some new open source bug trackers have been written since then. As of late 2011, I've made a few updates to the material below, but I haven't done a broad update of the entire survey. You might also want to look at the Wikipedia Comparison of Issue Tracking Systems, the DMOZ Bug Tracker survey, the article (and attached comments) Ask Slashdot: How do you track bugs for personal software projects?, or this list at WebResourcesDepot.
Redmine is a relatively recent (as of 2011) and pretty polished project tracking system. It's somewhat more than a bug tracker, since it also offers wikis, message forums, and other features, but bug-tracking seems to be the core of what it does. It has a fairly intuitive Web-based user interface, flexible configuration (multiple projects, role-based access control, custom fields, etc), Gantt charting, calendaring, bidirectional email interaction, and more. If you're setting up a new project and you can choose any bug tracker you want, Redmine is a good choice.
Bugzilla is very popular, actively maintained, and seems to make its users pretty happy. I've been using a modified variant of it in my work for four years now, and like it. It's not highly customizable, but in a odd way, that may be one of its features: Bugzilla installations tend to look pretty much the same wherever they are found, which means many developers are already accustomed to its interface and will feel they are in familiar territory.
GNU GNATS is one of the oldest open source bug trackers, and is widely used. Its biggest strengths are interface diversity (it can be used not just through a web browser, but also through email or command-line tools), and plaintext ticket storage. The fact that all ticket data is stored in text files on disk makes it easier to write custom tools to trawl and parse the data (for example, to generate statistical reports). GNATS can also absorb emails automatically by various means, and add them to the appropriate tickets based on patterns in the email headers, which makes logging user/developer conversations very easy.
RT's web site says "RT is an enterprise-grade ticketing system which enables a group of people to intelligently and efficiently manage tasks, issues, and requests submitted by a community of users," and that about sums it up. RT has a fairly polished web interface, and seems to have a pretty wide installed base. The interface is a bit visually complex, but that becomes less distracting as you get used to it. RT is licenced under the GNU GPL (for some reason, their web site doesn't make this clear).
Trac is a bit more than a bug tracker: it's really an integrated wiki and bug tracking system. It uses wiki linking to connect tickets, files, version control changesets, and plain wiki pages. It's fairly simple to set up, and integrates with Subversion (see Appendix B, Free Version Control Systems).
Roundup is pretty easy to install (only Python 2.1 or higher is required), and simple to use. It has web, email, and command-line interfaces. The ticket data templates and web interface are customizable, as is some of its state-transition logic.
Mantis is a web-based bug tracking system, written in PHP, and using MySQL database for storage. It has the features you'd expect. Personally, I find the web interface clean, intuitive, and easy on the eyes.
Flyspray is a web-based bug tracking system written in PHP. Its web pages describe it as "uncomplicated", and the list of features includes: multiple database support (currently MySQL and PGSQL); multiple projects; 'watching' tasks, with notification of changes (via email or Jabber); comprehensive task history; CSS theming; file attachments; advanced search features (though easy to use); RSS/Atom feeds; wiki and plaintext input; voting; dependency graphs.
Scarab is meant to be a highly customizable, full-featured bug tracker, offering more or less the union of the features offered by other bug trackers: data entry, queries, reports, notifications to interested parties, collaborative accumulation of comments, and dependency tracking.
It is customizable through administrative web pages. You can have multiple "modules" (projects) active in a single Scarab installation. Within a given module, you can create new ticket types (defects, enhancements, tasks, support requests, etc.), and add arbitrary attributes, to tune the tracker to your project's specific requirements.
As of late 2004, Scarab was getting close to its 1.0 release.
The Debian Bug Tracking System is unusual in that all input and manipulation of tickets is done via email: each ticket gets its own dedicated email address. The DBTS scales pretty well: http://bugs.debian.org/ has almost a quarter of a million tickets as early 2014, for example.
Since interaction is done via regular mail clients, an
environment which is familiar and easily accessible to most people,
the DBTS is good for handling high volumes of incoming reports that
need quick classification and response. There are disadvantages too,
of course. Developers must invest the time needed to learn the email
command system, and users must write their bug reports without a
web form to guide them in choosing what information to write. There
are tools available to help users send better bug reports, such as the
command-line reportbug program or the
debbugs-el package for Emacs. But most
people won't use these tools; they'll just write email manually, and
they may or may not follow the bug reporting guidelines posted by your
The DBTS has a read-only web interface, for viewing and querying tickets.
These are more oriented toward help desk ticket tracking than software bug tracking. You'll probably do better with a regular bug tracker, but these are listed for the sake of completeness, and because there could conceivably be unusual projects for which a trouble-ticket system might be more appropriate than a traditional bug tracker.
WebCall — http://myrapid.com/webcall/
BTT is somewhere between a standard trouble-ticket tracker and a bug tracker. It offers privacy features that are somewhat unusual among open source bug trackers: users of the system are categorized as Staff, Friend, Customer, or Anonymous, and more or less data is available depending on one's category. It offers some email integration, a command-line interface, and mechanisms for converting emails into tickets. It also has features for maintaining information not associated with any specific ticket, such as internal documentation or FAQs.