We are busily adjusting our fixes and features to the new Thunderbird 153 code base as outlined in this article. When working on the "attachments on top" feature for both message display and compose window, we noticed that icons for certain documents are no longer displayed next to the attachment name in using the 153 code base. This also happens in other parts of the system, like here, in the Downloads Manager:
We did a bit of digging in Thunderbird's bug tracker, and lo and behold, found this ticket.
So a regression introduced in Thunderbird 141 which was shipped in July 2025, about 10 months ago. Finally, users noticed and headed to the support forum in November 2025, from where a volunteer filed the ticked we mentioned, also in November 2025. And what did the developers do? They shrugged their shoulders and left the software broken, until yesterday when two volunteers miraculously started showing some activity.
So where is QA to detect such failures before users do? Where is the management that monitors clearly visible regressions? Where is the management who assigns a developer to get the issue fixed? Where is accountability?
Ten years back, the Thunderbird project was run by some volunteers, who contributed as their personal circumstances allowed. The then chairmen of the chairman of the Thunderbird Council used to refer to the team as a "pack of cats" (although the correct term is "clowder of cats"). So with 50+ staff and millions of dollars at their disposal, what has actually changed in the attitude of those running the project?
Old and annoying 20+ year old bugs seem the be exclusively addressed by volunteers, and from them we heard questions and statements like:
- Why do [old bugs] have such little priority that I can find 20 year old low-hanging fruit?
- If I were running the shop, there would be a freeze on new internal features [...] and a systematic revision of all bug reports.
Well, good luck with 16.000+ open tickets. BTW, here is what AI had so say about so-called bug rot:
“Bug rot” is the gradual degradation of a bug tracker’s usefulness as unresolved issues accumulate faster than they are properly triaged, resolved, or retired. Over time, a large backlog—often spanning years or even decades—mixes active defects with obsolete reports, duplicates, unreproducible issues, and context that no longer matches the current codebase. This creates a system where the signal-to-noise ratio steadily worsens: important bugs are harder to identify, prioritization becomes less reliable, and contributors increasingly rely on informal knowledge rather than the tracker itself. The result is not that the project stops working, but that its issue tracker shifts from being a precise engineering tool into a partially archival, partially operational database whose meaning becomes progressively harder to interpret.
Fun fact: Paid Thunderbird staff approach those volunteers asking them to take on further bugs. That's true Mozilla exploitation culture. All those volunteers are part of the business model that counts on highly skilled people to work for free. Of course there are lots of honourable mentions, and some of them even get a free T-shirt. Our project leader used to be one of them, he still has two Mozilla T-shirts. And he usually says: Look at this T-shirt, it's worth about $50,000 of labour.