Why Linux Still Doesn't Have a Great Gmail Client

Here’s a question I kept running into while building Spondr. Why does Linux still not have a great Gmail client?

Not “why doesn’t Linux have good email software.” That’s too vague. I mean: Gmail is the dominant email provider. Linux has serious, sophisticated users. And yet, the email experience on Linux is, at best, mediocre for Gmail users.

I think I know why.

The Abstraction Problem

Most Linux email clients were designed around IMAP. Not Gmail IMAP. IMAP as a protocol and a mental model.

Gmail is not a standard IMAP server. It has labels, not folders. It has Gmail search semantics that don’t map cleanly to IMAP. It has threading behavior that most clients get wrong. It has archive, which isn’t quite delete and isn’t quite move. These things don’t fit neatly into the folder-message structure that most Linux mail clients were built around.

So what happens? Clients bolt on Gmail support. Labels become tags or fake folders. Search gets proxied through IMAP in ways that break the obvious behavior. Threading works but not like Gmail threading.

The result is software that technically supports Gmail and practically frustrates Gmail users.

The Electron Trap

A lot of recent Linux software went the Electron route. Cross-platform, fast to build, familiar web stack.

Electron email clients work. They can implement Gmail API correctly. They can make search behave like Gmail search.

They also feel like web apps that happen to run in a window. Latency is always there. The network is always in the loop. The UI feels borrowed from somewhere else.

Software you use every day needs to be fast, responsive, and frictionless. “It works” isn’t the bar. The bar is “it feels right.”

That bar is hard to hit in Electron.

The Plugin Fallacy

Some Linux email clients went the extensible route. Plugin systems, Lua scripting, deep customization. The thinking: let users build what they need.

I understand the appeal. Power users want control.

But plugin systems are also a way to defer product decisions. If you don’t have to decide how search should work, you can let a plugin handle it. If you don’t have to decide what Gmail labels mean, you can let a plugin figure it out.

The problem is that those plugins are often brittle, poorly maintained, and wrong in subtle ways. When they break, your email workflow breaks.

Spondr doesn’t have a plugin system. It has a config file. That means we made the decisions about Gmail labels, search semantics, threading, and what “archive” actually does.

Making those decisions is harder. The result is more coherent.

What Spondr Is Betting On

I’m building Spondr because I think the gap exists partly because nobody has tried to do this the other way. Build specifically for Gmail on Linux, with a native stack, prioritizing correctness and feel over extensibility.

Native means fast. Local data means instant search. Gmail-first means the behavior is actually right, not approximately right.

Is this bet guaranteed to work? No. But Linux users who want a genuinely good Gmail experience deserve something built for them. Not a compromise that mostly works. Not a plugin-dependent solution that sometimes works.

That’s what I’m trying to build.