Egal welchen Bug-Tracker ein Projekt benutzt, manche Entwickler beschwehren sich immer gerne darüber. Das scheint eher im Bezug auf Bug Tracker zuzutreffen, als bei irgend einem anderen der üblichen Werkzeuge für die Entwicklung. Ich denke das liegt daran, dass Bug Tracker so visuell und interaktiv sind, dass es leicht ist sich die Verbesserungen vorzustellen die man machen würde (wenn man nur die Zeit hätte), und diese Verbesserungen laut zu sagen. Nehmen Sie die Verbesserungen mit einem gewissen Vorbehalt—viele der hier aufgeführten Bug Tracker sind ziemlich gut.
In dieser Auflistung wird das Wort "Ticket" benutzt, um Einträge in dem Tracker zu bezeichnen. Denken Sie aber daran, dass jedes System seine eigene Begriffen verwenden kann, wobei der Begriff etwas wie "issue", "artifact", "bug" oder etwas anderes sein könnte.
Bugzilla ist sehr beliebt, wird aktiv entwickelt, und scheint seine Nutzer ziemlich glücklich zu machen. Ich benutze eine angepasse Variante auf meiner Arbeit seit mittlerweile vier Jahren, und ich mag es. Man kann es nicht sonderlich individualisieren, aber auf eine komische Art, könnte das einer seiner Vorteile sein: Installationen von Bugzilla neigen dazu überall ziemlich ähnlich auszusehen wo immer man sie antrifft, was bedeutet, dass viele Entwickler bereits mit seiner Bedientung vertraut sind und sie werden sich auf gewohntem Gebiet fühlen.
GNU GNATS ist eines der ältesten Open Source Bug Tracker und ist weit verbreitet. Seine größten Vorteile sind die Vielfalt seiner Bedienung (es kann nicht nur mit einem Web Browser sondern auch per Email und über die Kommandozeile bedient werden), und die Speicherung von Tickets im Klartext. Die Tatsache dass alle Daten der Tickets in Text Dateien gespeichert werden, erleichtert es eigene Programme zu schreiben, um die Daten analysieren und zu verarbeiten (zum Beispiel um Statistik Berichte zu generieren). GNATS kann auch auf verschiedene Arten Emails automatisch aufnehmen, und sie den entsprechenden Tickets hinzufügen, auf der Grundlage von Mustern in den Email 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 ausgefeilte Web Oberfläche, und scheint ziemlich breit installiert zu sein. Die Oberfläche ist visuell etwas komplex, das wird aber wärend Sie sich daran gewöhnen weniger ablenkend. RT ist unter der GNU GPL lizensiert (aus irgend einem Grund, macht ihre Webseite das nicht klar).
Trac etwas mehr als ein Bug Tracker: es ist in wirklichkeit ein integriertes System von Wiki und Bug Tracker. Es benutzt wiki Verweise um Tickets, Dateien, Changesets der Versionsverwaltung, und einfache Wiki Seiten zu verbinden. Es ist relativ einfach einzurichten, und lässt sich mit Subversion integrieren (siehe Anhang A, Systeme zur Versionsverwaulung).
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, Email und der Kommandozeile bedient werden. Die Vorlagen für Ticket Daten und die Web Oberfläche können genau so angepasst werden, wie einige seiner Logik für die Übergänge zwischen verschiedenen Zuständen.
Mantis ist ein Web basierter Bug Tracker, 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 Bug Tracker. 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 Email 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; Diagramme von Abhängigkeiten.
Scarab ist als hochgradig anpassbarer, vollständiger Bug Tracker gedacht, welches mehr oder weniger die Vereinigung aller Funktionen die von anderen Bug Tracker angeboten werden: Daten Eingabe, Abfragen, Berichte, Benachrichtigungen an interesierte Parteien, gemeinschafftliche Ansammlung 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 insofern ungewöhnlich, dass alle Eingaben und Änderungen über Email gemacht werden: Jedes Ticket bekommt seine eigene Email Adresse. Das DBTS skaliert ziemlich gut: http://bugs.debian.org/ hat zum Beispiel 277,741 Tickets.
Da die Bedienung über gewöhnliche Email Anwendungen erfolgt, eine Umgebung welche mit dem die meisten Person vertraut sind und leicht Zugang haben, ist das DBTS gut für die Handhabung großer Mengen eingehender Meldungen die eine schnelle klasifizierung 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 die Nutzer zu helfen, bessere Bug Meldungen zu machen, wie das Kommandozeilen Programm reportbug oder das debbugs-el Paket für Emacs. Die meisten Leute werden diese Werkzeuge aber nicht benutzen; sie werden die Email einfach händisch schreiben, und es mag sein, dass sie die Richtlinien für die Meldung von Bugs die von Ihrem Projekt veröffentlicht wurden, befolgen oder auch nicht.
DBTS hat eine Web Oberfläche mit reinem Lese-Zugriff, um Tickes anzuschauen und Abzufragen.
Diese sind eher darauf ausgelegt Tickets für ein Informationsschalter zu überwachen, als Bugs in Software. Sie werden wahrscheinlich einen gewöhnlichen Bug Tracker hilfreicher finden, sind aber der Komplettheit halber und da man sich ungewöhnliche Projekte vorstellen kann bei dem ein Trouble-Tocket System eher angemessen wäre als ein herkömmlicher Bug Tracker hier aufgelistet.
WebCall — http://myrapid.com/webcall/
Teacup — http://www.altara.org/teacup.html
(Teacup scheint nicht mehr aktiv entwickelt zu werden man kann es aber noch herunterladen. Beachten Sie, dass es sowohl über einen Browser als auch über Email bedient werden kann.)
BTT liegt irgendwo zwischen den üblichen trouble-ticket trackern und einem Bug Tracker. Es bietet Funktionen für den Datenschutz, was unter Open Source Bug Tracker 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 Email Integration, eine Bedienung mittels der Kommandozeile, und Mechanismen um Emails in Tickets zu konvertieren. Es hat auch Funktionen um Informationen zu pflegen, die nicht mit irgend einem spezifischen Ticket zu tun haben, wie interne Dokumentation oder FAQs.