If only there was a well supported, standard, open and interoperable text messaging protocol (with multiple implementations) that companies could host themselves...
This comes up every time, and as usual you have totally missed the point.
IRC is difficult to configure, difficult to host, difficult to use, and does not offer the same feature set as Slack. There is an obvious use case for something like Slack (obviously, because otherwise it would not have millions of users!) and covering one's ears while yelling "IRC! IRC! IRC!" is sort of wilfully ignoring that if it were a suitable solution, Slack would never have taken off.
I honestly don't get this. I've been using IRC for a few years, but I don't think nearly enough for blind eye nostalgia to take hold.
It's not like you're stuck with ugly terminal only clients anymore. There is KiwiIRC, IRCCloud, and several other great web clients that not only let you connect to any server but provide bouncer services and backlog. There are also plenty of easy to use native clients that don't require any configuration.
There are some benefits of Slack, but the ones you mention aren't them. In fact, seeing how you CANT host your own Slack server I would say "difficult to host" is a flat lie against IRC.
I don't want "backlog" (read: see what happened when I was gone). I want full-text searching of the entire channel history. I already log my IRC conversations, and it's a pain in the goddamned ass to ssh to my bouncer, grep through the logs, and try to find what I was looking for. I want to type in the same client that I'm chatting in, and be able to reference this message to other people. IRC doesn't do that.
grep works way better than Slack's search, which makes you wait several seconds per tiny page of search results. I look forward to the day when Slack catches up to grep.
I think the point is that we should enhance IRC or XMPP, or create a new federated and open protocol that supports the features and easy setup Slack offers. Users suffer when we create proprietary protocols and walled gardens. Can you imagine if someone using Google Mail couldn't send an email to to someone using a university, government, or Yahoo email address? It would be unacceptable. However, this is the situation we are in with real time messaging protocols. It's infuriating to me that developers are content creating these systems. It's unethical, in my opinion.
A distributable VM or docker container, or even ball of scripts fixes the configure/host package. And there are plenty of easy to use IRC clients, perhaps make and even dumber/simpler one. Easy problem to solve.
It really isn't hard to use. Firefox has a great extension called Chatzilla that makes it wonderfully easy to use. Maybe it's hard to host, but you can just claim a channel on freenode if you need to.
It's easier to host (at least on the scale that most teams would, few nodes, few tens of users, no need for services -- basically `apt-get install ircd-of-choice`) than to use, but I disagree that it's easy to use.
I can tell anyone in any kind of role (senior to junior, technical to non-technical) on my team to "Download (the/a) client for X and join #channel #channel2" "Follow the directions to set it up so changes on this Trello board are posted to #channel" and reasonably expect they will succeed if X is Slack, but not if X is IRC.
Are you fucking kidding me? I've been using IRC since I was 10. If a 10-year-old can figure it out, I think a professional engineer can figure it out. Using your typical IRC client to join a channel is just 4 steps:
1. Download IRC client.
2. Pick a nickname.
3. Pick a server.
4. Join a channel.
With something like kiwiirc, you can even omit steps 1, 3, and 4: you can give someone a URL to a particular channel on a particular server. Just pick a nickname and click "join". It's really simple.
> anyone in any kind of role (senior to junior, technical to non-technical)
I'm talking about Joe Frontend, Billy Design Intern, Gary Office Assistant. Maybe you work on teams that are 100% neckbeards that aren't afraid to crack open an RFC to get daily shit done (and waste huge amounts of company resources on things that should be simple), but that's not the environment I'm talking about.
Not accounting for these people is the fatal mistake made by far too much of the tools and processes in software. I've watched people go into shops like this as non-technical helpers, work really hard and skillfully within the boundaries of their role, but get burned too many times by a hoity-toity technical bro "lol, you can't even open an ssh tunnel to the bastion host to connect to the internal IRC..." that they quit software, return to lower paid job they did during school and decide they have no skills, when they would thrive on a more balanced (and more socially skilled) team.
I've never needed to open an SSH tunnel to connect to IRC. I click on the Xchat icon, and two seconds later I'm connected. I don't know where you're getting these ideas that using IRC requires consulting the RFC or opening SSH tunnels, because you don't need to do either of those things.
There's two ways this argument goes awry: "IRC is fine, you just have to be smart enough" and "Only ever use IRC for the things it does well", I thought we were on the other branch there for a bit.
I had specifically included a scenario that is both common for use in my experience, and also pretty much impossible for a normal human using IRC in order to preempt this branch:
> Follow the directions to set it up so changes on this Trello board are posted to #channel
Sure, in extremely limited situations (so many qualifications are required here I won't list them) it's mostly easy enough for a non-technical person to manage.
Normal people (that is, people who value their own time and haven't been warped by daily interaction with software that fails to do what you asked because you failed to include some extremely implicit punctuation) laugh at many common explanations surrounding IRC, just a handful of examples: "IRC doesn't have passwords really so to prove who you are, you have to speak specific commands, like a CLI, at this bot over here, or configure your client to do that for you" "IRC has away status but nobody really uses it, because it's manual in many clients, so you typically 'ping' people and just wait to hear back if they are around" "oh yeah, if you want to get rid of all the join/part/away spam, the option for that is hidden in a menu with a bunch of other stuff, and in this client you have to set it up for each channel separately" "oh, yeah, you can't speak in that channel because you have to get the bot to +v you by direct messaging it 'shibboleth'" "btw here's the list of random-seeming letter 'flags' our server supports and how it interprets what they mean differently from other IRC daemons"
And we haven't even talked about how bad the story is around message persistence or using multiple clients or the "solution": bouncers. Getting all that going is basically a non-starter for humans unless you give in and use a service like IRCCloud that deals with search and synchronization well across platforms (but which you must be aware of in the first place).
I'm pretty technical, I've internalised the arcane knowledge, I've written IRC RFC-compliant bots to get things done (and then made them conform with common out-of RFC conventions in order to work with non-conforming IRCds), but that was all in high school, well before I gained a sense for the value of my own time. I can do it but I still refuse (to the degree that a team's use of IRC would make me pass on an offer as would I pass on a developer interviewee's inability to perceive usability problems with IRC).
Those are all good points (hell, I've been using IRC for nearly 17 years and I still don't know what half those flags mean). I think it's the first time I've seen a good argument about not using IRC!
I still think it'd be fairly easy to set up a company-internal server and make the whole process pretty streamlined for users. The only somewhat difficult part, then, would be the password. And I'm not sure how valuable message persistence really is, anyway, especially when you have your company email directory (and you could have IRC logs).
And for the record, I don't claim IRC's UX is without it's problems. It could certainly be improved a lot. I just don't think it's bad enough that people can't be expected to figure out how to log on and start chatting. At the same time, I think switching to a proprietary service that's run offsite is not a good solution. (We use XMPP where I work, but strangely not with conferencing. It works very well, but we're forced to use a shitty client (Cisco Jabber)). I've got high hopes that IRCv3 can start making improvements on a lot of the things you mentioned, but only time will tell.
Yeah, we tried that. You forgot setting up TLS, authentication, and oh you wanted a backlog? You'll have to switch to this different client that runs in the cloud / on a Linux server.
If there were no other alternatives we could probably manage somehow, but there's much less friction in "here's the URL, sign up with your email address"
Actually I know several IRC channels that have bots that send messages for activity on GitHub, Twitter, etc. And writing IRC bots is among the easiest things ever. The IRC protocol isn't hard and there are lots of libraries, snippets and bots out there.
Yeah, comparing it to Google Wave probably is a bit too much. In my neck of the tech woods HipChat is still pretty hip. I suspect that by the time we discover Slack, something else will have taken Slack's place as the new wave. Meanwhile I'll just keep visiting the same IRC channels outside of work that I have been frequenting for a decade. Will Slack be around in 10 years? Maybe. Will it be the poster-boy of internal chat? Unlikely.
You mean the same IRC that doesn't include basic features like the ability to receive messages if you aren't currently connected? The same IRC that has horrible scaling issues once you try to really use it? The same IRC that is a miserable experience to setup, administer, search, and even use?
Stop touting IRC as the "perfect" chat system. It's far from it.
Traditionally offline message caching would be the responsibility of a bouncer, or something like memoserv. There is an interest to make this responsibility part of the server in IRCv3, though.
IRC scales much, much better than Slack. Unreal or InspIRCd or Charybdis whatever - Slack fails miserably for hundreds of thousands of users in one "team"/network.
I do agree administering/configuring IRC servers has to get nicer. I personally want an IRC server that exposes a REST API for online configuration (no rehashing of a config file).
99.9% of Slack users don't give a shit about hundreds of thousands of users in on network. Slack scales better than IRC at anything other than absurd rates.
I don't understand your point - Slack can't scale for extremely large teams well. I've watched the desktop and web app grind to a halt on the first load of a channel because it's still loading in channel history/offline messages. Beyond that, when trying to tab-complete a nickname this similarly almost freezes the desktop app. This has been my experience as part of a team on Slack that has 4000+ users. These are client-side problems, really - but I don't see how you can say Slack scales better when all of its [great] features come at a cost that limit how large a team can be. The larger the team, the more noticeable it becomes.
The history should load in progressively as needed. Switching channels within the same team should be instant. I don't know how you fail at tab-completing nicknames and commands, but somehow they made that slow. I get the feeling rendering is not on a separate thread in the desktop app.
Anyway, you're right that not everyone needs to be on 7-9 networks with the ability to talk to everyone among those. Slack is great for teams of like 500 people and less (imo).
I think their point is that open standards are good for user experience. Can you imagine if each browser implemented their own hypertext format instead of html? Or Stylesheet language beside css? Or they used their own application protocol instead of http? Or if email wasn't federated; Can you imagine not being able to send emails between networks, so nodamage@gmail.com couldn't email smadge@myuniversity.edu? No matter how good the user experience of these nonstandard protocols and formats were, the user would suffer.
if only getting external collaborators or non-technical users into IRC didn't involve sending them a 15-step howto on configuring screen and ssh and could be as simple as "check your email and click the link you get"
and, if only there was push button per channel access control set up out of the box so that some users can join some channels but not others! no, not channel keys, those are busted (what do we do when someone stops being involved in a channel? rotate the channel key?)
there's way more in slack than IRC, so there needs to be way more in a slack killer than IRC...
The question should be "why not use a self hosted irc client instead".
At least developers will use IRC anyway to get and stay in touch with open source projects and the countless communities that have their own irc server/channel. Why not use one protocol that's widely used?
because they're not user friendly, and my company wants to stay in touch with more than the developers. with slack, we can have all the admin and sales staff in the same virtual space as developers and operations - how easy is it to do that with IRC?
Discord isn't open source, AFAIK. Like Slack it's another data locker. And IRC isn't a solution because of it's age and issues like offline access and relatively poor clients.
Where I work, not even a very large startup, we spend a lot of venture money on a PR firm. It's pretty common for a PR firm to push content to journalists and blog writers and really it works nicely most of the time. It bugs me in this case though if it is a PR fluff piece.
Eh, the number of downvotes I'm seeing for a contrary opinion to article about something not really controversial is also pretty weird. Seems like evidence of a concerted promotional push on HN to be honest, if only anecdotally.
The first few times these discussions were interesting. But for every submission mentioning Slack, somebody has to come and claim that IRC is all anybody ever needed, and all the arguments have been rehashed over and over. The alternatives mentioned in the article on the other hand are barely discussed at all.
I find it interesting that all those who claim IRC is insufficient or is too hard to implement (they say the same about XMPP) don't ever seem to say what is so hard, or mention the features that are missing.
As soon as you say "run a bouncer" you limit your audience severely. Without a bouncer, you're a transient in the world of IRC. Doubly so if you have the temerity to want to interact from a mobile device that pops on and off networks all the time.
I was in the LCA2016 IRC channel and at LCA2016 in person. I really wish we could have CCC [1] levels of "audience participation" because it allows people to interact with the conference who may not normally be able to attend. The live streaming was really well done but I think there needs to be One True Chat Channel for LCA2017. Maybe that means using Slack or similar and swallowing a bit of FOSS pride for a while.
Because such comments are at this point inane and uninteresting. As has been mentioned ad nauseum, Slack and friends are winning because IRC is a pain and lacks really basic creature comforts like offline messages and anything but text.
I'm downvoting them as I see them for this reason. Anyone saying "Why not IRC?" to the question of "Slack alternative?" is being willfully ignorant at this point.
Same goes to those who accuse people of astroturfing absent evidence other than "$ideaILike is being downvoted".
Only as inane and uninteresting as the comment you just posted.
You can't impute motives why someone might ask that question. You may feel it has been repeated ad nauseum but it's quite possible those asking the question haven't read the previous HN comments.
I'm sorry but from where i am it's not "contrary opinions" being downvoted, it's useless dribble.
Hell one of the downvoted comments is just "IRC comes to mind"... Just hand waving away all of the problems that something like slack is trying to solve, which the article talks about.
It's not even that great of an article, and yet it's the top post on HN? I hope at least dang looks at the data. I'm sorry it's pretty suspicious. Like what is so notable about this post that it warrants being at the top? Above the living social layoffs and the various other way more interesting things on the front page right now.
Worst case, it turns out being a legit article, in which case it's cool. Eh, no big deal.
If you're worried about the upvotes on the article, they're definitely legit (as far as we can tell). I suspect it's as simple as that Slack is a hot topic (for or against) and people here like open source. And are passionate about chat software.
if only IRC was sufficient for the needs of modern workplaces. We use it, but it requires you do things like write a bot just to send a message to someone who is offline or store history so you can refer to it later.
IRC lacks message persistence across devices and sessions, which is a hard requirement today. It could be implemented but would require distributed storage, queueing, etc. between servers.
Messaging protocols are largely fungible these days, which makes them irrelevant implementation details. A major reason for the success of Slack is around the end-to-end UX. It's not "perfect", whatever that means, but it has met important needs that the "well, we already have IRC!" portion of the world has apparently never dreamed of.
That's Slack's main feature. Well that and gifs. IRC on the other hand is
James has left the channel.
Bill has left the channel.
Samantha has joined the channel.
Samantha has left the channel.
filled with worthless status updates
Martha has gone idle
that make it
Bill has joined the channel.
terribly easy to
Bill has changed the channel topic to "ZOMG! Ponies!"
miss things
Martha has become active
Martha has left the channel.
Well, in Slack, you don't leave by disconnecting, so that lowers the volume of people joining/quitting because they moved their laptop.
It doesn't help that IRC tends to get used in places where massive amounts of users are expected. I feel some of the newbie clients should just hide by default join/quit spam.
So I can point my run-off-the-mill IRC client to a slack server and partake in cat pictures exchanging and almost-NSFW-but-not-quite with my fellow coworkers, yes?
Otherwise whatever it uses inside its walled garden is completely irrelevant I'm afraid.
They have an IRC bridge you can connect your IRC client to. It probably can't do all the things (because IRC has no way of expressing them, and I wouldn't be surprised if they didn't spend too much effort on it), but it works.
You actually can use a regular IRC client with Slack. Though obviously anything that isn't supported natively by IRC comes through as a URL or encoded somehow.
Oh wait, IRC.