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.
Throughout these listings, the word "issue" is used to refer to the items the trackers track. But remember that each system may have its own terminology, in which the corresponding term might be "artifact" or "bug" or something else.
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 issue storage. The fact that all issue 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 issues 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 issues, files, version control changesets, and plain wiki pages. It's fairly simple to set up, and integrates with Subversion (see Apêndice A, Sistemas de Controle de Versão Livres).
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 issue 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 issue 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 issues is done via email: each issue gets its own dedicated email address. The DBTS scales pretty well: http://bugs.debian.org/ has 277,741 issues, 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
project.
The DBTS has a read-only web interface, for viewing and querying issues.
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/
Teacup — http://www.altara.org/teacup.html
(Teacup doesn't appear to be under active development anymore, but the downloads are still available. Note that it has both web and email interfaces.)
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.