I think it's even worse than "supporting" it, it was breaking their UX if certain users didn't have certain features (namely threads).

Disclaimer: I hate threads in slack

> Disclaimer: I hate threads in slack

When you already have too many channels, and then they give you the ability to have too many threads.

I feel like they do a worse job at the supposed value add of being able to archive and later refer to a topic of conversation than channels simply because they are so light weight and proliferate so many of them, potentially.

Plus it's really jarring to be pulled into a bunch of threads.

I think the too-many-channels problem is a symptom of the excessive walled gardening.

Slack segregates by interests and social group, and bundles that with strict gatekeeping. There is no way for people to remix that to suit their own preferences. You can only fragment existing communities more.

I would love a slack multiclient where I can put channels I care about side by side, regardless of origin, and keep the rest out of sight. Instead now everyone has their own #random and #offtopic and so on. Cruising between Slacks and Discords is like navigating a hall of mirrors. If there is disagreement, the only solution is complete schism.

Slack's use as a "community" chatbox is a mangling of its original intent to be used by teams. That's where your pain points are coming from, and some of my own (no /ignore feature, for instance).

I have some of the same issues, but I'm not part of any community slacks. I run my own consulting company, and as such, I've been invited to most of my client's slacks. So I've currently got 37 Slack workspaces going. But most of the time, I'm only concerned with the specific project channel that I'm working on for a client, and I might only be active in 2-3 projects at a time. So I'd love, like OP, to be able to just have those 3 channels front and center.

That's definitely a use case I hadn't considered.

The point is that with XMPP at least, they could add those features. They presented their case as if it couldn't be done with XMPP, which is not true.

Probably the subtext here is that they didn't feel it was worth the effort of doing double work for all their new features.

Then they could at least say so. Not making some BS excuses.

What difference would it make to anyone if they added "...and yeah, we could fix it, but we don't see it as worthwhile" to the end of the post?

Without the additional text it reads like it's the fault of XMPP/IRC.

I really recommend checking out Zulip. It's open source, and they do threading so much better than everyone else.

Making your UI so that it doesn't break is the very definition of supporting it.

The particulars of each one's business model is moot if they're all incentivized similarly (which is to lock-in users and to hoard their data).

Lockin could mean they use the service, or stronger, they use the service on the official UI (which may have ads). I think for Slack, the first type of lockin is enough (a paying user is a paying user, whether they use IRC or slack.com), whereas for FB the second type of lockin is better because only that can be monetized.

Yeah, I think this article is needlessly paranoid. I've seen no evidence that their protocol connectors pose any threat to their main business. Like you, I believe that the real problem is development velocity.

As much as I'd like to live in a world where open protocols and federated services evolve as quickly and turn out as well as proprietary solutions, that's apparently not the world I'm living in. Email, as much as I love it, is basically stagnant. IRC existed long before Slack, and if it had been truly successful, Slack would never have existed because there would not have been a market niche. And having recently written a bunch of XMPP code to talk to my vacuum [1], I was entirely underwhelmed. Whereas Slack is a product I use daily because it just works, and works well.

[1] http://github.com/wpietri/sucks