Thunderbird 2020 Financial Report
groups.google.com
groups.google.com
Honest question: What are these people actually doing? I haven't seen new features since a long time, but Thunderbird seems to have reorganized one year ago (https://blog.thunderbird.net/2020/01/thunderbirds-new-home/), so they probably plan something big, like a rewrite of the software?
17 years ago, a Mozilla engineer called it "the single most braindamaged file format that I have ever seen in my nineteen year career".
Sadly they only mention it in passing (it's blocked by global indexing).
Thunderbird is slowly becoming less dated, but I'm not sure Gmail's UI is necessarily what email client designers should be aspiring to. The former lead designer of Gmail (and Inbox) hated it so much that he has put hundreds of hours into maintaining personal modifications. Now that's he's trying to turn it into a business, the marketing site is a bit more original and there's fewer strongly worded criticisms but I'm sure you can read between the lines [3].
[1] https://addons.thunderbird.net/en-US/thunderbird/addon/gmail... [2] https://addons.thunderbird.net/En-uS/thunderbird/addon/threa... [3] https://simpl.fyi/
Maybe they will pull it off with just gecko, that would be neat.
[EDIT] "but it's already XUL!" right but XUL-based GUI programs can run great on machines without enough memory to use Slack or VSCode without hitting swap, even if those were the only programs open. My source for this: I've been using XUL apps since the days when machines with 128MB of system memory were pretty damn high-end. They were kinda heavy back then, but basically fine. They're straight-up lightweight by today's standards.
That's not a problem I recall encountering in the days of Firefox 2.0.
I guess it's too much to ask companies not to implement websites that leak memory.
2) I'd prefer software just, you know, not be bad. Safari, for all its problems, demonstrates that there's nothing inherent in a modern desktop web browser that requires it to be grossly inconsiderate of your system resources.
I remember these days clearly because Firefox 1 was very fast and it displaced Mozilla (what was later called "Mozilla Suite") as the main browser for the Mozilla Foundation exactly because of that performance benefit. However Firefox 2 not only ended up becoming much slower but Mozilla Suite actually became faster and ended up being faster than Firefox despite providing not only a browser, but also a mail client, news client, WYSIWYG editor, IRC client, etc - ie an integrated "internet client".
At the time i liked Mozilla more than Firefox so i was bitter about it and how it was eventually abandoned by Mozilla Foundation (it became Seamonkey, sure, but that is another story).
IE6, on the other hand, would be usable in less than 10 seconds from launch. Granted, it probably got preloaded by Windows, but even Windows took less than 5 minutes.
Right, but even XUL has grown quite a bit since those days - not to mention that it's pretty much dead at this point. Still, something other than "yet another desktop app built around some descendant of KHTML" would be nice.
There are basically four ways this could go:
1. Thunderbird spearheads a Gecko-based alternative to Electron (following Firefox in deprecating XUL)
2. Thunderbird throws in with the various XUL-preserving Firefox forks to maintain XUL as a Gecko-based alternative to Electron (since the Firefox folks don't seem to have any interest in doing so)
3. Thunderbird switches to some native-widgeted toolkit like Qt or GTK
4. Thunderbird switches to Electron
These are in order of my preference. Option 1 also thankfully seems to be Thunderbird's current direction, though it'd be nice if it could spearhead the necessary documentation and niceties for other applications to use Gecko in desktop apps.
I used Mozilla (the original) on my Pentium MMX with 128MB of RAM and i remember it being so slow i could literally watch the widgets draw themselves one after another whenever i opened a dialog window.
I don't mean this to be dismissive, I mean that EWS is a massive moving target that will require a significant allocation of resources that would, IMO, be better spent on other things.
The major features that have come out lately that I've noticed are first-party calendar integration and first-party GPG support. There was a calendar integration but I always found it to be a bit funny and hard to get working all of the way. I never had problems with Enigmail, however.
Both features work much more solidly as an included part of Thunderbird. There are other, smaller features that have come in like having e-mail addresses in the To/CC/BCC lines be places into ovals to show them as a distinct, drag-able element.
The Thunderbird codebase is old and is full of a ton of features, transforming it in a way that is true to its past and moves towards a better future is going to take time but it is coming along. Sure, some of the major features were available as plug-ins but they're much more solid now that they're built-in.
Those seem pretty close to upstream, however. I got an update for it just last week.
All of that said - I'm replying to this message and not the other because there is one use for secure e-mail that may make a difference: DeltaChat. Deltachat uses autocrypt which includes your public key in headers. With autocrypt in place, Thunderbird can still read DeltaChat messages.
I'm not sure if DeltaChat will ever take off in large numbers but it seems like a decent option for secure chat/IM.
Well, since everybody is using Gmail or Office365 anyway, encrypted email is kind of pointless, no?
This is so ridiculous. I have to log in to a dozen different sites to download documents. And those sites are 2FA secured, so I have no means to automate. Of course these companies never heared of (REST) APIs. - This is such a step backwards.
I know it's for liability reasons, but annoying nontheless
I haven't had to work with encrypted email for a little bit, but I think the next time I do it'll push me to another email client if I still haven't gotten this working.
This is very tricky.
Thunderbird keeps breaking addons compatibility (as an end user, I don't care if this is justified or not), by supporting main versions for short times (v68 was released less than two years ago).
An O/S like LTS Ubuntu, which has a 4+ years support cycles, is systematically forced to break TB compatibility during each cycle, which is contrary to the O/S versioning guidelines (which typically freeze the program versions, with the exception of security upgrades, e.g. web browsers).
As a side effect, addons, which give TB a significant value (I'd argue that they give its only value - even Google Calendar is not natively supported) slowly disappear.
Thunderbird is essentially systematically and forcefully breaking versioning and compatibility. I believe something's broken in the team/company.
Alternatively, and not so good, the other answer is to maintain shims or back-ported APIs for some duration as downloadable add-ons that extensions could use. You could add existing extensions to a giant test-suite that ensures common extensions don't break.
You could combine all these approaches, of course. Personally, I'd push to have common community add-ons maintained centrally though, such that if they change an API and it's a relatively easy fix, project maintainers could automate a "code-mod" or fix to rename and use the new API, or shim support for the old API? It's not easy, exactly, it requires taking ownership of a community to such an extent that you can ship API changes as useful codemods to help automate community porting efforts.
That said, I've often found that even if plugin APIs don't change, requirements to list compatible API versions in plugin manifests can make it hard to use new plugins until app authors can get around to updating the manifest to a new version and ensure compatibility for their extension. It might be interesting if app or extension stores could run tests to confirm if a plugin is compatible or not and if not, maybe suggestions could be made to point projects to new APIs and porting guides, if not outright automated PRs for fixes?
If I understand correctly, this is what they're actually doing. From https://developer.thunderbird.net/add-ons/updating/tb78:
> Knowing that following the proper migration strategy is not easy, we created two wrapper APIs which do not require all of these changes. Using these APIs, you can quickly get your add-on running in Thunderbird 78 again, but you will not get the benefits of a MailExtension. The idea behind this is to make add-ons compatible with the current ESR as quickly and easily as possible, so users can continue to work with their beloved add-ons.
Per se, this would be a sensible move. However, in the bigger picture, the plan starts to show its pointy-hairedness:
> While the Thunderbird team plans to add more APIs with upcoming releases, the current set of APIs will not be sufficient to port most add-ons. To work around this limitation, add-ons can introduce their own, additional APIs as so-called Experiments [...] [which] are expected to require updates for each new version of Thunderbird.
In other words, the TB team, for unspecified reasons (it's not clear if they were really forced to move to MailExtensions), has broken compatibility with the previous versions of the addons, and provided half-baked APIs which are expected to break again in the future.
Other mind-numbing pointy-hairedness:
> [...] If you follow this strategy, you will end up with a future-proof MailExtension that will require substantially less maintenance work for future versions of Thunderbird.
They're saying in a single sentence that updated addons won't require changes in the future (being "future-proof") _and_ that they will require them.
===
All in all, I have the strong suspicion that Thunderbird is very incompetently developed/maintained, but I'd be very happy to be proven wrong (with technical arguments).
- Basic IMAP/POP3 client
- with GPG integration
- without global indexing (I use simple searches)
and in the entire TB history, I can't remember anything that significantly changed the usage of the above.
What I remember though, is that, even with lack of resources, at some point they added a chat client!!!
E.g. the virtual identities extension now is a first party feature.
I still use KDE as a desktop environment and while I think Kmail looks better, Thunderbird just works so much better (e.g. faster, better RSS integration, better search results) that I am quite happy that I switched.
at least they are not doing what gmail engineers are doing and changing the interface every few months for no good reason...
The one thing I'm currently looking forward the most is multi-process support, planned for Thunderbird 91, IIRC; It should relieve the hangs I sometimes get (having >50 GiB mails locally has its tolls, but oh well LKML, QEMU, ... archives and such are just nice to have around for me).
I've changed the advanced settings and set a minimum font size, and it has no effect. You can zoom in when you're looking at an email, but the results are inconsistent from email to email.
With Claws Mail I get the same font size every time.
If anyone knows how to set this up properly, I'd give Thunderbird a try again.
I realize this would probably require a complete re-write.
The closest I can do to that now is a much more cumbersome solution involving something like a bare bones xfce4 desktop environment, the Linux thunderbird client, and VNC-over-SSH or apache guacamole.
Thinking they've done some interesting updates since then, I tried it again recently, in February 2021.
I was disappointed to find a sluggish client with worse UI than it had 8 years ago, defeating the entire purpose of having a desktop email client on a powerful machine. Maybe it was some default settings or whatnot, but I didn't feel like digging around to fix it and there was no advantage in using it over the default Gmail web client. RAM usage was not light either. It all seemed like some weird poor UI wrapper around an Electron instance that just loads the Gmail client.
I ended up going back to Opera Mail - a lightweight desktop email client from 2016, that unfortunately isn't getting updated anymore.
Not sure what the use case is for that type of software anymore. It didn't feel like a real desktop client.
1. Why is there no Thunderbird for Android? It's the only project that I trust with my emails on my phone.
2. What do Android users use as an email client on their phones?
I current cannot access email on my phone. Maybe it is better this way, security wise. But if Thunderbird was available for Android I might consider using it.
Hey, does that mean we can have two lines per mail in the mail column :) ?
Otherwise, I am not convinced by matrix integration. Unless it's a deep one and creates new scenarios impossible with two standalone applications.
Another question is: there's no HTML tree component.
I didn’t see a HR person listed on staff, so it’s probably just easier to use a third party service to handle all of that.
Does it mean it will be slow? Does it mean it is basically based on Node.js?
I use this Client since 2000 (on Windows) and due to problems with my computer in the beginning, i use it the PortableApp.com Version of TB more than 10 years. My Mail-Archive (only important mails) is beginning in the year 2000, the whole TB-folder has a size of 1.33 GB.
TL;DR; I use TB and TB Portable over 20 years and have an actual folder size of 1.33 GB. No unsolvable problems in this time. I make heavy use of the RSS-Reader, too. Therefore i use uBlock Origin for TB.
Did you read the financial report at all?
TB has had the embarrassing Mork backend for ages (took around 14 years to fix; it's not in the released version yet). And the codebase is so tangled that nobody has been able to convert the email writing window into a tab. One window!
Even ignoring the above, the addons compatibility keeps breaking. AFAIK that's a necessity, but as an end-user, the result is an increased alienation from the product.
Ultimately, Thunderbird without addons is an unremarkable product.
Switching between windows is easy using alt-tab. Switching tabs requires one to do something like ctrl-pgup/pgdown or alt-number if you know the tab number. Personally, I think using alt-tab is a lot easier to switch between the compose and overview windows.
Since it's spin-off it's been developed at breakneck speeds to desperately bring it up to par with modern Firefox (they share back-end technologies) in order to make it's development more sustainable and predictable. Unfortunately this has been a strain on add-on developers like myself. I was maintain the lookout TNEF parsing plugin however due to the pace of the changes and an increase in lack of time I'm now only putting out small fires
I'm sure it has issues - heck, I've even filed bugs against it personally - but your comment doesn't at all resonate with my experience as a user.
The open bug I linked above is 13 years old, so maybe it isn't.
I know of some that I trust not to lose my mail. I know of some whose bugs don't worry me as much as stuff like this:
https://bugzilla.mozilla.org/show_bug.cgi?id=462156
> your comment doesn't at all resonate with my experience as a user.
Okay? I just assume that you don't believe nobody loses data to this program simply because you have not lost data to this program.
Much easier to backup if your email is in one place and running even a local IMAP server is better than storing it in an email client.
The 13-year old bug I linked to involves IMAP mail handling, I believe. I haven't dug too deeply into these bugs because, honestly... I'd like to be able to use Thunderbird for a couple of things, but mail handling doesn't need to be very screwed up for me to avoid the program. A 13 year old bug involving data loss is enough to make me avoid the program, even if it would not appear to effect my use case.
> Haven't lost anything
I guess I can understand how others might view it as "just email." I won't argue with the implied "I've never lost data to this program so it must never happen" argument, but I wonder how you know you've never lost anything. I feel like I'm capable of not noticing a data loss bug involving email, or not noticing until I need something and it is not there.