Bugzilla ist sehr verbreitet, wird aktiv entwickelt und scheint seine Nutzer ziemlich glücklich zu machen. Ich benutze eine angepasste Variante bei meiner Arbeit seit mittlerweile vier Jahren, und ich mag es. Man kann es nicht sonderlich individualisieren, aber auf eine gewisse Art kann das als Vorteil betrachtet werden: Bugzilla-Installationen neigen so stets zu recht ähnlichem Aussehen, und da viele Entwickler bereits mit der Bedienoberfläche vertraut sind, fühlen sich auf gewohntem Terrain.

GNU GNATS ist eines der ältesten Open-Source-Butracker und ist weit verbreitet. Seine größten Vorteile sind die Vielfalt seiner Bedienung (es kann nicht nur mit einem Browser sondern auch per E-Mail oder über die Kommandozeile bedient werden), und die Speicherung von Tickets im Klartext. Die Tatsache dass alle Daten der Tickets in Textdateien gespeichert werden, erleichtert es, eigene Programme zu schreiben, um die Daten analysieren und zu verarbeiten (zum Beispiel um Statistiken zu generieren). GNATS kann auch auf verschiedene Arten E-Mails automatisch aufnehmen, und sie den entsprechenden Tickets hinzufügen, auf der Grundlage von Mustern in den E-Mail-Headern, was es sehr einfach macht, die Unterhaltungen zwischen Nutzer und Entwickler zu protokollieren.

Die Webseite von RT sagt "RT ist ein für Unternehmen geeignetes Ticket-System, welches einer Gruppe von Personen erlaubt, intelligent und effizient Aufgaben, Probleme und Anfragen die von einer Gemeinschaft von Nutzern eingereicht werden, zu verwalten", was es im wesentlichen zusammenfasst. RT hat eine relativ ausgefeiltes Webinterface, und scheint ziemlich weit verbreitet zu sein. Die Optik der Oberfläche wirkt zunächst etwas komplex, bedarf aber lediglich einer Eingewöhnungsphase. RT ist unter der GNU GPL lizenziert (aus irgend einem Grund wird das auf der Webseite nicht recht deutlich).

Trac ist etwas mehr als ein Butracker: es ist in Wirklichkeit ein integriertes System von Wiki und ButTracker. Es benutzt Wikiverweise um Tickets, Dateien, Changesets der Versionsverwaltung, und einfache Wikiseiten zu verbinden. Es ist relativ einfach einzurichten, und lässt sich mit Subversion integrieren (siehe Anhang A, Systeme zur Versionsverwaltung).

Roundup ist relativ einfach zu installieren (es wird lediglich Python 2.1 oder höher benötig) und einfach zu benutzen. Es kann mit einem Browser, E-Mail und der Kommandozeile bedient werden. Die Vorlagen für Ticket-Daten und die Webinterface können genau so angepasst werden, wie Teile seiner Logik für die Übergänge zwischen verschiedenen Zuständen.

Mantis ist ein Web-basierter Bugtracker, geschrieben in PHP, und mit MySQL als Datenbank. Es hat die Funktionen die man erwartet. Ich perönlich finde die Oberfläche sauber, intuitiv, und angenehm für die Augen.

Flyspray ist ein in PHP geschreibener Bugtracker. Seine Webseite beschreibt es als "unkompliziert", und die Liste seiner Funktionen beinhaltet: Unterstützung für mehrere Datenbanken (derzeit MySQL und PGSQL); mehrere Projekte; 'Beobachtung' von Aufgaben, mit Benachrichtigung bei Änderungen (mittels E-Mail oder Jabber); umfassende Historie von Aufgaben; CSS-Motive; Datei-Anhänge; erweiterte Suchfunktionen (aber einfach zu bedienen); RSS-/Atom-Kanäle; Wiki und Klartext-Eingabe; Abhängigkeitsdiagramme.

Scarab ist als hochgradig anpassbarer, vollständiger Bugtracker gedacht, mehr oder weniger die Vereinigung aller Funktionen die von anderen Bugtrackern angeboten werden: Daten-Eingabe, Abfragen, Berichte, Benachrichtigungen an interesierte Parteien, gemeinschafftliches Sammeln von Kommentaren und Verfolgung von Abhängigkeiten.

Es ist über administrative Webseiten anpassbar. Sie können in einer einzigen Scarab-Installation mehrere aktive "Module" (Projekte) haben. Innerhalb eines Moduls können Sie neue Arten von Tickets anlegen (Mängel, Verbesserungen, Aufgaben, Support-Anfragen, usw.) und beliebige Attribute hinzufügen, um den Tracker an die spezifischen Erfordernisse ihres Projekts anzupassen.

Ende 2004 näherte sich Scarab seiner 1.0-Version.

Das Debian Bug Tracking System ist insofern ungewöhnlich, dass alle Eingaben und Änderungen per E-Mail gemacht werden: Jedes Ticket bekommt seine eigene Mailadresse. Das DBTS skaliert ziemlich gut: http://bugs.debian.org/ hat zum Beispiel 277,741 Tickets.

Da die Bedienung über gewöhnliche E-Mail-Anwendungen erfolgt, eine Umgebung mit der die meisten Person vertraut sind und leicht Zugang haben, ist das DBTS geeignet für die Handhabung großer Mengen eingehender Meldungen, die eine schnelle Klassifizierung und Reaktion benötigen. Es gibt natürlich auch Nachteile. Entwickler müssen Zeit investieren, um das Befehlssystem zu lernen, und Nutzer müssen ihre Bug-Meldungen ohne ein Web-Formular eingeben, welches sie beim Schreiben mit der Auswahl der nötigen Informationen hilft. Es gibt Programme um den Nutzern zu helfen, bessere Bug-Meldungen zu machen, wie das Kommandozeilenprogramm reportbug oder das debbugs-el-Paket für Emacs. Die meisten Leute werden diese Werkzeuge aber nicht benutzen; sie werden die E-Mail einfach per Hand schreiben, und es mag sein, dass sie die Richtlinien, die für die Meldung von Bugs die von ihrem Projekt veröffentlicht wurden, befolgen oder auch nicht.

DBTS hat ein Webinterface mit reinem Lese-Zugriff, um Tickes anzuschauen und abzufragen.

Dieses System ist eher darauf ausgelegt, Tickets für einen Informationsschalter zu überwachen, als Bugs in Software. Sie werden wahrscheinlich einen gewöhnlichen Bugtracker hilfreicher finden, sind aber der Komplettheit halber und da man sich ungewöhnliche Projekte vorstellen kann bei dem ein Trouble-Ticket System eher angemessen wäre als ein herkömmlicher Bugtracker hier aufgelistet.

BTT liegt irgendwo zwischen den üblichen Trouble-Ticket-Trackern und einem Bugtracker. Es bietet Funktionen für den Datenschutz, was unter Open-Source-Bugtrackern etwas ungewöhnlich ist: Nutzer des Systems werden in Mitarbeiter, Freund, Kunde, oder Anonymer kategorisiert, und es stehen, je nachdem zu welcher Kategorie man gehört, mehr oder weniger Daten zur Verfügung. Es bietet etwas E-Mail-Integration, eine Bedienung mittels Kommandozeile, und Mechanismen um E-Mails in Tickets umzuwandeln. Es hat auch Funktionen um Informationen zu pflegen, die nicht mit irgend einem spezifischen Ticket zu tun haben, wie interne Dokumentation oder FAQs.