The future of Thunderbird [LWN.net]

Rewriting ancient code

Posted Feb 9, 2023 17:41 UTC (Thu) by abacus (guest, #49001) [Link] (33 responses)

It is not clear to me why it has been decided to rewrite ancient Thunderbird code? Other projects follow the guideline "if it ain't broke don't fix it".

Rewriting ancient code

Posted Feb 9, 2023 18:01 UTC (Thu) by cyperpunks (subscriber, #39406) [Link] (2 responses)

For me the required feature set in a MUA was completed at least 15 years ago, still TB need to change each month going forward?
Why?

Rewriting ancient code

Posted Feb 10, 2023 11:30 UTC (Fri) by bluss (guest, #47454) [Link] (1 responses)

Isn't it a quite superficial question?

It's their software project and this is how they want to structure it, it's the process they want to use. It suggests a type of continuous delivery model instead of working up to big releases, missing deadlines, and moving release dates. Nothing says that there needs to be big changes every six weeks, it's just a new release, big or small.

It sounds like they were inspired by Rust, which has been running on a six week release schedule since 2015(!), and not every Rust release brings anything major. Nothing in programming languages says it's important to have a new change out quickly. It's just a productive and useful process to follow.

Rewriting ancient code

Posted Feb 23, 2023 13:10 UTC (Thu) by mrugiero (guest, #153040) [Link]

Isn't it quite a superficial answer, too?

More seriously, the question is not whether or not the team has the right to do so, but whether or not it is a good idea. Which the 6 weeks release model is (not so a rewrite, IMO). Even if the MUA feature set is complete (which it isn't, as standards have changed), bugs will always exist. Because they exist, you as a maintainer are left with three choices:
- Do a release whenever a bug is fixed. Impractical for most people, not limited to dev but also packagers and users.
- Do a big release whenever you have a big batch of fixes. Practical for the dev, but annoying for the people waiting on a fix.
- Do time based releases, preferably at what you consider a sweet spot between your own effort and the UX in terms of how much I need to wait to see my problem fixed.

On the rewrite, it's most often a bad idea to do a big rewrite, specially if the reason is just tech debt. Your rewrite will also have tech debt while also losing treatment of many edge cases you and others found along the way. Plus, it may never ship or just come late to the party when everybody already moved on. Some people in my environment actually think both divesting effort into Rust and trying to gradually rewrite Gecko is what lead to the big loss of market share for Firefox in the past. I only partially agree, but it's true it was a little too late for some things and it may have been more pragmatic to focus on fixing existing code instead.
Improving and modernizing the UI, on the other hand, is sensible. Focusing in what the user will perceive is most often the right approach, and we geeks and people with engineering/programmer mindsets tend to forget it. The whole point of software is to satisfy the user, not to make code pretty.

Rewriting ancient code

Posted Feb 9, 2023 20:28 UTC (Thu) by lostwizard (guest, #57225) [Link] (28 responses)

It's not so "ain't broke" as it might seem. There's a lot of stuff that works most of the time but occasionally goes weird or behaves in a less than ideal fashion. It's very likely that much of that is due to the ancient code (or "technical debt") that "ain't broke". Basically, there's almost certainly plenty of room for improvement on the technical side of things.

Rewriting ancient code

Posted Feb 9, 2023 20:55 UTC (Thu) by ggiunta (guest, #30983) [Link] (8 responses)

I just watched the video on the TB blog's announcement, an I must confess I am more dubious than excited.

Technical debt? Hell yeah, any codebase decades-old is bound to have a huge amount of that. Bring on the refactoring!

UI debt? This is definitely more controversial....
Any decades-old application is bound to have reams of users who internalized all its quirks and will be completely upset and unwilling to accept even the slightest change. UI is the bike-shedding topic par excellence for open-source geeks. Just ask the Firefox devs...

For sure, the current UI is inconsistent as hell. The Calendar component is way less functional (and more ugly) than what Google manages to do in pure JS. The AddressBook looses out big time when compared to managing the data in a huge spreadsheet. The chat... I have no idea - I never used it ;-)
But email management? I think that was nailed years ago. And that's what every current user is most likely afraid of - seeing the cherished mail-management experience be dumbed down to the levels of, say, Gmail or android clients.

And, monthly releases: how can someone think it is a good idea, for a mature product? The only reason I can think of that being necessary is if A) there's a constant stream of security issues being found, or B) the devs expect to be trashing around a lot the UI and functionality. Is that what users really want?

Back on the topic of the video: for all the declarations that it contains, of love for the community and for the product, it reminds me strongly of similar situations I lived through with other OSS projects, when new UI experts and Product Managers were brought onboard who, for all their good will, were clearly less competent than the unruly/incoherent/unvisionary bunch who preceded them, but were too stubborn and proud to acknowledge it, and tanked the product hard.
I guess many people around here will have got similar "gnome devs" vibes...

Rewriting ancient code

Posted Feb 9, 2023 21:37 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

And, monthly releases: how can someone think it is a good idea, for a mature product?

If nothing else, Thunderbird includes Gecko, which is constantly being updated. They would probably need to release on a regular schedule just to make sure users are getting an up to date version of that, even if they didn't have their own fairly ambitious plans for changes to the rest of the program.

Rewriting ancient code

Posted Feb 23, 2023 13:14 UTC (Thu) by mrugiero (guest, #153040) [Link]

As a counter point, the concerns of a mail client are often of more reduced scope than those of a browser. The security ones are the same (do HTML emails allow JS? I don't know, but if they do you're running potentially untrusted code), so sandboxing does justify the same degree of effort. However, you don't need to be so strict, for example, with performance. Honest emails tend to be rather lightweight compared to full fledged websites. So, maintaining Gecko (or even using a simpler engine, but that only applies to rewrites and the like) may take less effort because you're not making all that parallelization work and what not that Firefox desperately needs. You just need to fix bugs that appear and probably keep CSS up to date or stuff like that (which is obviously non-trivial anyway).

Rewriting ancient code

Posted Feb 23, 2023 13:30 UTC (Thu) by mrugiero (guest, #153040) [Link] (5 responses)

> Technical debt? Hell yeah, any codebase decades-old is bound to have a huge amount of that. Bring on the refactoring!
>
> UI debt? This is definitely more controversial....
> Any decades-old application is bound to have reams of users who internalized all its quirks and will be completely upset and unwilling to accept even the slightest change. UI is the bike-shedding topic par excellence for open-source geeks. Just ask the Firefox devs...

Quite the contrary, open source geeks focus too much on tech debt and too little on making sensible UI/UX choices. In fact, your own comparison with GNOME is evidence of this: GNOME is one of the most corporate (and thus client focused, because that's what makes money) led DEs we have. It's often called a Red Hat project, even. Compare that to everything community led and see how often those change. The only real example I can think of is when KDE switched to Plasma. Otherwise, everything looks and feel more or less the same than it felt 15 years ago. Even with Wayland, most compositors are more or less clones of some existing X11 window manager rather than something completely new. Open source geeks surely like their UIs to stay the same over time.
Regarding users who internalized the quirks, maybe some projects are interested in actually attracting _new_ users that have higher standards than adapting themselves to software. Software is meant to serve the user, not the other way around. Only geeks and people with very specific needs (e.g. privacy conscious not trusting the proprietary alternatives with better UX) are interested in sacrificing usability to serve the whims of a decrepit email client.
Firefox didn't lose the browser wars because it changed UI, it lost way before that. It lost the browser wars because of several other factors, one of them being too static to catch up with the competition. The change was probably good except for power users, but it came too late.

> For sure, the current UI is inconsistent as hell. The Calendar component is way less functional (and more ugly) than what Google manages to do in pure JS. The AddressBook looses out big time when compared to managing the data in a huge spreadsheet. The chat... I have no idea - I never used it ;-)
> But email management? I think that was nailed years ago. And that's what every current user is most likely afraid of - seeing the cherished mail-management experience be dumbed down to the levels of, say, Gmail or android clients.

You say this as if dumbing down is really that bad. Those clients are, apparently, _very_ _practical_. Thunderbird was always meant to be for the general user. If it allows for configuration, extensions, or whatever mods for power users to suit their needs better, then great. If it doesn't, then find something aimed for power users. But if you aim for general public, your defaults should be what a regular user would expect. And most users don't cherish their mail management experience, they mostly see it as a tool that needs to get out of the way as soon as its work is done.

> And, monthly releases: how can someone think it is a good idea, for a mature product? The only reason I can think of that being necessary is if A) there's a constant stream of security issues being found, or B) the devs expect to be trashing around a lot the UI and functionality. Is that what users really want?

People don't like waiting 6 months for a trivial but annoying bug to be fixed.

> Back on the topic of the video: for all the declarations that it contains, of love for the community and for the product, it reminds me strongly of similar situations I lived through with other OSS projects, when new UI experts and Product Managers were brought onboard who, for all their good will, were clearly less competent than the unruly/incoherent/unvisionary bunch who preceded them, but were too stubborn and proud to acknowledge it, and tanked the product hard.
> I guess many people around here will have got similar "gnome devs" vibes...

Unvisionary is probably good, visionary is risky and it could end well or it could end miserably. Visionary can also be reverted if failed, tho, while unvisionary will always remain static.
The other qualities tend to do poor UX. I dislike PMs just as much as the next programmer, but UI experts exist for a reason. Programmers tend to write code for other programmers in the best case, and for the code itself in the worst case. That doesn't lead to something most people will want to use. Just look at most TUI MUAs and how many users (even among geeks) they have compared to Thunderbird or webmails or Outlook. Sane defaults and a little bit of usability could make it at least an order of magnitude more popular than they are today, but leets gonna leet.

Rewriting ancient code

Posted Feb 23, 2023 15:54 UTC (Thu) by pizza (subscriber, #46) [Link] (4 responses)

> You say this as if dumbing down is really that bad. Those clients are, apparently, _very_ _practical_. Thunderbird was always meant to be for the general user. If it allows for configuration, extensions, or whatever mods for power users to suit their needs better, then great. If it doesn't, then find something aimed for power users. But if you aim for general public, your defaults should be what a regular user would expect.

The "general user" will just use gmail (in-browser or phone app), outlook (desktop, in-browser, or phone app), and so forth.

The only ones left using something like Thunderbird are so-called "power users" and folks that started using it a decade or two ago and don't want _anything_ to change. And the needs of those two groups are nearly diametrically opposed.

Rewriting ancient code

Posted Feb 23, 2023 16:38 UTC (Thu) by mrugiero (guest, #153040) [Link] (3 responses)

> The "general user" will just use gmail (in-browser or phone app), outlook (desktop, in-browser, or phone app), and so forth.
>
> The only ones left using something like Thunderbird are so-called "power users" and folks that started using it a decade or two ago and don't want _anything_ to change. And the needs of those two groups are nearly diametrically opposed.

Which may very well be a case of cause and consequence :^)
If Thunderbird keeps being unsuitable for common folk, of course common folk won't use it.

Rewriting ancient code

Posted Feb 23, 2023 16:58 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

The problem there, is that if the common folk have never experienced anything other than webmail, they'll be perfectly happy. My first (combined news and) mail client was Turnpike, and half the features that disappeared when it was scrapped, have never appeared anywhere else that I know of.

Things like regular expression mail header parsing and filtering. I'm sure that's probably available in things like mutt and milter and esoteric :-) mail processing tools, but Turnpike was a simple, easy-to-use client with all this power lurking just below the surface. And it drew you in - you started using the simple features and thought "hey that looks nifty", and next you knew you were digging into this cool-looking power feature. Bit like WordPerfect really.

Nowadays either these features don't exist, or they're so undiscoverable nobody realises they're there until they are broken for lack of use ... :-(

Cheers,
Wol

Rewriting ancient code

Posted Feb 24, 2023 9:22 UTC (Fri) by smurf (subscriber, #17840) [Link]

> The problem there, is that if the common folk have never experienced anything other than webmail, they'll be perfectly happy

until they need to switch webmail providers – and realize that half their accounts won't work anymore and can't be switched over because the confirmation email is sent to the old address.

In other words, returning control of their email back to users is a matter of education and awareness, not of whether Thunderbird is built on top of Gecko or Webkit.

Rewriting ancient code

Posted Feb 23, 2023 18:27 UTC (Thu) by pizza (subscriber, #46) [Link]

> If Thunderbird keeps being unsuitable for common folk, of course common folk won't use it.

"common folk" won't ever use Thunderbird, because it represents a completely different paradigm to everything they've ever experienced, and there's no way to meaningfully bridge that gap without defeating the entire purpose of using it to begin with.

In other words, to appeal to the "common folk" Thunderbird would have to become yet another hosted email service, accessible via a web site (possibly with a "desktop app" aka electron wrapper for the web site) or mobile app that can only talk to the Thunderbird servers. Oh, and it would have to be completely free, because who pays for email anyway?

You might as well be saying "Bananas should make themselves to be more like oranges, so that folks who like oranges will
want to eat bananas."

Rewriting ancient code

Posted Feb 9, 2023 22:01 UTC (Thu) by Vipketsh (guest, #134480) [Link] (18 responses)

On the flip side my experience tells me that any code which works, even with a lot of bugs, has a lot more effort behind it than anyone can imagine. The result is that a rewrite which seemed to be so easy at first ends up hardly functional after more than a year of work. Sure, there are times when things need to be thrown out for the better, but something large and complex like a UI is bound to take years and end up with a whole bunch of bugs and missing features until it is even initially useful. A few more years until it can be used without going crazy.

A few wonderful examples to learn from: Gnome 2->3, KDE 3->4, X->Wayland (about *10 years* to start being usable).

Rewriting ancient code

Posted Feb 9, 2023 22:26 UTC (Thu) by cyperpunks (subscriber, #39406) [Link]

> The result is that a rewrite which seemed to be so easy at first ends up hardly functional after more than a year of work

Indeed, and when the product finally works as it should after a decade of work, the entire thingie is seen as technical debt :-)

Rewriting ancient code

Posted Feb 10, 2023 12:45 UTC (Fri) by rschroev (subscriber, #4164) [Link]

And Netscape 4 -> Netscape 6, which Joel Spolsky used as an example in his take on why you should not rewrite from scratch (https://www.joelonsoftware.com/2000/04/06/things-you-shou...).

Rewriting ancient code

Posted Feb 13, 2023 13:08 UTC (Mon) by rsidd (subscriber, #2582) [Link] (12 responses)

Wayland isn't a rewrite of X, any more than Android SurfaceFlinger or MacOS Quartz is a rewrite of X. It is a completely different way of doing things.

Rewriting ancient code

Posted Feb 13, 2023 13:45 UTC (Mon) by dskoll (subscriber, #1630) [Link] (11 responses)

It's true that Wayland is not a rewrite of X, but it is intended to replace X. As such, it needs to do a bunch of things that X currently does (though it does them in quite a different way.)

Rewriting ancient code

Posted Feb 13, 2023 14:49 UTC (Mon) by Wol (subscriber, #4433) [Link] (10 responses)

Wayland is, in spirit at least, X13. It can't claim to be X12, something else has claimed that.

Cheers,
Wol

Rewriting ancient code

Posted Feb 23, 2023 13:34 UTC (Thu) by mrugiero (guest, #153040) [Link] (9 responses)

I always love your historical knowledge. With something else claiming X12 you mean the one next version of X that never materialized, or was there another project that took the name?

Rewriting ancient code

Posted Feb 23, 2023 16:03 UTC (Thu) by Wol (subscriber, #4433) [Link] (8 responses)

Yes I meant the version that never materialised.

Can't remember where I got the information from, but I was discussing X, Wayland, and network transparency iirc, probably here on LWN! Probably from someone in Wayland.

Cheers,
Wol

Rewriting ancient code

Posted Feb 27, 2023 19:57 UTC (Mon) by nix (subscriber, #2304) [Link] (7 responses)

The only references I can find to it on LWN are from you, so it's not there.

(I am not aware of an X12, FWIW. But I'm just a random nobody.)

Rewriting ancient code

Posted Feb 28, 2023 1:48 UTC (Tue) by mrugiero (guest, #153040) [Link] (6 responses)

I think all of us mean this: https://www.x.org/wiki/Development/X12/

It never got to a proper planning phase, but was just some discussion as to what a successor for X11 would require. Eventually the people involved (I think) ended up creating Wayland instead. From what I gather, the name was just to mean "what's next from X11" rather than actually an official successor.

Rewriting ancient code

Posted Feb 28, 2023 11:10 UTC (Tue) by paulj (subscriber, #341) [Link] (5 responses)

So Wayland essentially is X12, so far as implementation goes.

Rewriting ancient code

Posted Feb 28, 2023 12:12 UTC (Tue) by jem (subscriber, #24231) [Link] (3 responses)

>So Wayland essentially is X12, so far as implementation goes.

I really don't recognize Wayland in that text. The first part is a list of general requirements, nothing specific to X or what Wayland was to become. The latter part is just a list of X11 limitations, like "XIDs are too small", "[X11 protocol] extension space is too small", "Strings for [X11] Atom names", and so on, none of which have any meaning for Wayland.

Rewriting ancient code

Posted Feb 28, 2023 14:27 UTC (Tue) by Wol (subscriber, #4433) [Link]

I think that's why Wayland isn't X11.

X11 has fundamental design flaws in an insecure world, and having "designed" X12, they presumably decided they couldn't evolve X, so they took all that into account and started again.

Cheers,
Wol

Rewriting ancient code

Posted Feb 28, 2023 14:30 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

Yeah, that doc seems very X11 centric. Hence my "in implementation" qualification.

Rewriting ancient code

Posted Feb 28, 2023 14:31 UTC (Tue) by paulj (subscriber, #341) [Link]

I.e., the next protocol after X11 is Wayland, effectively X12.

That there exists a very early planning document in that process, a very incomplete wiki doc, that viewed the future in an X11 context, doesn't mean Wayland is not that next protocol after X11.

Rewriting ancient code

Posted Mar 1, 2023 20:30 UTC (Wed) by mrugiero (guest, #153040) [Link]

That's a bit what I meant, although the phrasing was a little poor on my side. Rather than "ended up creating Wayland" I should have said "it was different enough that they chose to call it Wayland". In part I kept ambiguous due to laziness, I didn't want to check whether the exact same people was involved.

Rewriting ancient code

Posted Feb 19, 2023 20:24 UTC (Sun) by ssmith32 (subscriber, #72404) [Link] (2 responses)

Just because something took ten years to complete doesn't mean it was the wrong decision.

Rewriting ancient code

Posted Feb 19, 2023 20:44 UTC (Sun) by smurf (subscriber, #17840) [Link]

Nobody said it was.

However, the adage "to convert an estimate to something realistic, multiply by two and go up one order of magnitude" certainly holds true.

Rewriting ancient code

Posted Feb 23, 2023 13:36 UTC (Thu) by mrugiero (guest, #153040) [Link]

It does if it means the work is irrelevant by the time it's ready tho. I think that's one of the major risks of rewrites. That and never being ready and just taking resources from tasks that actually result in stuff a user can interact with.

Rewriting ancient code

Posted Feb 20, 2023 2:34 UTC (Mon) by ras (subscriber, #33059) [Link]

> Other projects follow the guideline "if it ain't broke don't fix it".

But it was broken, in a way. It's true code doesn't wear out in the convention sense. But software has an analogous process: bit rot, which I guess is where it stops working because rest of the world has changed underneath it. In Thunderbird's case, it is based on the same engine as Firefox, and that engine has undergone some drastic changes over the last few years. The justifications I've read from Mozilla on why they were forced to make the changes to gecko looked pretty grounded to me - again they revolved around the world changing so much the old gecko was not a good fit capabilities and security guarantees a modern browser is expected to provide.

That left the Thunderbird team with two choices, neither pleasant: take over maintenance of the now abandoned (and huge) version of the engine they are currently using, or move to what Firefox uses now.

They chose the latter. In the short term it has lead to a lot of the same type of breakage we've seen with Firefox extensions. But it looks like that is over now as thankfully the pace of breakage has slowed down, which means they are running on the new engine. But I expect they held the core together during the thick of that transition by adding generous amounts of glue that made the new API look like the old one.

So now we are in the "lets revisit everything in the light of the new engine" phase, where they rewrite the top layer so it doesn't need the glue. In the mean time UI's have evolved from the 20 year old Netscape email client interface. Personally I think it's mostly been in the positive direction. I expect they will take the opportunity to incorporate some of those ideas into Thunderbird's UI. Indeed, they already have started down that track in recent versions.

The future of Thunderbird

Posted Feb 10, 2023 6:32 UTC (Fri) by flussence (guest, #85566) [Link] (4 responses)

I was cleaning out some old hard drives this week and found an old ~/.thunderbird/ filesystem tree. New enough that I bothered to keep the hard disk it was on, but there were (to my absolute horror) data files in Mork format. This program has always been losing the fight against technical debt, it seems.

The future of Thunderbird

Posted Feb 10, 2023 6:54 UTC (Fri) by vasvir (subscriber, #92389) [Link] (2 responses)

Hey,

I didn't know about Mork format.

The name reminds Lord of the Rings.

Thanks.

https://en.wikipedia.org/wiki/Mork_%28file_format%29

The future of Thunderbird

Posted Feb 10, 2023 17:07 UTC (Fri) by ballombe (subscriber, #9523) [Link] (1 responses)

Wrong movie :)
https://en.wikipedia.org/wiki/List_of_The_Neverending_Sto...

The future of Thunderbird

Posted Feb 11, 2023 9:21 UTC (Sat) by ctreb (subscriber, #4406) [Link]

Also wrong :)

https://web.archive.org/web/20191008061717/https://develo...

'The Mork name comes from the famous '80 TV series "Mork & Mindy".'

The future of Thunderbird

Posted Feb 27, 2023 20:03 UTC (Mon) by nix (subscriber, #2304) [Link]

Have some documentation on mork (and murder, and of relevance to the ongoing liability comment thread): <https://www.jwz.org/blog/2011/07/mork-keeps-on-giving-whe...>

A classic jwz rant about the file format (in the comments at the top): <https://www.jwz.org/hacks/mork.pl>

The future of Thunderbird

Posted Feb 10, 2023 13:59 UTC (Fri) by WhatsInAName (guest, #128037) [Link] (2 responses)

What about fixing egregious bugs? Version 102.7.0 broke authentication against Outlook business servers, and the two subsequent minor releases after this one have yet to fix the problem.

The future of Thunderbird

Posted Feb 12, 2023 1:01 UTC (Sun) by himi (subscriber, #340) [Link] (1 responses)

If it's the same issue I hit, the fix/workaround is to disable ipv6 name resolution - in the config editor, toggle `network.dns.disableIPv6`. I didn't look into the issue in detail, but it smelled more like misconfiguration on the server side than in thunderbird - advertising v6 addresses, but having the service not work with them, or something like that.

The future of Thunderbird

Posted Feb 13, 2023 14:05 UTC (Mon) by WhatsInAName (guest, #128037) [Link]

Yes, it seems to be that issue. Thanks for the tip.

The future of Thunderbird

Posted Feb 10, 2023 16:21 UTC (Fri) by ericc72 (guest, #41737) [Link] (2 responses)

The UI absolutely needs work in my opinion. Also, just installed of Fedora not too long ago as only client that could natively do the OAuth stuff needed to access the Exchange Online accounts we have at work. But pulled up long since deleted archive folders and left out ones that were current (not sure how this works on the server side to make this happen, but it did.) Works fine in Outlook and OWA.

Also, long time gripe, when composing an email I ca choose a font family. But for size I cannot pick a numeric size, it is all relative "small, medium, large" stuff! What???

This all said, I want Thunderbird to be a compelling product. So I hope they do good things with it.

The future of Thunderbird

Posted Feb 10, 2023 16:38 UTC (Fri) by Wol (subscriber, #4433) [Link]

Just a shame Eudora decided to scrap their product and re-badge Thunderbird.

Likewise when Turnpike disappeared.

The trouble is, if there aren't enough people prepared to PAY for a decent product, them as pay the piper call the tune, and if nobody's paying then the piper doesn't care what he plays so long as he's playing. If you don't like the tune, tough :-(

Cheers,
Wol

The future of Thunderbird

Posted Feb 16, 2023 7:00 UTC (Thu) by gdt (subscriber, #6284) [Link]

Evolution can do OAuth. But the last time I did this I had to look up some of the parameters using other tools, so I got to learn far more OAuth than I had ever wished. See https://wiki.gnome.org/Apps/Evolution/EWS/OAuth2

The future of Thunderbird

Posted Feb 15, 2023 7:17 UTC (Wed) by jond (subscriber, #37669) [Link]

I’ve still got an ancient TB filed away somewhere for a workflow that requires one of the plugins from the other side of their last red flag day. That summary doesn’t read like it was written by people who love what Thunderbird is, but rather what they wish it was.

The future of Thunderbird

Posted Feb 16, 2023 7:47 UTC (Thu) by smurf (subscriber, #17840) [Link]

Frankly I'd settle for it to not eat a GByte of memory (in-core, not VM space!).

… and that's after an uptime of LESS THAN TWO DAYS.

It also keeps one core CPU 15% busy, no idea why or what the heck for, even when I'm not interacting with it at all. :-/

I can well imagine that it'll take a ton of refactoring to even discover the reasons for that.

The future of Thunderbird

Posted Apr 20, 2023 10:36 UTC (Thu) by Klavs (guest, #10563) [Link]

This seems to be related to the fact that the popular mobile mail client "k-9 mail" - has chosen to the new thunderbird mail client.. https://blog.thunderbird.net/2023/03/thunderbird-for-andr...
So I am assuming its because a lot of development is going on there - they want to clean up the codebase, so it can more easily be used for that and as its "good and old desktop client"