It seems that the author references different IRC clients but at the same time ignores (can't say if on purpose or not) the fact that there are also alternative Slack clients which address many of the pain points.
To stefan's point, Slack clients are unofficial and unsupported software built on top of proprietary protocols which are subject to change at any time according to the whims of a private company which has their bottom line at heart instead of your communication needs.
They can crack down on alternative clients at any time they want. You are living on borrowed time. A guest who is wild camping in their gated community walled garden private property.
I also agree with you. It was painful when e.g. Twitter basically killed 3rd party apps.
What happens here is that I don’t see any significant portion of Slack users moving to IRC anytime soon. Therefore, if you’re forced to use Slack, you should know that alternative clients are available as of today.
I’m just trying to show that there are alternative ways to use Slack for those who are forced to use it. If you and/or your company actively use IRC then my suggestions obviously don’t apply to you.
And even more so to the point, you can't self host slack and have absolute root level to the OS it's running on admin control. For somebody who knows what's they're doing it takes maybe 45 minutes to set up a basic ircd-hybrid daemon on Debian or centos.
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.
> 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.
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.
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.
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.
> 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.
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.