It does scale when being considered by software running on it. Even more with some alternative approaches like directories. What OP means is that it does not scale for software to be oblivious to underlying cache coherence and to operate on "one flat shared RAM" assumption. E.g. false cache line sharing etc.

Do you plan on open sourcing plugs or any parts of your system?

You can see what happens to OS projects that work with WhatsApp, Skype, and some of the other heavily guarded walled gardens -- cease & desist orders, carried out by GitHub.

We have absolutely no interest in joining that list, which unfortunately means the answer - for the time being - is no :(

Right, but surely if you're selling it that's much more incentive for a cease and a desist (regardless of whether it is free software).

Actually I don't think so. The main thing the owners of big networks are afraid of is spam.

We provide a ridiculously expensive way to connect, say, Slack to Skype, which is ==great for Skype==, from almost every possible angle. It means Skype users can stay on Skype instead of switching to someone else's Slack team.

In that case great for skype, bad for slack. Someone, somewhere will decide they'd rather force those customers to use their service/client, or else they'd have an open protocol in the first place.

There's a huge compliance problem with working in someone else's Slack team -- you own none of the resulting data and you don't control access on your end.

Email is much better in this way, since everyone gets a copy.

With Sameroom you essentially retain the carbon copy semantics of email, but with real-time collaboration. So, I'd argue that it's great for Slack.

Would be awesome if you had some sort of status page for all chat services.

We actually do, but it's way too ugly at the moment (raw JSON).

We plan on beautifying soon.

So how this works with federation? I don't see any open/common API.

It's "federation-as-a-service", basically.

A common use case is federation between two Slack teams (share a channel).

Another common use case is federation between a group in Skype and a channel on Slack.

Or IRC and Telegram, etc.

Making existing systems work together really well is priority one. API only makes sense once that's done.

I can see this working when the entire team does support, but when you have dedicated support/outreach people they will likely prefer Intercom webapp.