Issue tracking systems

Major issue tracking systems

Proprietary ones and/or paid services

Will not cover those, it is mainly a source of frustration to me: they tend to be broken (perhaps not even worth listing: virtually everything that can be broken is broken at least in some of those) with no hope for improvement, yet managing to get sold and used in companies. I can go on complaining, but it would not be of much use.

Public services

Such as GitHub, SourceForge, Bitbucket, etc. Those are actually handy for hobby projects, though GitHub will probably look in a decade as SourceForget looks now: those fancy things don't seem to last long, though GitHub has plenty of apparent flaws even now: particularly in UI, and being centralized. Still, GitHub is used by plenty of rather large and nice projects as their primary BTS (and hosting, too). Perhaps it is worth highlighting Bitbucket (and Atlassian in general), where every tiny bit is terribly broken, and it'd keep spamming you if you ever [manage to] register there; extremely frustrating, and a few different feedback mechanisms are also broken.

Trac

Python, 3-clause BSD. A somewhat minimalistic system. Does not support multiple projects nicely (single-project system hacked to host more than one project), features are rather limited, not that easy to deploy properly. Though deemed good enough (and used) for large projects such as GHC.

Bugzilla

Perl, MPL. Seems to be nice for larger projects such as GNOME, but perhaps not so nice for using in a relatively small company (or small hobby projects). User interface is not that handy. Apparently a nice and solid system overall, yet I am just avoiding it. Though as of 2020, there's a new UI full of private use unicode code points, and partially broken functionality without JS.

Redmine

Ruby, GPLv2. Many features out of the box, pretty nice overall. Though markup is not good, mail notifications (their headers, in particular) are a bit broken for a long time, and it is rather hard to deploy properly.

roundup

Python, MIT. Supports email seemingly well, the web interface is quite clean and simple, JS-free, has fine documentation, relatively easy to install nicely. Though apparently the documentation is outdated: pointing out that it is in Debian repositories, while it is not anymore (well, it is in oldstable), and the last release at the time of writing (2017-11-30) is almost two years old. Hence no automated security updates and awkward manual installation; risky to deploy overall.

debbugs

Mostly Perl, GPLv2. Very lightweight web UI, mail-only updates, actively used and maintained for 23 years now. Same issues as with most of the BTSes though: not in repositories, rather cumbersome manual installation, configuration, and maintenance. debbugs git repository is perhaps the primary source for its documentation (and sources).

GitLab

Ruby, Go, JS; MIT for the community edition. Sluggish JS-based UI (as of 2022, pretty much unusuable in Firefox, though was very slow for years before that too; apparently it uses the Vue.js framework) with annoying animations, suggested installation method involves curl | bash, the website is full of marketing texts and broken markup with little focus on technical details, only minimal mail integration. Quite bloated, includes a CI service. Not sure why, but seems to be pretty popular at the time of writing (the end of 2018, and still so in the end of 2025). Though it's rather a software forge, not just a BTS. In 2025, I tried setting it; found that its official Debian package includes PostgreSQL, nginx, Ruby, and so on, installing everything into /opt/gitlab/, and taking 4 GB of disk space. The Docker container is similar, and each takes 4 to 5 GB of main memory. It also takes a minute or few to restart, or to reload the configuration. The configuration itself and debugging are a pain: it is a large and oddly behaving system one has to deal with, not a single documented program.

public-inbox

Perl, AGPL-3.0+. Similar to a mailing list archiver, but git-based: instead of server sending messages to subscribers, subscribers are supposed to pull it (via NNTP, Atom feed, WWW, or to mirror it as a git repository). I haven't tried to use it beyond reading archives produced with it, but it looks nice.

Forgejo

Go and JS, MIT. A fork of Gitea (MIT, for-profit since 2022). Appears to be a reasonable option and fairly popular, as of 2024. Consumes notable server resources, says that it requires JavaScript (though seems to work fine for basic usage without that). Relatively easy to setup with its official package (including nginx reverse proxying, use of local postfix to send mail, use of a local OpenSSH server), and it is distributed as a single (though bloated) binary. In the end of 2025, its fresh installation takes about 170 MB of main memory, which seems excessive, but much lower than that of GitLab.

Others

There is much more in the Wikipedia Comparison of issue-tracking systems and Comparison of project management software. Most of those are pretty bad.

Common issues

• Installation, configuration, maintenance: for some reason issue tracking systems are among the worst kinds of software in that, competing with mailing list management and archieval software.
• Flexibility and accessibility versus shiny things: as with other communication-related software, some want the UIs they can configure and improve (e.g., email interfaces, FLOSS), and others want them to be all shiny (e.g., fancy visual effects and pictures, often JS-based; possibly integrations with smartphone things and other trendy stuff); those two rarely fit together. There's no fundamental reason why such software can't have multiple UIs, but usually it doesn't.
• Extensibility: this may be unnecessary, and often gets awkward, but in some cases it is handy if a BTS can be extended to assist particular workflows. Language-agnostic extension mechanisms are uncommon.
• Migrations, interoperability: usually changing a BTS means losing all the collected information, or at least not getting it on a new BTS.

Other approaches

Common models and gateways

There are various attempts to integrate different programs and protocols (e.g., by using common models provided by RDF ontologies such as SIOC, all kinds of APIs and gateways), but they are not used any widely.

Distributed issue trackers

There are less common issue trackers that are distributed, like bugs everywhere and git-bug. Perhaps worth trying, the description looks nice. ikiwiki can be used as such a system, in addition to having a web interface for reading, search, and editing. Simply a set of files (possibly hypertext-capable: org-mode, HTML, etc) may work, too.

TODO files and email

That's what I'm using the most, and perhaps it is the most reliable and simple way to manage tasks. Journaling can be used together with it or as an alternative. In my experience, over the years people occasionally ask to use some issue trackers, the ever-changing centralized IMs, voice calls, and/or just meet; those conversations are lost to email message archives, but can still be summarized in journal/TODO files. That's additional work, but helps to ensure that you have everything important written down, in one place, ready to be found when needed.