Unabhängig davon welchen Bugtracker ein Projekt benutzt: es wird immer Entwickler geben, die oft und gerne etwas daran auszusetzen haben. Das scheint in Bezug auf Bugtracker häufiger zuzutreffen, als bei irgend einem anderen der üblichen Entwicklungswerkzeuge. Ich denke das liegt daran, dass Bugtracker so visuell und interaktiv sind, dass es leicht ist, sich die Verbesserungen vorzustellen die man vornehmen würde (wenn man nur die Zeit hätte), und diese Verbesserungen auch laut zu benennen. Nehmen Sie die Verbesserungen mit einem gewissen Vorbehalt – viele der hier aufgeführten Bugtracker 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. Hinweis: Dieser Überblick stammt größtenteils noch aus dem Jahre 2005, seitdem wurden einige neue Open-Source-Bugtracker geschrieben. So könnten wir die Liste sicherlich einmal aktualisieren, aber bis dahin erhalten Sie aktuelle Informationen unter , , und Redmine ist ein relativ junges (Stand 2011) und recht ausgefeiltes Projekt-Management-System. Es geht etwas über einen Bugtracker hinaus, denn es bietet auch Wikis, Diskussionsforen und andere Funktionen, dennoch scheint die Fehlerverfolgung sein Kernstück darzustellen. Es hat eine ziemlich intuitive webbasierte Benutzerschnittstelle, flexible Konfiguration (mehr als ein Projekt, rollenbasierte Zugriffskontrolle, benutzerdefinierte Felder usw.), Gantt-Diagramme, Kalender, bidirektionale E-Mail-Interktion und mehr. Wenn Sie ein neues Projekt beginnen würden und den Bugtracker frei wählen könnten, dann wäre Redmine eine gute Wahl. 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 zu einem recht ähnlichem Aussehen, und da viele Entwickler bereits mit der Bedienoberfläche vertraut sind, fühlen sich auf gewohntem Terrain. GNU GNATS ist einer der ältesten Open-Source-Butracker und weit verbreitet. Seine größten Vorteile sind die Vielfalt seiner Bedienung (er kann nicht nur durch den Browser sondern auch per E-Mail oder über Kommandozeile bedient werden) und die Speicherung der Tickets im Klartext. Die Tatsache, dass alle Daten der Tickets als Textdateien gespeichert werden, erleichtert es, eigene Programme zu schreiben, um die Daten analysieren und zu verarbeiten (zum Beispiel um Statistiken zu erstellen). GNATS kann E-Mails auch auf verschiedene Arten automatisch annehmen und sie den entsprechenden Tickets hinzufügen, was auf Grundlage von Mustern in den E-Mail-Headern geschieht, das erleichtert die Protokollierung des Austauschs zwischen Nutzern und Entwicklern. Auf der Webseite von RT steht "RT ist ein für Unternehmen geeignetes Ticket-System, welches einer Gruppe von Personen erlaubt, Aufgaben, Probleme und Anfragen die von einer Gemeinschaft von Nutzern eingereicht werden, intelligent und effizient zu verwalten", womit das Wesentliche gesagt ist. 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 Bugtracker. Es nutzt Wikiverweise um Tickets, Dateien, Changesets der Versionsverwaltung, und einfache Wikiseiten miteinander zu verbinden. Es ist recht einfach einzurichten, und lässt sich mit Subversion integrieren (siehe ). Roundup ist relativ einfach zu installieren (es wird lediglich Python 2.1 oder höher benötig) und einfach zu benutzen. Es kann per Browser, E-Mail oder Kommandozeile bedient werden. Die Vorlagen für Ticket-Daten und die Webinterface können genauso angepasst werden, wie Teile seiner Logik für die Übergänge zwischen verschiedenen Zuständen. Mantis ist ein Web-basierter Bugtracker, geschrieben in PHP, der MySQL als Datenbanksystem nutzt. 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 geschriebener 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-Themes; Datei-Anhänge; erweiterte Suchfunktionen (aber auch einfach zu bedienende); 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, gemeinschaftliches 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-Bugtracking-System ist insofern ungewöhnlich, als dass alle Eingaben und Änderungen per E-Mail gemacht werden: Jedes Ticket bekommt seine eigene Mailadresse. Das DBTS skaliert ziemlich gut: hat zum Beispiel 277,741 Tickets. Da die Bedienung über gewöhnliche E-Mail-Anwendungen erfolgt, eine Umgebung mit der die meisten Personen vertraut sind und zu der sie 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, das sie beim Schreiben in der Auswahl der nötigen Informationen unterstützen würde. Es gibt Programme, die den Nutzern zu helfen, bessere Bug-Meldungen zu schreiben, 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 so werden sie die Richtlinien, die für die Meldung von Bugs von Ihrem Projekt erarbeitet wurden, befolgen oder eben auch nicht. DBTS hat ein Webinterface mit reinem Lesezugriff, um Tickes anzuschauen und abzufragen. Solche Systeme sind eher darauf ausgelegt, Tickets für einen Informationsschalter zu überwachen, als Bugs in Software. Sie werden wahrscheinlich einen gewöhnlichen Bugtracker hilfreicher finden. Solche Systeme habe ich hier der Vollständigkeit halber aufgeführt, da auch auch ungewöhnliche Projekte vorstellbar sind, bei dem ein Trouble-Ticket-System besser passt als ein herkömmlicher Bugtracker. WebCall –  BTT liegt irgendwo zwischen Trouble-Ticket-Tracker und Bugtracker. Es bietet Funktionen für den Datenschutz, was unter Open-Source-Bugtrackern etwas ungewöhnlich ist: Nutzer des Systems werden in Mitarbeiter, Freunde, Kunden, oder Anonyme eingeteilt, und es stehen, je nachdem zu welcher Kategorie man gehört, mehr oder weniger Daten zur Verfügung. Es bietet etwas E-Mail-Integration, die Bedienung mittels Kommandozeile und Mechanismen um E-Mails in Tickets umzuwandeln. Es hat auch Funktionen zur Pflege von Informationen, die nicht mit einem spezifischen Ticket zu tun haben, wie z.B. interne Dokumentation oder FAQs.