[Spivak]

I mean all IRC clients are 3rd party so I'm surprised that your sentiment towards 3rd party Slack clients is so bad. I've been using wee-slack for a while now and I have very few complaints.

I mean it's not IRC where the protocol is etched on stone tablets but Slack has been thus far a good steward of their API.

[est31]

> I mean all IRC clients are 3rd party so I'm surprised that your sentiment towards 3rd party Slack clients is so bad.

The difference between IRC and Slack is that IRC is seen as a standard protocol while for Slack the network protocol is an inofficial implementation detail and any use other than of the official client is unsupported. I'm not very familiar with Slack, but I've heard about Whatsapp users being banned just for the crime of using an alternative client. That's the difference between an open protocol and a proprietary one.

[Spivak]

Huh? The network protocol for Slack is JSON over WebSockets and is completely documented and supported [1]. You don't need a Slack SDK to speak to Slack and can do it with any plain WebSocket library.

Obviously Slack doesn't provide support for 3rd party clients; how could they? But they do provide support to the developers of those clients using their API.

[1] https://api.slack.com/rtm

[Sir_Cmpwn]

I'm going to remind you of this comment in 5 years.

[Spivak]

I mean if Slack didn't end up ruining their API in the name of greater development flexibility I'm not sure I could even comprehend it.

But that's the thing, I think Slack is a fundamentally inappropriate tool for FOSS work or public communications. Anyone who stakes their long-term community on a single company's proprietary product is asking to be hurt down the road. But I don't think IRC is the right alternative because the UX is so newcomer unfriendly and requires so many disparate 3rd party services to be useful. I would much rather see communities standardize on something like Riot or Mattermost with OpenID.

Simultaneously, I think that Slack (and its contemporaries) are a breath of fresh air for internal team/office chat. Sure it's expensive, and like all corporate-y things you have to keep a little distance so you can migrate when they get shitty, but we can at least acknowledge that it's a damn slick product.

[johannes1234321]

The difference is that the IRC standard is decades old and stable and made for "independent" clients.

Slack is Young and evolving and driven by a single company which wants to push their client

[Spivak]

This is all very true but they're also a company that wants to push their API since that's where most of their stickyness comes from as a business.

IRC definitely has stability going for it but it also means it has been unable to adapt to user requirements changing over time. The most usable IRC client right now is IRCCloud which is good, but it doesn't inspire much hope because it's only usable since they completely plaster over the protocol in their UI.

In this model there's nothing special about IRC except that it's a common denominator protocol for a few networks that use it. If we were choosing a inter-network protocol I don't think anyone today would come up with IRC.

[johannes1234321]

> This is all very true but they're also a company that wants to push their API since that's where most of their stickyness comes from as a business.

This is what people said about Twitter as well ;)

And slack, for instance, discontinued their IRC gateways as that limited their possibilities to "innovate" and I can image Slack, being pushed by shareholders, restricting free add-ons to getting data into slack (from Version control, business tools, task trackers, ...) but restricting getting data out to more expensive tiers (making transition of Slack harder)

But there are the key difference between open and proprietary protocols: Open protocols are slow to evolve (see also the state of mail protocols ... where innovation happens mostly in Gmail's protocols, not SMTP/imap/...) but allow wide variety of clients, while proprietary systems can evolve faster, but are more limited in clients.

[Spivak]

Well yeah, I'm in no way saying that people in the OSS world should standardize on single company's proprietary protocol and platform and if IRC is the only thing people from two projects can agree to speak then it's what we've got.

But we really need to stop trying to make IRC 'work' and build something more usable that can interop with existing IRC networks (hi Matrix!). IRC is fundamentally not a good enough protocol for how people people chat today but it's easy for people who have been using it for 20 years and have a lot of pride and machismo sunk into figuring it to dismiss outsiders that are struggling and believe that if you pile enough barely-working brittleware on top that it can sorta-kinda work like Slack or Mattermost.

[johannes1234321]

There were attempts to replace IRC with more modern (back in those days ...) architecures. For instance jabber/xmpp. But between IRC and commercial alternatives it hardly played a role. (I see more usage of commercial jabber extensions in Cisco than jabber itself these days)