> The author isn't sticking his head in the sand

I think he was talking about HN users who argue that IRC does everything slack does.

> One of the sad things that has come out of Slack's meteoric rise to success, has been how many free and open source projects have jumped over to using it (after previously using IRC or XMPP).

He's definitely honing in on a group of people who should support federated solutions and instead evangelized the opposite. Ironically there's a similar frustration with using the proprietary GitHub service rather than open source git sites like GitLab

Apples to oranges, GitHub provides Git as a service and Git is open source, so you can take your repo any time and host it yourself in number of different ways. It just happens that GitHub is most popular (for now) Git As A Service, probably due to the fact that GitLab had few horrible outages regularly every few months for past 2-3 years and hosting it yourself is/was also a bit of nightmare. Anyway, it's not like that. ;)

The problem with GitHub silo is not the repo hosting per se but the ancillary services. Issues are not easily exported. The milestones and related metadata are not easily exported. Even the identities are not easily exported since you can use noreply email addresses in git actions if you turn off public email

Neither of these are Git features. Vote with your legs if you think what you want should be available in a service like this.

My company has gone through three different milestones and issue apps. Sure its mot manually exportable but thats why we pay for data entry staff.

There are many different reasons to choose a service provider. Being FOSS should factor in, but it should hardly be the major factor. Currently, Slack and Github are better choices (Slack is far easier to get started using than IRC, and Github currently has more of a network effect than anything out there). While yes, it would be nice for open source projects to use open source solutions, they should be choosing the best tools for the job. If those aren't open source solutions, so be it.

Yeah anytime Slack is mentioned at work someone brings up IRC. So I get what he’s saying.

Nobody argues that. But they may very well argue that IRC doesn't everything they want it to do.

My argument is that IRC is better because it doesn't do a lot of things. I really don't feel my day would be enhanced by people pasting images or animated emojis into my IRC channels.

Ugh I messed up my post, "doesn't" was supposed to be "does".

See the replies to my comment 10 days ago: https://news.ycombinator.com/item?id=16495893

Most of the replies are criticising the ghastly inefficient app. What is wrong with that?

I know people who literally argue that. Needless to say, I don't agree with them. :P

Thanks for clarifying this for me while I was afk. :) I wouldn't constrain it to HN only, but yes, that's my point.

Interesting if it ends up supporting Emoji Reactions (note, this is not just Emoji, but Emoji Reactions to messages) and Threads

That's the right answer, I'm very skeptical of people saying "this can be done in XMPP" but when it comes to the actual implementation it falls short

Edit: also note the author updated the article and Emoji Reactions are still not supported in XMPP but are in development

> but a lot of the clients are currently lagging behind.

^ this.

A lot of people are so mad at Slack and extolling the virtues of XMPP and IRC and fully forget that there are about zero clients for either XMPP or IRC that have the same functionality (consistent across multiple platforms) as Slack.

Yes, I'm fully aware of exactly one client for Android (Conversations) that supports mobile-friendly XEPS. And yes, I'm fully aware of IRCCloud, a closed-source, proprietary 100% web-based product on top of IRC (all the things that people seem to hate about Slack. Go figure)

> And yes, I'm fully aware of IRCCloud, a closed-source, proprietary 100% web-based product on top of IRC (all the things that people seem to hate about Slack. Go figure)

My understanding is that many of IRCCloud's Slack-like features are based on the open IRCv3 standard. If this standard ever takes off (fingers crossed...), IRCCloud will have a lot less vendor lock-in than Slack does.

> If this standard ever takes off

Hard to imagine it will for Slack's audience. Slack is serving the case for the non-technical folk extraordinarily well right now. A significant amount of their user base doesn't care about standards or IRC channels. They just want a consistent, well-designed product that does the things they need it to for work. They've never opened a terminal in their life and they don't need the terminal-irc-gateway that this recent change has killed off.

All of that is true, not to mention that Slack is free (up to a certain point).

But many IT departments require on-premise hosting, which Slack doesn't offer. Users don't care about open standards, but maybe their sysadmins do. If IRCv3 can capture this audience, it has a chance to co-exist with Slack.

> But many IT departments require on-premise hosting, which Slack doesn't offer.

Less and less IT departments do that now, since so many things move to the cloud. When you have all your stuff in Gmail and Google Docs already, having Slack is a no-brainer.

IRCv3 has the same problems as XMPP's XEPs [1]. You need servers capable of handling these standards, and then you need clients capable of handling these standards.

In the meantime people will chose other platforms that provide better and more consistent experiences.

[1] https://gultsch.de/xmpp_2016.html

That's entirely possible, but commercial products are not infallible either. I remember a time before Slack when many companies were using Skype for intra-company chatrooms. Then Microsoft managed the product to death and people started looking for new solutions again.

E-mail is about as terrible as IRC and yet it just won't die.

> E-mail is about as terrible as IRC and yet it just won't die.

At least with email you're able to send messages to those on different "networks".

> Then Microsoft managed the product to death and people started looking for new solutions again.

That's very true. Products fail. So instead of blaming others for failing to provide integrations, I would look at what made these products popular in the first place. Unfortunately most discussions around XMPP and IRC rarely actually discuss this.

Speaking of Skype. You can actually see how management fails to understand the popularity and features of other communication platforms in each release. It's funny and sad at the same time.