If you were willing to use Slack after all, then I guess you were willing to consider non-FOSS alternatives? In which case, one service you don't seem to have considered: Discord.

Yes, really, for business. Look past the theming.

Discord has a much more solid tech base (and engineering team) behind it than Slack, IMHO. A better API, too; and—unlike Slack—real support for third-party clients!

I built my own niche team-collaboration app back in 2012, and I tried out a lot of things, but ended up building my whole own stack. That was back then. If I was doing it again today? I'd just make it an alternative Discord frontend.

(There are also offerings specifically designed for the "build your own custom frontend for our chat backend" use-case, like https://pusher.com/chatkit, but IMHO Discord even has these beat.)

Right, let's just do all our business on an app that doesn't have SSO and instead anyone with the link who can sneak in has access. I'm sure that's not sketchy at all and your IT department will be thrilled.

> and instead anyone with the link who can sneak in has access

You don't have to make those links (and you can turn off, per server, the ability to create those links.) You can invite specific users. The user already has to have a Discord account, though.

And that's the thing; Discord has a different accounts model. Which is part of what I was referring to when I said they had a more solid tech base: when you're signed into a dozen Slack workspaces, the Slack client has to keep a dozen websockets open, because the open connection is for a given Slack account's view of the world, and Slack accounts are a sub-resource of Slack teams. This isn't a scalable model, and when the Slack app is using 1.2GB of memory and two full CPU cores, this is much of the reason why. When you're signed into a Discord account, on the other hand, you just have one connection to the server—and one state-sync session that includes all your open channels in all those servers—because your profile on a given Discord server is a sub-resource of your global Discord account.

It's the difference between how an email client connects to N accounts through IMAP, and how the Gmail mobile app is connected to N GSuite accounts.

And, as such, it wouldn't really make sense to have Discord SSO at the account level, because a Discord account is associated with the individual, not with a particular employee record of a particular Enterprise. It's not like an email address; it's more like a Keybase identity or a Facebook profile. (You could certainly have particular profiles under the Discord account that did SSO to a particular server, but this wouldn't be traditional SSO-as-we-know-it; it'd be more of a "connector" flow, like when an app wants to use your Github profile.)

Github is a good comparison, actually. Most corporations just use Github, not Github EE. You don't Enterprise-SSO to Github.com. Github.com is an SSO provider, in fact, that other sites (e.g. Asana) can take auth from!

I don’t think this is an advantage? Work account can be accessed by your IT department, locked out when you leave, investigated for any reason. I certainly don’t want to have any links to my personal stuff at all!

As for github.com, our official IT recommendation that people don’t use their personal accounts, but create one just for work. This way there is no worries about personal data there.

(This is at a subsidiary of a large international company. I can believe small startups use a simpler methods)

> I certainly don’t want to have any links to my personal stuff at all!

Keep in mind, putting SSO into Discord’s account system (if that ever happened) wouldn’t be like putting Enterprise MDM on your personal phone. It would be more like having Chrome Sync signed into both your personal Gmail account and your GSuite account, as separate Chrome “People” (or whatever those are called.)

With Chrome Sync, the profiles are still isolated from one another; but updates to them ride in the same sync carrier connection, because that connection is going to Google either way. In this sense, the Chrome installation itself, and its “installation-specific sync client ID”, is like a Discord account. It’s not a personal account, or an enterprise account; it’s a nothing in-and-of-itself, that has those types of objects under it.

I always thought of Electron as a way to kick out a minimum viable product quickly before writing native versions. But nope, I guess give a $16 billion company 4 years and 1600 employees and that's still not feasible.

Electron gets a lot of hate on HN. I get it. But IMHO the existence of VSC (Visual Studio Code) -- as an extraordinarily useful, powerful, compelling cross-platform application -- serves as the only counterexample needed to puncture the "it sucks bc it's Electron" trope.

It can absolutely still be useful, and it would make sense for an early stage startup or someone's side project to use it so they're not duplicating work porting it to .NET, Cocoa and Qt or whatever. And sure, having an identical look and feel everywhere is nice. But with all the resources that Slack and Microsoft have, they need to publish a lengthy guide for the users to deal with their performance problems [1]? They take 22 seconds to load a 6 MB XML file [2]? Ehhh... it's not asking that much of a multi-billion dollar company. You deserve better!

[1] https://github.com/Microsoft/vscode/wiki/Performance-Issues

[2] https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

"Visual Studio Code jumps to the end of the file quickly, but then takes many seconds for the highlighting to complete."

I'm quite fine with that, frankly. Highlighting correctly requires actually parsing the file. I use vim and the colors get wonky way too many times, because it tries to "keep it fast".

A dozen web sockets are not the reason for high resource usage. Web sockets take very little to maintain.

It’s not the dozen websockets in a literal sense that are the problem; they’re more an especially-visible consequence of their design choices that is easily noticeable during a design audit—a “canary” that shows the flaws of their model.

Slack has decided that each team workspace must be firewalled off from the others: such that it needs its own websocket, its own client-side sync session, its own open channels, etc. This is because Slack was first-and-foremost a web-app, and in the Slack web-app, you’d just have one browser tab per Slack team. Slack built up its infra assuming this “one tab per workspace” model, and it crept into their backend API design, and now they’re kind of stuck with it. So now, even in the native mobile app (let alone the desktop Electron app), when you have 12 Slack teams open, you have basically 12 copies of the app’s view-controllers open and idling in the background, 12 background sync controllers, etc. In the case of the Electron client, that’s also 12 renderer processes, just as if you had 12 literal browser tabs open!

You might not notice this at first, because Slack won’t initialize all those resource for a workspace’s “tab”-equivalent until you actually focus the given workspace at least once. But if you just skim through all those workspaces once in the morning, and leave Slack open, it’ll be hogging those resources all day.

(And, on mobile, that’s especially a concern, because despite what you say, web-sockets themselves have heartbeats, and 12x the heartbeats is 12x the reasons for your phone’s modem to wake up. If you’re ever wondering why the part of your phone around the antenna is getting hot even when you’re not actively using data—it’s probably that you have several active Slack workspaces in a live Slack app-container.)

>because despite what you say, web-sockets themselves have heartbeats, and 12x the heartbeats is 12x the reasons for your phone’s modem to wake up.

Don’t put words in my mouth. A heartbeat is not high resource usage.

Your wall of text doesn’t negate the fact that multiple websockets can be maintained with trivial resource consumption. It absolutely cannot be generalized to assume that multiple websockets means copies of everything. I’ve seen multiple clients supporting multiple websocket connections to distinct servers while re-using all of the same UI components.

Everyone in the Open Source community with the skills to write a good chat app is perfectly happy running IRC in a terminal. Good Open Source only happens when someone needs to scratch their own itch.

We've been using mattermost internally for a year or so and his has worked flawlessly. I can't tell the difference from slack.

At least a year and a half ago, Android notifications weren't at all reliable, even when on wi-fi. You'd have to start the app most of the time to get them. I can't remember if it was Rocket.Chat or Mattermost that also was taking 15% of the CPU while idling on macOS, but I think it was Mattermost.

Have you tried out wire? I like it, but never used it in a work environment.

Matrix has been a better fit at my company, though it was a bit rough a year ago.

Bridging in Slack, Gitter, IRC and other platforms makes working with external teams a breeze, everything is in one place.