If IRC were good enough to handle the needs of small software company communication, people would use IRC. Sitting here pretending everyone just doesn't know about a 20+ year old technology is comical.
The "IRC Features" section bugs me, too. Unless you run a private IRC server IRC has a long, tortured history of design-based security difficulties. Gone are the days of netsplits permanently owning channels, but the so called "distributed" design of IRC makes it very brittle and easy to deny service.
Oh, and did you know that with modest, low volume channels (>200 <1000, some networks tolerate more) you can make IRC networks struggle? Turns out that their lousy distributed design hurts more than helps when single channels get heavy.
Slack also offers a logging service that, for what it's worth, is configured correctly and secured by default. For organizations with 1-3 technical staff, maintaining and securing a reasonable approximation of Slack's feature is probably time better spent working on your product.
IRC is a classic example of the "it's broke but we don't fix it because it's familiar" mentality of old school services. While it may be a good choice for running low-volume (<500 users) public communication. Most tooling around it is woefully inadequate and often tedious to use for small software-oriented teams where Slack thrives.
But if you're genuinely concerned about security, HipChat will sell you a whitelabel product you can host and monitor and its setup is quite good for what it is.
> If IRC were good enough to handle the needs of small software company communication, people would use IRC. Sitting here pretending everyone just doesn't know about a 20+ year old technology is comical.
I'd just like to point out that this argument ("if <x> were so great, everyone would already use/do <x>") is just a slightly different form of the ancient appeal to popularity argument and is entirely fallacious.
Respectfully, I disagree. In many cases, things are popular because they are better/easier for a given audience. I'm a smart guy, have managed (and continue to manage) many, many UNIX-based services, and have run several IRC daemons in my life.
I still use Slack for internal use, and for our students.
What makes Slack (and its ilk, though the title of the post makes a bias against Slack clear) so great is that it's simple, easy, full-featured and has a low barrier to entry to the non-HN crowd that is being asked, in many cases, to use it.
I can promise you, out of experience and out of just plain statistics, that Slack and IRC have different audiences, and those audiences will not likely prefer the other.
Also, I'd guess that IRC is actually the more popular choice. But the majority of the IRC using audience is too busy getting work done in IRC to comment on an HN post.
I didn't mean to imply it was causal. I implied that the industry is full of people who know about the product comparison and make exactly the opposite value judgement.
Whatever gave you the impression I think this is causal?
That the reasoning is fallacious doesn't make the conclusion incorrect. I could argue that 1+1=2 because when I looked directly into the sun today both my eyes closed. The reasoning is wrong, but the conclusion is true.
Similarly here, you could argue that the popularity argument is stronger because the tools are relatively easy to switch between and people are constantly re-evaluating this choice as new projects are created. Lock in and other switching costs bolster the concern of relying on popularity, but those don't come into play very strongly here.
IRC is used by many projects small and big and I've used it in a few companies as well, it's not like it's an absurd concept.
I don't know if Slack is better or worse (I've never used it, I thought the title was talking about Slackware linux which seemed odd) but you draw a much bleaker portrait of IRC than what I experience day to day using it extensively.
Now if you want to talk about mailing lists I might side with you...
I'm being brutally real. IRC is a brittle, aged, poorly designed protocol even by the standards of 1988 academia. You could design a more robust centralized service just by using off the shelf components today.
Seriously. Use off the shelf Google Container Engine stuff along with some modest websocket work and even relative neophyte will end up with a more robust service with better scaling characteristics.
Really, that's why stuff like Slack and Hipchat exist. Becuase it's not really all that hard to do a much better implementation than what IRC can feasibly do.
What people here aren't getting is that IRC and a listserv aren't still used because they have the most features or are the most brilliantly designed pieces of software for the job, it's the best because it's a standard.
I have IRSSI always running in a remote screen session. I read many mailing lists. It's not just my personal preference, it's part of my workflow. When I hit a problem, my immediate reaction after consulting the docs or google is to ask a question on a relevant IRC channel or hit up a mailing list. I don't think I'm the only one that works like this, either.
So asking me to use hipsterchat or slack or gitter or trello or whatever means another another client, and not one that's going to replace my other client, but in addition to it. That's not good. If it had some amazing features other than emoji and fluff, I'd be open to it. But they really don't. People get work done with IRC and a listserv, and that's all that matters.
Let's be honest, Trello and Slack have taken off because young developers aren't familiar with this system and are taking to a new one. And maybe in a few years they will become the norm and my argument will no longer be valid because my workflow will change.
But until that point comes, I agree wholeheartedly that it's a bad choice for FOSS communities, on top of the fact that these are paid services and you're locked out of control of your communications if they decide it's better for their bottom line. That alone seems antithetical to the idea of free software.
Slack is basically IRC with "subjectively nicer" design and helpful integrations, e.g. your builds, deployment, compilation progress can show up on separate channels, you can see if somebody mentioned you on twitter etc. You get the idea. Principally it's just extended IRC, maybe they even use slightly modified IRC protocol underneath for anything chat-wise.
IRC usage stats are really bad. Steady decline from 1 million users in 2003 to 400k in 2012. In a time where we're talking about communication apps with hundreds of millions of users, not even having a million is pretty telling to me.
A lot of IRC usage used to be purely social. So the fact that that are lots less users isn't really indicative of anything in the context of FOSS development.
IRC population has also become harder to track because more people now set up cottage networks that have one server and only host a few channels. There was an article a few years ago discussing this exodus from big networks which I'm having trouble bringing up now.
The worst that can happen to IRC is something like Usenet's death - growing too popular to scale. But scaling isn't of primary importance because a network hosting 100,000 channels is only mildly more convenient than 100 networks hosting 1,000 channels each. Nobody wants a chat stream that looks like a popular Twitch channel, because there is no longer any signal when that happens, so big channels are outliers. (And Twitch chat is IRC-based itself - demonstrating how much this technology is a commodity.)
IRC isn't going to stagnate completely until people decide to give up on text-based chat. The main thing it has trouble with is new client features like inline images.
IRC's userbase is consolidating around the OSS crowd, hence Freenode exploding in popularity while other networks falter. Unlike regular consumers, OSS people understand the value of minimum-common-denominator networks, interoperability and openness.
When most people will do all their chatting in Facebook or Slack, OSS developers will still use IRC.
Things decreasing doesn't necessary tell anything worthy. IRC is less used, but it's still used, and used a lot, and guess what, one can find a lot and lot of very rare and interesting people and data there. All of this without heavy hardware nor software requirements, or even psychological, it's still the same old IRC system, no change required.
>Unless you run a private IRC server IRC has a long, tortured history of design-based security difficulties.
So run a private IRC server? This is a weird caveat, like complaining that angelfire is an insufficient web platform and you have to run your own http server to do well. There are a billion IRC clients, libraries, and bots out there. There are IRC servers in most distros. There are JS servers in NPM. Why not use them?
Companies are using Slack because they explicitly don't want to have to deal with this and would rather someone else take care of their chat infrastructure, and with more features.
But I like the Emacs shortcuts! And "buffer" is a sensible way to describe an opened file. It has worked for decades and will continue to work for decades more! Get off my lawn, whippersnappers!
> Oh, and did you know that with modest, low volume channels (>200 <1000, some networks tolerate more) you can make IRC networks struggle? Turns out that their lousy distributed design hurts more than helps when single channels get heavy.
source? or at least names of networks/IRCds?
freenode at least has 19 channels with more than 1000 users currently, and one with just barely more than 2000.
##linux 2072 :It's official! We're now Linux.Chat! | Channel website: http://linux.chat | Pastebin: http://paste.linux.chat | Spammers or trolls? use !ops <troll's nick> <reason>". | For op assistance, join ##linux-ops | Feel at home and enjoy your stay
#ubuntu 1798 :Official Ubuntu Support Channel | IRC Guidelines: http://ubottu.com/y/gl | IRC info: http://ubottu.com/y/irc | Pastes to http://paste.ubuntu.com/ | Download: http://ubottu.com/y/dl | Currently supported: 12.04 LTS, 14.04 LTS, 15.04, 15.10
#python 1763 :Don't paste, use https://bpaste.net/+python | http://bit.ly/psf-coc | NO LOL | Tutorial: http://bit.ly/MCAhYx | New programmer? http://goo.gl/c170V | Specify 2.x or 3.x in your question | Find your local User Group: http://goo.gl/S1Zsq | #python-fr #python.de #python-es #python.tw #python.pl #python-br #python-nl #python-ir #python.it #python-ro #python-india #python-hu #python-dev
#debian 1707 :Debian 8 Jessie released! /msg dpkg jessie ; /msg dpkg wheezy->jessie ; /msg dpkg install jessie | current point releases: /msg dpkg 8.2; /msg dpkg 7.9 | NO FLOOD: /msg dpkg paste | /msg bots NOT people | offtopic: #debian-offtopic | testing/unstable: #debian-next (irc.oftc.net) | chanlogs: /msg dpkg irclog
#archlinux 1655 :Welcome to Arch Linux World Domination, Inc. <+> Be kind to the people who are helping you. Be kind to the people you are trying to help. <+> FOSDEM 2016 participation! https://lists.archlinux.org/pipermail/arch-events/2015-October/000544.html <+> Yes we know about Twitch
#freenode 1566 :Welcome to #freenode | tor-sasl is offline until further notice | Staff are voiced; some may also be on /stats p -- you can /msg us at any time | FAQ: https://freenode.net/faq.shtml | Channel guidelines: https://freenode.net/poundfreenode.shtml | Blog: https://blog.freenode.net | Be nice!
#haskell 1505 :http://www.haskell.org/ | https://wiki.haskell.org/IRC_channel | Paste code/errors: http://lpaste.net/new/haskell | Logs: http://tunes.org/~nef/logs/haskell/?C=M;O=D http://ircbrowse.net/day/haskell/today?mode=recent | http://reddit.com/r/haskell | Administrative issues: #haskell-ops | Hackage status? http://status.haskell.org | http://downloads.haskell.org
#Node.js 1252 :Can't talk? Get registered on freenode (http://freenode.net/faq.shtml#nicksetup ) | Current Stable v5.0.0 (LTS: Argon v4.2.1) | Mission Statement: http://bit.ly/node-irc-mission-statement | Info: http://nodeirc.info | Logs: http://logs.nodejs.org/node.js/index | On codes of conduct: http://j.mp/1RFlyvr http://blog.izs.me/post/30036893703/policy-on-trolling
#go-nuts 1242 :isgo1point5.outyet.org | golang.org | known issues: golang.org/issue | channel log: botbot.me/5/log | don't ask to ask; just ask | ʕ◔ϖ◔ʔ | gophercon2015 videos: https://goo.gl/vKWB3Q
##javascript 1207 :Can't talk? Get registered on freenode (HOWTO: http://freenode.net/faq.shtml#nicksetup ). | ECMAScript, JavaScript. JS *not* Java. | Say "!help" (or ask and wait). | Say "!mdn abc" for docs on "abc". | Don't paste code in the channel.
#git 1169 :We use git, but don't be a git. Help given and wanted, or just gorge on candy | Current stable version: 2.6.2 | Start here: http://jk.gs/git | Getting "cannot send to channel"? /msg gitinfo .voice | Beware the git-reaper this Hallow's Eve: he comes for your rebases
##security 1152 :Computer & Physical Security http://fnsecurity.org/ http://ow.ly/gsVTo | Type !op to summon staff - Be nice or GTFO. -- Toothe is seeking his stalker from a security presentation on Oct 27!
#bitcoin 1126 :Current v0.11.1 | DO NOT POST ADDRESSES | uPnP vuln: https://bitcoin.org/upnp-vulnerability | https://bitcoin.org/ | bitcoin.com is SCAMMY | https://en.bitcoin.it/wiki/Faq | No pricetalk (#bitcoin-pricetalk), ads, trading (#bitcoin-otc), begging, altcoins | Web wallets will probably steal your money | URLs are often MALWARE
#ansible 1123 :Ansible - http://docs.ansible.com *** 1.9.4-1 has been released - https://groups.google.com/forum/#!topic/ansible-announce/r_uNM1lWlAE *** Ansible 2.0.0 beta 2 is ready for testing - https://groups.google.com/forum/#!topic/ansible-project/krpeTwi3mpo
#gentoo 1103 : Gentoo Linux Support | Can't speak? /j #gentoo-ops | long pastes: dpaste.org | masked by license? http://x.vu/WgxYLs | | Unworking hibernate and suspend? emerge -1 upower-pm-utils | firmware not loading? http://goo.gl/MzVLBN | perl conflicts? http://goo.gl/n1FMk8 | Be nice! http://xrl.us/kftd
#bash 1082 :FAQ: http://mywiki.wooledge.org/BashFAQ | Guide: http://mywiki.wooledge.org/BashGuide | Ref: http://gnu.org/s/bash/manual | http://wiki.bash-hackers.org/ | http://mywiki.wooledge.org/Quotes | Check your script: http://www.shellcheck.net/ | Mailing list: https://lists.gnu.org/mailman/listinfo/help-bash | Devel: http://xrl.us/bmodjy
##networking 1074 :Computer Networking | If you have a question, just ask it! | Please don't paste - http://paste.debian.net | M = mega = (10^6). m = milli = (10^-3). Mi = mebi = (2^20). B = bytes. b = bits. | Vendor Help = #$vendor | pastebin iptables-save | Why aren't you using IPv6 yet? | IP address classes died in 1993 | VPNs were not designed for anonymity https://goo.gl/iLyXUP
#vim 1050 :Can't Talk? Get Registered on freenode (HOWTO: http://ur1.ca/90niw) | Vim 7.4.900 http://www.vim.org | Don't ask to ask! | Use :help and :helpgrep | WIKI: http://vim.wikia.com | PASTE: http://vpaste.net/?ft=vim | DONATE: http://www.vim.org/sponsor
#puppet 1000 :Puppet Enterprise 2015.2: http://puppetlabs.com/puppet/whats-new | Puppet 4: http://bit.ly/1fCLbPX | Help: http://{ask,docs}.puppetlabs.com | Beaker users read this! http://bit.ly/1zE2DYU | Bugs/Improvements: https://tickets.puppetlabs.com/ | Logged http://bit.ly/11ifvbU | Community guidelines: http://bit.ly/1wTNy65 | PuppetConf Videos http://bit.ly/1NWiHQb
now, the volume of chat may be too much to read for some people, but that's not an issue with the protocol.
Unfortunately, there's little correlation between the number of users joined to a channel and its communication volume. My experience is that the amount of actual communication in IRC tends to be low; many channels have a large user contingent that's simply silently parked there in some dormant screen or tmux session.
We nearly broke EsperNet with about 500 users which were proxies into Minecraft servers. We used a Minecraft mod called EiraIRC. The constant connection and traffic from these users required a fair amount of interaction and management between us and the staff. And Espernet is not a small network by IRC standards.
The problem is that all traffic has to be carried to all nodes brokering connections for a channel. When you have a LOT of traffic this gets onerous.
You CAN scale these channels. But it requires some experience and most people never even consider that there might need to be action taken. The Freenode admins know what they're doing, and I respect them enormously for keeping freenode as responsive as it is on what amounts of a 25 year old, bad implementation of a distributed algorithm.
Considering World of Warcraft guild channels have a configurable "message of the day", I kind of assumed all WoW chat was IRC. I'm sure they break 1000 users in a channel without problems.
Are these limitations in the protocol, or just in the network, especially freenode? If someone were to run a paid, $5-a-month to run a channel with over 20 users IRC network, would they be able to address the difficulties of freenode and EFNet before it? Would SILC fix anything?
> Given A and B, if A were good enough, people would use A... What if B is better? What if both are good enough?
Prior to Slack existing, lots of people who now use Slack weren't using IRC, because Slack offers a lot more.
Everyone I know working in academia or on a startup that uses any kind of instant chat uses Slack. None of them previously used IRC for the same purpose.
And it's just _obvious_ why, once you've used Slack for a while. They're quite different -- IRC is a protocol for real-time discussion on the internet. Slack is a business tool that incorporates real-time discussion.
Allow me to shout into the void for a minute here...
1. Slack is a well-designed interface for allowing teams to communicate via chat.
2. Slack is easy to install is use on Mac, PC, iOS, and Android. It Just Works™.
3. Slack doesn't require me to install IRC somewhere. Which also means I don't have to worry about how people gain connectivity to said server when outside the office.
4. Slack has whimsy. Fun colors, messaging, emoticon, bots, etc.
All of this is what folks in this thread seem to be missing. I've used IRC for a very long time, but have NEVER been successful at getting wide adoption of IRC for communication.
I am well aware that I'm trusting a third party with out information. I'm aware that alternatives exist and you can get them to work. That doesn't matter when I have to try to explain to my CEO how to /join #channel.
There is a reason why IRC, a widely-available, chat solution that has been available for decades didn't catch on. It has nothing to do with how well the software moves messages from one computer to another.
Slack and IRC have two different (but interconnected) use cases. I love IRC, and I haunt a couple servers to chill or to ask an occasional newbie question. I'm pretty comfortable with IRC; it's a part of my culture.
I often find myself needing to establish a line of communication between people who aren't particularly tech-savvy. Slack works excellently for this: I make a new team, fire off some invites, and everyone just understands how it works. I can only imagine that, say, coordinating dev, corporate, and sales over IRC would be like living in the same circle of hell cardinally occupied by people who talk at the theater. If IRC works well for your team (whatever it is), excellent! Don't try to fix something that isn't broken. Slack isn't flawless, but it does have its usecases, and it fills them very nicely.
> 1. Slack is a well-designed interface for allowing teams to communicate via chat.
subjective. I consider a bloated web interface taking several tens to hundreds of megabytes of RAM compared to a text-based interface taking less than 100 kB to be poorly designed.
> 2. Slack is easy to install is use on Mac, PC, iOS, and Android. It Just Works™.
spelled wrong, and IRC clients are harder to configure only because there are so many options for servers, whereas Slack only supports one server.
> 3. Slack doesn't require me to install IRC somewhere. Which also means I don't have to worry about how people gain connectivity to said server when outside the office.
webchat was invented for a reason
> 4. Slack has whimsy. Fun colors, messaging, emoticon, bots, etc.
IRC has had mIRC-style colors supported and even adjustable by the majority of clients for at least 10 years. I don't know what "messaging" means. If you mean "private messaging", pretty much every chat software in the world has that. AOL and ICQ have that. You can put emoticons in your text manually if you want. It was on IRC that the concept of chat bots was invented, not on Slack.
> There is a reason why IRC, a widely-available, chat solution that has been available for decades didn't catch on. It has nothing to do with how well the software moves messages from one computer to another.
Yes, it is about how much money a for-profit company has to spend on marketing and copy as opposed to a standards organization.
This whole response reads like it was written in the 90's. Most people don't care if something takes up 10's of MB's of RAM when new PC's are shipping with 16-32GB standard.
Your comparison of what amounts to ASCII art versus Slack's rich-media embedding reads like it is straight out of a Fortran developer's "I'm still relevant" handbook. You even offer up AOL and ICQ as counter examples!
If we're going there, I guess we should simply assign everyone a GUID and be done with it, right?
Most non-technical users don't care how much memory their chat client takes up as long as it works. They also don't care what server they need to connect to as long as they can communicate with the people they need to — less is more in this case.
Slack has its fair share of flaws but design and ease of use are not among them.
We have learned absolutely nothing. Let's all jump on the bandwagon of another closed-source, proprietary, walled-garden service and hand over all of our private intra-company communications to a private third-party in another country. GREAT IDEA.
Agreed, but with that said... IRC has serious issues, and dancing around them or pretending they're not there is not helping. I talk a bit about them here:
The reason Slack exists and can be so successful yet entirely proprietary is a symptom that IRC is not good enough and that has to be fixed. It is the manifestation of the papercuts we, IRC users, have been having for a long time now. (late edit: If you are interested in fixing this problem, email me, see my profile.)
There are very promising efforts on IRCv3 (http://ircv3.net/) ongoing. I hope they eventually go live to the bigger clients and networks so that we may actually have a good foss alternative to slack (and I don't mean something like Mattermost. Like SirCmpwn said some comments below, having one browser tab per project REALLY SUCKS when you contribute to a lot of projects. I'm in over 20 channels myself, and I do my best to keep that number low...).
I really resonate with this position. IRC is open source and it has had problems FOR DECADES. IM programs from third parties add genuinely useful features which people clearly want. So rather than call for a general boycott of Slack (a negative approach) why not call to fix IRC?
What is wrong with Mattermost? I've never actually used it, but it seems like a better OSS slack competitor than irc. If it really is just the problem of 1 project per tab, surely fixing that minor issue is easier than a whole new IRC spec?
irccloud.com (disclaimer: I'm a subscriber) addresses a number of the deficiencies of standard IRC.
A lot of the other deficiencies are a consequence of any decentralized, open resource, due to "tragedy of the commons" effects. Those will always require active admin participation to resolve.
Freenode sometimes does get a lot of abuse, which is a shame. Some networks definitely do have better anti-spam and anti-botnet functionality, but I don't think most users ever even notice this. Even on Freenode, most channels will go without problems like botnets or channel takeovers for most or all of their life.
If you're running your own irc server, you'll probably never notice anything. If you do, it's as simple as adding a server password (or maybe even changing the default port among some other settings), and anything unwanted will likely be a thing of the past (assuming you don't have dedicated people attacking you).
On your comment about IRC bots and services, networks don't see that as something that is up to them. If something requires a U:line or other network privileges, then it's up to the network staff to implement that, sure, but anything else is for their users to do. If IRC networks were for-profit, maybe you could expect them to have things like this and advertise how amazing all of their features are to potential clients. But IRC is nothing but a money sink for everyone involved, and there's therefore often little incentive for networks to implement and integrate a lot of bots and functionality that aren't integral to network operation.
Apart from this, spam is a really hard problem if there are resourceful people dedicated to it. Email has existed for even longer than IRC, and despite absurd amounts of work into anti-spam systems and functionality with it, it's not too surprising when spam manages to finds its way into your mailbox.
I still agree there's a lot of room for improvement, both at the protocol level and at the user level, though.
> Let's all jump on the bandwagon of another closed-source, proprietary, walled-garden service and hand over all of our private intra-company communications to a private third-party in another country. GREAT IDEA.
Well said, I chuckled. Let me just add something...
If you want a paper trail of anything, use an email you own.
I have a friend who was locked out of a startup's Slack right before he was due to be paid for three months of work. He had been discussing business inside of Slack, and instantly lost access to all of those messages.
Could this have happened if the startup used a private email server, or a private IRC server? Of course. But if they were using more open protocols, he would have at least been able to back up the messages. Slack provides an easy tool for backups to admins, but not for normal team members. Slack provides an API for all users, but team admins can disable the API. Slack also allows team members to connect over IRC and XMPP, if team admins turn on that feature (https://slack.zendesk.com/hc/en-us/articles/201727913-Connec...).
Slack is great, I love using it. Just remember who owns the data. Always use your own personal email if you want to create a papertrail, as my friend found out.
Uh, in both cases "not the user", your friend using any other system unless he decided to back it up would have been locked out anyway unless he was using a localised system like POP3... Most systems allow admins to block/prevent data exports one way or another. He could have copied and pasted the slack history if he wanted a copy as easily as he could have backed up gmail / irc / etc....
> We have learned absolutely nothing. Let's all jump on the bandwagon of another closed-source, proprietary, walled-garden service and hand over all of our private intra-company communications to a private third-party in another country. GREAT IDEA.
So don't use AWS or Google App Engine or Heroku? etc. Why?
I use Facebook for a lot of my communications. Seems to be working out OK so far.
Use the tools that help you get your work done efficiently. Consider the long-term consequences, of course, but if someone took all of my Slack team messages and told me I couldn't have them back, I'd be annoyed but it wouldn't affect my productivity much.
OTOH, losing the ability to coordinate via Slack, as you're suggesting, would certainly lower my productivity.
> So don't use AWS or Google App Engine or Heroku? etc. Why?
Leaving aside that there are extremely valid reasons not to use those services, communication is a huge deal. Can you imagine if email was a walled garden?
I feel like that has to diminish the walled-garden, proprietary weight at least a little bit if slack & irssi can communicate. And it works over SSL too. Once I started doing that, I didn't mind using slack. You have to "/ignore" certain server messages though or your whole screen will be spammed with them and you'll barely see the stuff people are saying.
> another closed-source, proprietary, walled-garden service and hand over all of our private intra-company communications to a private third-party
Amen to that. Our company yet to transition away from using Salesforce, but we greatly restrict its use for the reasons above, and one day will move completely away from it.
Not only is there IRC, which many people have talked about, there is also chat over XMPP, which is how I prefer to use slack. The alternatives are worse in connectability, because they restrict you to one narrow range of clients and protocols, instead of letting you choose the right client for the job at hand. People use services like slack because they don't want to have to give a shit about communications, they just have something that works.
And you used to be able to get an RSS feed from twitter. Things in walled gardens tend to have a habit of disappearing when interoperability no longer seems to be in the proprietor's interest.
This is one of the better reasons for opting for open-source alternatives to new technologies.
If you have a single person that is even slightly technical, it should be trivial to set up your own IRC server, and then you get complete control over all of your own information.
Even with that, you still can choose from a multitude of servers, services, clients, bots, client scripts, bouncers, and so on. Anything common you want to add on after that point has likely already been written for what your purposes (and is of course open-source), whether it's a git commit bot, a logging/relay bot, or even end-to-end encryption (even after TLS). It's even quick to write custom IRC bots for arbitrary purposes if you use a framework or copy some example code (even without that, it is only so bad).
> If you have a single person that is even slightly technical, it should be trivial to set up your own IRC server, and then you get complete control over all of your own information.
That's a pretty narrow view of 'slightly technical'.
These days, we've got generations of people who can manage their own email account setup, install web apps and mysql databases, configure zapier to connect multiple apps together within a few minutes. I know dozens of people who do things like this all day long for their clients.
I'd call all these people more than "slightly technical", but there's no way on earth they'd be qualified to set up and administer an IRC server.
You need far more than "slightly technical". "Slightly technical" sets you up for disaster. And... it's not 'trivial' to understand what's going on and how to manage it.
I agree, though, it should be trivial. It's just not.
Good luck pretending than "setting-up your own IRC server" is easier than not having to care about such a thing, and that most people really enjoy to have to "choose from a multitude of servers, services, clients, bots, client scripts, bouncers, and myriad of bots" instead of just going to https://slack.com/downloads
The article does not even discuss the fact that projects that opened a slack community with a big increase in their audience. Apparently audience is much less important than purity.
> If you have a single person that is even slightly technical, it should be trivial to set up your own IRC server, and then you get complete control over all of your own information.
I'm "slightly" technical and I have absolutely no interest in setting up an IRC server for my project or company. That's time better spent on developing our offerings. While I have no doubt I could set up a server, I also have no doubt that setting it up and maintaining it would drain time unnecessarily.
It's the same reason that I don't advocate for most people to maintain their own servers in 2015.
I agree with this completely.
I hate that we now have SO many competing protocols that do basically the same darn thing and NOBODY wants interoperability!
I really don't get this, 99% of the stuff you use everyday is closed-source and proprietary. Most often the tradeoff in something bad happening (which has yet to be with Slack) versus having a functional and productive system is more than worth it.
Or do you also build your own computer from raw silicon and communicate with pirated radio signals?
As usual, I'm (not) surprised by the downvotes but no real exposition here. What's the collective freakout over what Slack is going to do? So the features and user experience aren't worth it? Why isn't everyone on IRC then?
If some basic programming chat about an open source project isn't safe then we should all throw away our phones and turn off the internet immediately, but I don't see that happening. This is basically bikeshedding on how to run open source projects.
Not sure why I would want to self host what is effectively a phone system. I have actual products to build. We could ease time self hosting source control as well -- to what end? I have members of the team spending time (and thus money) setting up something that pleases people philosophically but really adds zero value -- in fact, it actually costs money (through very expensive developer time.)
I don't get the point of complaining about Slack. It works great, it's simple to use and it has an amazing feature set. IRC is pretty terrible. Try doing a drag and drop file transfer. Try using markdown. Try displaying images inline.
I don't get what the problem is with closed source Slack. Do we avoid the phone company because their software is closed source? There comes a point where this FOSS obsession sort of jumps the shark. Worrying about a 'walled garden' for a chat tool is kind of silly. If it bothers people so much, create a FOSS Slack with the ease of use and setup and maybe people would be more interested. But anything that requires me to 'self host' something that amounts to a service means that is a bad use of time. I can pay the Slack guys to maintain chat while my devs work on maintaining our products. IRC is terrible. Try and get someone from your marketing department to use IRC. The neck beard and almost hipster pontification about the 'bloat' of Slack is kind of ridiculous. We have better things to worry about. Slack works on all my devices perfectly. I have a searchable log of everything. I don't have to think or worry about anything. It's simple and works. Until there's a viable alternative that exceeds Slack's ease of use, that's what I recommend people use.
It's interesting how you compare Slack with a phone company. There are important differences between Slack and a phone company. 1. If you give me your phone number I could be talking with you in a few seconds without me even knowing the name of our phone company. 2. You could decide to change your phone service provider and (in some countries) even keep your number.
How would you do these things with Slack? Slack is great, and I like it, but it could stop being great at some point in the future.
(Yes, I realize that Rocket.Chat user couldn't chat with Zulip user, for example. That's why I'm excited about efforts like https://matrix.org/.)
I agree with you: it's expensive to self-host. [1] But when it is possible to self-host, you could hire a specialized company to host the chat system for you. And - if you are careful - you can later switch your chat-system-hosting provider if you want.
> Not sure why I would want to self host what is effectively a phone system
That's an interesting parallel. I suppose it would technically be possible for a company to out-source their internal phone system to an external third-party using VOIP. But I've never seen it done and I don't know how I would persuade a CTO that it's a good idea to make internal communication reliant on the Internet.
Yet companies are falling over themselves to out-source internal IM... why?
> Not sure why I would want to self host what is effectively a phone system.
Because you work in an industry were security matters. Such as banking, healthcare, government, government contracting, or any business with more than a couple hundred folks.
Because you provide support and want to customize / integrate that with rest of your data/systems to provide superior service to customers.
On my last evaluation, I found the two most interesting to look at matrix and tox.chat. But in the context of a slack-alternative, matrix is definitely the one to look at. Also has an IRC bridge: https://github.com/matrix-org/matrix-appservice-irc
As for XMPP, I think it is still entirely viable as an alternative to using a brand new protocol and brand new clients and servers. But if you want solid off-line messaging, server-side logging and scalable group chat -- there aren't any out-of-the box combination of free/open servers and clients that will work, as far as I've been able to figure out. I assume one would want a solid command line client, solid gui clients for Windows, OSX, Linux/BSD, Android, iOS and Windows phone, along with a good web client.
I don't think you can pick-and-choose a XMPP server and clients that will provide all that, today. It is certainly possible to make that, standing on the shoulders of various open projects -- but the effort would be anything but trivial. I'd be happy to be proved wrong, though!
Unfortunately XMPP didn't take off. Notice how it's nowhere near as ubiquitous as email and web standards. Also notice how nearly all modern chat services don't support XMPP. I'd argue there are technical reasons for this situation. Try searching for "XMPP" in this thread for details.
It is reasonable to raise the point that building FOSS software while using a closed piece of software as a core tool bears consideration.
However, I am 25 and largely missed the boat on irc. I decided to start using it ~1 year ago. It is hard to use, but we will look at that in a minute. Often, we assume people have as clear an idea of what we are talking about as we do. That is often not the case. Let's explore IRC now.
* Integration has never been a problem ... build bots.
I feel silly and naive, should I know how to set this up? Maybe it is really easy and well documented, and I am an edge case here, but i don't know how to do this. I clicked 3 buttons to setup github for slack. It was very easy and I didn't haystack through building a solution to something that exists. Scope creep on tooling is dangerous as an aside. Thos takes that off the table.
* persistence
again, I have to set up an alternate tool to download the content. i assume this would backup the whole channel so any user could reference it, but it comes by default for free with slack. if each user must have a seperate tool, or go to a seperate place to see a conversation (which may be less searchable) it adds friction.
* code snippets
actually super reasonable to use pastebin. slack is at least as annoying for code as pastebin, if not more.
* etc
The point is, not everyone lnows as much as the author about IRC who is likely quite a talented developer who grew up on it. An 18 year old likely won't have used irc as much as older generations given the plethora of tools and chat clients.
FOSS is a choice and a philosophy and that should be given some degree of consideration. Utility, workflow and getting new devs onboard and contributing is important. I agree with the author that it bears consideration, but slack or hipchat are much easier than IRC.
It's worth mentioning that Zulip (https://zulip.org/) is a new open source option that has basically all the features IRC/Slack does. So using open source tools for open source development doesn't have to mean dealing with IRC's limitations.
(I'm one of the Zulip maintainers; happy to answer any questions about it).
I've been meaning to give Zulip a try. How many users can it handle?
Less importantly:
What would you say its biggest missing feature is vs Slack? And conversely what does it bring to the table that Slack can't touch yet?
I'm excited about Zulip as a Slack-style tool, especially for teams. (Separate from the discussion of whether FOSS project collaboration should be Slackish or IRCish.)
Are there any plans to support multiple teams / multiple servers from the native client? This is a particularly acute pain point on mobile; I'm reluctant to promote any tool that requires me to be logged in to only one project's instance of the tool at a time, because if it works well, it gets adopted for other projects, and then I'm having to juggle clients. I am unfortunately on two projects that use HipChat, and even there it's a huge pain that I can't be logged in to both simultaneously on my phone. (Some of their desktop apps finally support multiteam which is a huge help, but I still have to pick just one to participate in on mobile..)
Slack isn't perfect, but at least all the native clients will let me be logged in to 5 teams at the same time. (And no, opening multiple browser tabs is not an appropriate solution - it doesn't work at all on iOS, for example.) And obviously, this is something IRC does a great job of as well.
First, let me say that I'm really happy zulip was opened up, and grateful for you and your team to support it.
But does Zulip support server federation? Obviously slack doesn't allow self-host, so if slack is the alternative, that doesn't really make much of a difference. But that is one feature that http://matrix.org/does support.
Ehh, as someone your age (a couple years younger even), I have a completely different take on IRC.
It's incredibly intuitive because it's so similar to all the other chat clients we grew up with (presumably because they're based on IRC).
Sure, figuring out bouncers and build bots is a little tricky at first, but so what? That's the fun part. It's kinda fun digging into the IRC protocol and figuring out how it works.
And ok, if that's not fun for you, there are plenty of really "click and install" tools for you (e.g. ZNC is super easy to setup).
Not to sound like an elitist prick, but if you can't figure out how to setup an IRC bouncer, I'm not sure I really trust you contributing to the linux kernel, yaknow?
Reducing friction is great: But the kind of friction we should be trying to reduce is bureaucratic friction. Throwing out PRs and yelling at people because they forgot to cc some particular maintainer - that's the kind of friction that sucks. Having to setup an IRC bouncer? Idk, I think that's fine.
Same age group: Which chat systems were similar to IRC, but not to Slack, outside of IRC clients?
And just because someone doesn't want to spend the time fiddling with IRC bouncers, IRC bots, getting clients to display things nicely doesn't mean that they are a bad developer. Just that they have different priorities for their time than you.
I'm not saying that Slack is perfect or frictionless, but neither is IRC. And especially if you don't do it all the time, getting people set up to work with Slack is way easier than IRC.
I really find these discussions half amusing and half depressing. 2 sides have something that is "good enough", both insist that nearly all you want can be solved with their solution, especially if you just do X1,X2,X3,Y1,Y5, and Z4 and you technically could build something that is perfect for both on top: but sadly (and understandably) no-one actually cares enough to do so. Because what they have is "good enough"(TM).
I meant that software can be a philosophy or a project, and where you land on this concept will inform your decision making process. I agree with your above comment and don't find it contradictory to mine above.
Some great tools for software development:
* Microsoft
* OS X
* Linux
* Free BSD
To some degree that represents a spectrum and I don't fault the author for having strong beliefs about how software should be built, and agree with them for the most part. I think he could have made a stronger point generally from a philosophical and technical angle, i.e the regular arguments for open source tools, and highlight Slack as an example.
IRC is quite similar to Slack, but for the reasons the author suggests, it is different.
I don't think you sound like an elitist prick, but rather the kind of person that enjoys tinkering with technology for fun. Perhaps unfortunately, this view is no longer representative of most people working in technology, and definitely not all of the users of Slack.
Given how terrible the HipChat client is on Windows, it's really saying a lot that people end up choosing that over IRC.
Maybe Freenode could implement an enhanced IRC protocol and clients could opt-in to that.
I know at least one project that was very active on IRC, and they moved to HipChat for convenience. They also went full-on with the entire Atlassian stack (again, the fact anyone would choose JIRA is damning against everything else.)
I actively avoided IRC for years. I still avoid it whenever possible. And I've been developing and sysadmining for the web for more than 10 years now.
Frankly, it boils down to that I just don't like it. I'm more interested in getting better at programming, or learning about containers, or some other useful thing, than trying to figure out IRC's odd interface. Chat isn't something I should have to think about. It should just work.
So, I agree with most of what @vonklaus said, and disagree with the links pro-irc stance.
I've never used Slack, so I have no opinion on it.
You can master IRC with a few basic commands. In fact I rarely have to use anything more than /join, /leave and /msg <someone>. /me <some text> for announcing an action. That's about it.
(It probably helps that a lot of in-game chat interfaces use a lot of these same commands, as I'm a gamer as well as a programmer.)
There's a pretty nice web interface to IRC called irccloud.com which also persists your connection (so you can simply log onto irccloud.com somewhere else, and entire history is preserved).
The author makes a huge list of all the things Slack does and then goes on to suggest time-consuming ways to hack standard IRC clients to do the same thing. The question is: why in this day and age should we have to do that?
Have you ever noticed just how many open source projects are still using shitty software from the 90s? No doubt, some of that software is actually quite good but I will argue most of it exists primarily as a result of tradition. In other words: a lot of it isn't the best way to do things presently, and perhaps if we stopped using such mediums as: mailing lists, newsgroups, and IRC channels to run our open source projects then presumably our projects might be filled with more diverse people than dinosaurs that still roam our mailing lists.
I don't know why developers do this: but they assume because they have the skill to do just about anything with technology that other people who also have the skill ought to take the same time to do as they have. But honestly: even developer time is too valuable to waste on pointless shit. We ought to be trying to make things easier to use.
If you don't want to use Slack for open source projects because it's closed-source, fine. That's a reasonable argument.
If you don't want to use Slack for open source projects because Slack is in fact pretty bad at those workloads, fine. I agree! I think Slack does a pretty bad job at any group application where most of the people communicating don't already know each other.
Where you go off the rails is in suggesting that IRC is competitive with Slack. IRC is awful. It's a medium dominated by 7-bit clients with tiny message limits that provides virtually no useful metadata and no works-by-default history or search --- both things that virtually every open source IRC support channel b a d l y needs.
IRC does exactly one thing better than Slack: it's easier to join a new IRC channel than it is to join a new Slack project. The rest of IRC's "features" are red herrings, many of them more harmful than helpful.
Surely by now someone has built a Slack-like, perhaps with decent IRC support, that big open source projects can champion as a Slack- and IRC alternative.
It will be much easier to keep open source projects from trying to fit their square pegs into Slack's round aperture when people give up on promoting IRC.
One reason not to use Slack for FOSS projects that isn't mentioned in the article and has had few people mention here: choosing between short history or ridiculous expense.
The free version of Slack only has a 10k message limit, which runs out very fast with a user count in the 3-figures range. So if you want history, you need to shell out $8/user/mo, which is ridiculously expensive for chat. And not something a FOSS project should be spending it's limited funds on.
Slack has been successful because it's onboarding process is buttery-smooth. They've put a lot of work into making everything easy, from signing up to installing integrations. Unfortunately those integrations also waste a ton of space in the chat window. I use Slack at a couple of companies, and each of them got excited, installed a couple of integrations... and then abandoned the channels with integrations, because they waste so much screen space and you can't follow the flow of a conversation. It's a pity Hipchat got caught napping - they did displaying integrations well.
Another FOSS-specific problem with Slack is that they don't have a linux client, so you have to use the web app, which is terrible when you have to track more than one Slack team - you have to manually switch teams to check for updates, which takes a non-trivial amount of time (and the 'switch' control is right next to the 'sign out' control, which I've accidentally hit a couple of times)
Maybe the things that you claim make IRC "awful" actually have weird benefits in terms of community. Kind of like how HN is kept intentionally awful, to keep out the losers or whatever.
Usually you'll have a bot gather the channel's history that you can ping and most IRC clients collect the history locally. In the use cases that -most- people use Slack for, it's identical to IRC.
I don't use IRC anymore, I use Slack but only because it's convenient. IRC is all over the place like the majority open source projects. Slack is clearly inspired by IRC, but it's in a pretty package and works OOB. Not sure why people are shitting on Slack or IRC here.
> Usually you'll have a bot gather the channel's history that you can ping and most IRC clients collect the history locally. In the use cases that -most- people use Slack for, it's identical to IRC.
Yeah, that's not nearly the same. What I love about HipChat (and I'm sure Slack is the same, but I don't know) is that you can connect from any device and see the room history when you join a room. Going to some website to scroll back to see what people were talking about before you joined is annoying, especially so on a phone.
IIRC, Etsy has an internal chat client for IRC called F-Train that looks to be more or less a clone of the Slack UI. They haven't released it Because Of Reasons™.
This is the perfect counter example to "Open source is better". IRC has been around for 20+ years. But a company that is just a few years old blows it away feature-wise. Sure, you can do all the same stuff in IRC, but look right at the article for why you wouldn't. The answer to every "missing feature" in IRC is to install some extra software and then maintain it.
I'm don't want to waste time doing that, I've got products to build and maintain.
The closed source option is better because they have a financial incentive to keep it that way. And I'm happy to pay for that because it saves me time and lets me work on things for my customers instead of myself.
I'm a huge fan of open source and used to be a zealot about using open source to run my business. But I've started to see the light in my old age.
I generally agree, though I'm not sure financial incentive is the reason. Open source has really shown that financial incentive is (A) complex and (B) not the only thing that motivates people.
If you look at open and closed source across a lot of categories, I think it's more common to see OS "win" where the product is more objective. When it come to more subjective problems like UX, it seems to be more difficult.
If your goal is something fairly objective OS is really amazing. Take VLC's "play everything everywhere" goal. Fantastic, objective goal for and OS project that really plays to its strengths.
Linux is, I guess, the canonical example. It's fantastically successful relative to closed source competitors on every front that is objective. But, its consistently been unsuccessful as a consumer desktop.
That said, I don't think IRC is dead either. Some people/communities prefer IRC.
What you're trying to say is that open source works best when there's little or no design work involved and little or no product vision required.
Linux is a canonical example: it's simply a clone, design wise, of a plain old UNIX. The product vision was "copy UNIX". Where the wheels fell off Linux is the moment it got ahead of the UNIX legacy (i.e. modern desktops) and started having to compete with Windows, so suddenly the "copy UNIX" goal was no longer relevant. But Windows was made by Microsoft, or "the great satan" as Stallman memory called it.
So simply switching the goal to "copy Windows" wasn't possible because Windows and UNIX were very different and anyway, lots of people hated Windows. Linux had picked up a lot of semi-technical and technical users who didn't care much about FOSS purity but loved the club feeling that using an obscure OS brought them. The end result was big splits and bizarre, illogical design decisions being made simply because "do it like Windows did" was ideologically unthinkable, even when Windows had basically got it right (or at least, less wrong).
> This is the perfect counter example to "Open source is better"
Agreed. I think one of the main reasons for this is that cohesive design comes from dictatorships, not from distributed decision-making, i.e. design by committee.
The strength of open source is that it is usually "good enough", rather than "great" or "the best it can be".
Readit News
The "IRC Features" section bugs me, too. Unless you run a private IRC server IRC has a long, tortured history of design-based security difficulties. Gone are the days of netsplits permanently owning channels, but the so called "distributed" design of IRC makes it very brittle and easy to deny service.
Oh, and did you know that with modest, low volume channels (>200 <1000, some networks tolerate more) you can make IRC networks struggle? Turns out that their lousy distributed design hurts more than helps when single channels get heavy.
Slack also offers a logging service that, for what it's worth, is configured correctly and secured by default. For organizations with 1-3 technical staff, maintaining and securing a reasonable approximation of Slack's feature is probably time better spent working on your product.
IRC is a classic example of the "it's broke but we don't fix it because it's familiar" mentality of old school services. While it may be a good choice for running low-volume (<500 users) public communication. Most tooling around it is woefully inadequate and often tedious to use for small software-oriented teams where Slack thrives.
But if you're genuinely concerned about security, HipChat will sell you a whitelabel product you can host and monitor and its setup is quite good for what it is.
I'd just like to point out that this argument ("if <x> were so great, everyone would already use/do <x>") is just a slightly different form of the ancient appeal to popularity argument and is entirely fallacious.
I still use Slack for internal use, and for our students.
What makes Slack (and its ilk, though the title of the post makes a bias against Slack clear) so great is that it's simple, easy, full-featured and has a low barrier to entry to the non-HN crowd that is being asked, in many cases, to use it.
I can promise you, out of experience and out of just plain statistics, that Slack and IRC have different audiences, and those audiences will not likely prefer the other.
Also, I'd guess that IRC is actually the more popular choice. But the majority of the IRC using audience is too busy getting work done in IRC to comment on an HN post.
Whatever gave you the impression I think this is causal?
Similarly here, you could argue that the popularity argument is stronger because the tools are relatively easy to switch between and people are constantly re-evaluating this choice as new projects are created. Lock in and other switching costs bolster the concern of relying on popularity, but those don't come into play very strongly here.
Why does gchat, snapchat, whatsapp, fb messenger exist if AIM had been fulfilling the need of the market?
Dead Comment
I don't know if Slack is better or worse (I've never used it, I thought the title was talking about Slackware linux which seemed odd) but you draw a much bleaker portrait of IRC than what I experience day to day using it extensively.
Now if you want to talk about mailing lists I might side with you...
I'm being brutally real. IRC is a brittle, aged, poorly designed protocol even by the standards of 1988 academia. You could design a more robust centralized service just by using off the shelf components today.
Seriously. Use off the shelf Google Container Engine stuff along with some modest websocket work and even relative neophyte will end up with a more robust service with better scaling characteristics.
Really, that's why stuff like Slack and Hipchat exist. Becuase it's not really all that hard to do a much better implementation than what IRC can feasibly do.
I have IRSSI always running in a remote screen session. I read many mailing lists. It's not just my personal preference, it's part of my workflow. When I hit a problem, my immediate reaction after consulting the docs or google is to ask a question on a relevant IRC channel or hit up a mailing list. I don't think I'm the only one that works like this, either.
So asking me to use hipsterchat or slack or gitter or trello or whatever means another another client, and not one that's going to replace my other client, but in addition to it. That's not good. If it had some amazing features other than emoji and fluff, I'd be open to it. But they really don't. People get work done with IRC and a listserv, and that's all that matters.
Let's be honest, Trello and Slack have taken off because young developers aren't familiar with this system and are taking to a new one. And maybe in a few years they will become the norm and my argument will no longer be valid because my workflow will change.
But until that point comes, I agree wholeheartedly that it's a bad choice for FOSS communities, on top of the fact that these are paid services and you're locked out of control of your communications if they decide it's better for their bottom line. That alone seems antithetical to the idea of free software.
http://royal.pingdom.com/2012/04/24/irc-is-dead-long-live-ir...
The worst that can happen to IRC is something like Usenet's death - growing too popular to scale. But scaling isn't of primary importance because a network hosting 100,000 channels is only mildly more convenient than 100 networks hosting 1,000 channels each. Nobody wants a chat stream that looks like a popular Twitch channel, because there is no longer any signal when that happens, so big channels are outliers. (And Twitch chat is IRC-based itself - demonstrating how much this technology is a commodity.)
IRC isn't going to stagnate completely until people decide to give up on text-based chat. The main thing it has trouble with is new client features like inline images.
When most people will do all their chatting in Facebook or Slack, OSS developers will still use IRC.
So run a private IRC server? This is a weird caveat, like complaining that angelfire is an insufficient web platform and you have to run your own http server to do well. There are a billion IRC clients, libraries, and bots out there. There are IRC servers in most distros. There are JS servers in NPM. Why not use them?
https://blogs.dropbox.com/tech/2015/09/open-sourcing-zulip-a...
source? or at least names of networks/IRCds?
freenode at least has 19 channels with more than 1000 users currently, and one with just barely more than 2000.
now, the volume of chat may be too much to read for some people, but that's not an issue with the protocol.The problem is that all traffic has to be carried to all nodes brokering connections for a channel. When you have a LOT of traffic this gets onerous.
You CAN scale these channels. But it requires some experience and most people never even consider that there might need to be action taken. The Freenode admins know what they're doing, and I respect them enormously for keeping freenode as responsive as it is on what amounts of a 25 year old, bad implementation of a distributed algorithm.
No one's arguing against using it for your company. Ok, the article is for some reason, but that doesn't invalidate the main point.
Given A and B, if A were good enough, people would use A... What if B is better? What if both are good enough?
You go on as if your first sentence stands up on it's own. It makes no sense at all.
Prior to Slack existing, lots of people who now use Slack weren't using IRC, because Slack offers a lot more.
Everyone I know working in academia or on a startup that uses any kind of instant chat uses Slack. None of them previously used IRC for the same purpose.
And it's just _obvious_ why, once you've used Slack for a while. They're quite different -- IRC is a protocol for real-time discussion on the internet. Slack is a business tool that incorporates real-time discussion.
Dead Comment
1. Slack is a well-designed interface for allowing teams to communicate via chat.
2. Slack is easy to install is use on Mac, PC, iOS, and Android. It Just Works™.
3. Slack doesn't require me to install IRC somewhere. Which also means I don't have to worry about how people gain connectivity to said server when outside the office.
4. Slack has whimsy. Fun colors, messaging, emoticon, bots, etc.
All of this is what folks in this thread seem to be missing. I've used IRC for a very long time, but have NEVER been successful at getting wide adoption of IRC for communication.
I am well aware that I'm trusting a third party with out information. I'm aware that alternatives exist and you can get them to work. That doesn't matter when I have to try to explain to my CEO how to /join #channel.
There is a reason why IRC, a widely-available, chat solution that has been available for decades didn't catch on. It has nothing to do with how well the software moves messages from one computer to another.
</rant>
I often find myself needing to establish a line of communication between people who aren't particularly tech-savvy. Slack works excellently for this: I make a new team, fire off some invites, and everyone just understands how it works. I can only imagine that, say, coordinating dev, corporate, and sales over IRC would be like living in the same circle of hell cardinally occupied by people who talk at the theater. If IRC works well for your team (whatever it is), excellent! Don't try to fix something that isn't broken. Slack isn't flawless, but it does have its usecases, and it fills them very nicely.
subjective. I consider a bloated web interface taking several tens to hundreds of megabytes of RAM compared to a text-based interface taking less than 100 kB to be poorly designed.
> 2. Slack is easy to install is use on Mac, PC, iOS, and Android. It Just Works™.
spelled wrong, and IRC clients are harder to configure only because there are so many options for servers, whereas Slack only supports one server.
> 3. Slack doesn't require me to install IRC somewhere. Which also means I don't have to worry about how people gain connectivity to said server when outside the office.
webchat was invented for a reason
> 4. Slack has whimsy. Fun colors, messaging, emoticon, bots, etc.
IRC has had mIRC-style colors supported and even adjustable by the majority of clients for at least 10 years. I don't know what "messaging" means. If you mean "private messaging", pretty much every chat software in the world has that. AOL and ICQ have that. You can put emoticons in your text manually if you want. It was on IRC that the concept of chat bots was invented, not on Slack.
> There is a reason why IRC, a widely-available, chat solution that has been available for decades didn't catch on. It has nothing to do with how well the software moves messages from one computer to another.
Yes, it is about how much money a for-profit company has to spend on marketing and copy as opposed to a standards organization.
Your comparison of what amounts to ASCII art versus Slack's rich-media embedding reads like it is straight out of a Fortran developer's "I'm still relevant" handbook. You even offer up AOL and ICQ as counter examples!
If we're going there, I guess we should simply assign everyone a GUID and be done with it, right?
HMU on ICQ: 110339943
Slack has its fair share of flaws but design and ease of use are not among them.
We have learned absolutely nothing. Let's all jump on the bandwagon of another closed-source, proprietary, walled-garden service and hand over all of our private intra-company communications to a private third-party in another country. GREAT IDEA.
https://plus.google.com/u/0/+JeromeLeclanche/posts/icC6gDToB...
The reason Slack exists and can be so successful yet entirely proprietary is a symptom that IRC is not good enough and that has to be fixed. It is the manifestation of the papercuts we, IRC users, have been having for a long time now. (late edit: If you are interested in fixing this problem, email me, see my profile.)
There are very promising efforts on IRCv3 (http://ircv3.net/) ongoing. I hope they eventually go live to the bigger clients and networks so that we may actually have a good foss alternative to slack (and I don't mean something like Mattermost. Like SirCmpwn said some comments below, having one browser tab per project REALLY SUCKS when you contribute to a lot of projects. I'm in over 20 channels myself, and I do my best to keep that number low...).
A lot of the other deficiencies are a consequence of any decentralized, open resource, due to "tragedy of the commons" effects. Those will always require active admin participation to resolve.
If you're running your own irc server, you'll probably never notice anything. If you do, it's as simple as adding a server password (or maybe even changing the default port among some other settings), and anything unwanted will likely be a thing of the past (assuming you don't have dedicated people attacking you).
On your comment about IRC bots and services, networks don't see that as something that is up to them. If something requires a U:line or other network privileges, then it's up to the network staff to implement that, sure, but anything else is for their users to do. If IRC networks were for-profit, maybe you could expect them to have things like this and advertise how amazing all of their features are to potential clients. But IRC is nothing but a money sink for everyone involved, and there's therefore often little incentive for networks to implement and integrate a lot of bots and functionality that aren't integral to network operation.
Apart from this, spam is a really hard problem if there are resourceful people dedicated to it. Email has existed for even longer than IRC, and despite absurd amounts of work into anti-spam systems and functionality with it, it's not too surprising when spam manages to finds its way into your mailbox.
I still agree there's a lot of room for improvement, both at the protocol level and at the user level, though.
Well said, I chuckled. Let me just add something...
If you want a paper trail of anything, use an email you own.
I have a friend who was locked out of a startup's Slack right before he was due to be paid for three months of work. He had been discussing business inside of Slack, and instantly lost access to all of those messages.
Could this have happened if the startup used a private email server, or a private IRC server? Of course. But if they were using more open protocols, he would have at least been able to back up the messages. Slack provides an easy tool for backups to admins, but not for normal team members. Slack provides an API for all users, but team admins can disable the API. Slack also allows team members to connect over IRC and XMPP, if team admins turn on that feature (https://slack.zendesk.com/hc/en-us/articles/201727913-Connec...).
Slack is great, I love using it. Just remember who owns the data. Always use your own personal email if you want to create a papertrail, as my friend found out.
I think your argument is somewhat null....
So don't use AWS or Google App Engine or Heroku? etc. Why?
I use Facebook for a lot of my communications. Seems to be working out OK so far.
Use the tools that help you get your work done efficiently. Consider the long-term consequences, of course, but if someone took all of my Slack team messages and told me I couldn't have them back, I'd be annoyed but it wouldn't affect my productivity much.
OTOH, losing the ability to coordinate via Slack, as you're suggesting, would certainly lower my productivity.
Leaving aside that there are extremely valid reasons not to use those services, communication is a huge deal. Can you imagine if email was a walled garden?
http://www.tricksofthetrades.net/2015/09/10/slack-irssi-conn...
I feel like that has to diminish the walled-garden, proprietary weight at least a little bit if slack & irssi can communicate. And it works over SSL too. Once I started doing that, I didn't mind using slack. You have to "/ignore" certain server messages though or your whole screen will be spammed with them and you'll barely see the stuff people are saying.
Amen to that. Our company yet to transition away from using Salesforce, but we greatly restrict its use for the reasons above, and one day will move completely away from it.
For everything else, including at work, I/we use privately hosted solutions like GitLab, where we control our own data.
If you have a single person that is even slightly technical, it should be trivial to set up your own IRC server, and then you get complete control over all of your own information.
Even with that, you still can choose from a multitude of servers, services, clients, bots, client scripts, bouncers, and so on. Anything common you want to add on after that point has likely already been written for what your purposes (and is of course open-source), whether it's a git commit bot, a logging/relay bot, or even end-to-end encryption (even after TLS). It's even quick to write custom IRC bots for arbitrary purposes if you use a framework or copy some example code (even without that, it is only so bad).
That's a pretty narrow view of 'slightly technical'.
These days, we've got generations of people who can manage their own email account setup, install web apps and mysql databases, configure zapier to connect multiple apps together within a few minutes. I know dozens of people who do things like this all day long for their clients.
I'd call all these people more than "slightly technical", but there's no way on earth they'd be qualified to set up and administer an IRC server.
You need far more than "slightly technical". "Slightly technical" sets you up for disaster. And... it's not 'trivial' to understand what's going on and how to manage it.
I agree, though, it should be trivial. It's just not.
The article does not even discuss the fact that projects that opened a slack community with a big increase in their audience. Apparently audience is much less important than purity.
I'm "slightly" technical and I have absolutely no interest in setting up an IRC server for my project or company. That's time better spent on developing our offerings. While I have no doubt I could set up a server, I also have no doubt that setting it up and maintaining it would drain time unnecessarily.
It's the same reason that I don't advocate for most people to maintain their own servers in 2015.
Deleted Comment
I really don't get this, 99% of the stuff you use everyday is closed-source and proprietary. Most often the tradeoff in something bad happening (which has yet to be with Slack) versus having a functional and productive system is more than worth it.
Or do you also build your own computer from raw silicon and communicate with pirated radio signals?
This is Hacker News; I expect the average to be around 20%
If some basic programming chat about an open source project isn't safe then we should all throw away our phones and turn off the internet immediately, but I don't see that happening. This is basically bikeshedding on how to run open source projects.
* Rocket.Chat (https://rocket.chat/)
* Zulip (https://zulip.org/)
* Mattermost (http://www.mattermost.org/)
* Let's Chat (http://sdelements.github.io/lets-chat/)
Oh, and by the way, you could have your own Rocket.Chat instance running in Sandstorm in about 30 seconds: https://sandstorm.io/apps
Update. And I would love to see a modern federated chat protocol to take off. Something like http://matrix.org/.
I don't get the point of complaining about Slack. It works great, it's simple to use and it has an amazing feature set. IRC is pretty terrible. Try doing a drag and drop file transfer. Try using markdown. Try displaying images inline.
I don't get what the problem is with closed source Slack. Do we avoid the phone company because their software is closed source? There comes a point where this FOSS obsession sort of jumps the shark. Worrying about a 'walled garden' for a chat tool is kind of silly. If it bothers people so much, create a FOSS Slack with the ease of use and setup and maybe people would be more interested. But anything that requires me to 'self host' something that amounts to a service means that is a bad use of time. I can pay the Slack guys to maintain chat while my devs work on maintaining our products. IRC is terrible. Try and get someone from your marketing department to use IRC. The neck beard and almost hipster pontification about the 'bloat' of Slack is kind of ridiculous. We have better things to worry about. Slack works on all my devices perfectly. I have a searchable log of everything. I don't have to think or worry about anything. It's simple and works. Until there's a viable alternative that exceeds Slack's ease of use, that's what I recommend people use.
I didn't mention IRC in my comment :)
It's interesting how you compare Slack with a phone company. There are important differences between Slack and a phone company. 1. If you give me your phone number I could be talking with you in a few seconds without me even knowing the name of our phone company. 2. You could decide to change your phone service provider and (in some countries) even keep your number.
How would you do these things with Slack? Slack is great, and I like it, but it could stop being great at some point in the future.
(Yes, I realize that Rocket.Chat user couldn't chat with Zulip user, for example. That's why I'm excited about efforts like https://matrix.org/.)
I agree with you: it's expensive to self-host. [1] But when it is possible to self-host, you could hire a specialized company to host the chat system for you. And - if you are careful - you can later switch your chat-system-hosting provider if you want.
[1]: That's what https://sandstorm.io is trying to fix, by the way.
That's an interesting parallel. I suppose it would technically be possible for a company to out-source their internal phone system to an external third-party using VOIP. But I've never seen it done and I don't know how I would persuade a CTO that it's a good idea to make internal communication reliant on the Internet.
Yet companies are falling over themselves to out-source internal IM... why?
Because you work in an industry were security matters. Such as banking, healthcare, government, government contracting, or any business with more than a couple hundred folks.
Because you provide support and want to customize / integrate that with rest of your data/systems to provide superior service to customers.
Don't know others yet, thanks for the list.
XMPP?
As for XMPP, I think it is still entirely viable as an alternative to using a brand new protocol and brand new clients and servers. But if you want solid off-line messaging, server-side logging and scalable group chat -- there aren't any out-of-the box combination of free/open servers and clients that will work, as far as I've been able to figure out. I assume one would want a solid command line client, solid gui clients for Windows, OSX, Linux/BSD, Android, iOS and Windows phone, along with a good web client.
I don't think you can pick-and-choose a XMPP server and clients that will provide all that, today. It is certainly possible to make that, standing on the shoulders of various open projects -- but the effort would be anything but trivial. I'd be happy to be proved wrong, though!
However, I am 25 and largely missed the boat on irc. I decided to start using it ~1 year ago. It is hard to use, but we will look at that in a minute. Often, we assume people have as clear an idea of what we are talking about as we do. That is often not the case. Let's explore IRC now.
* Integration has never been a problem ... build bots.
I feel silly and naive, should I know how to set this up? Maybe it is really easy and well documented, and I am an edge case here, but i don't know how to do this. I clicked 3 buttons to setup github for slack. It was very easy and I didn't haystack through building a solution to something that exists. Scope creep on tooling is dangerous as an aside. Thos takes that off the table.
* persistence
again, I have to set up an alternate tool to download the content. i assume this would backup the whole channel so any user could reference it, but it comes by default for free with slack. if each user must have a seperate tool, or go to a seperate place to see a conversation (which may be less searchable) it adds friction.
* code snippets
actually super reasonable to use pastebin. slack is at least as annoying for code as pastebin, if not more.
* etc
The point is, not everyone lnows as much as the author about IRC who is likely quite a talented developer who grew up on it. An 18 year old likely won't have used irc as much as older generations given the plethora of tools and chat clients.
FOSS is a choice and a philosophy and that should be given some degree of consideration. Utility, workflow and getting new devs onboard and contributing is important. I agree with the author that it bears consideration, but slack or hipchat are much easier than IRC.
(I'm one of the Zulip maintainers; happy to answer any questions about it).
Less importantly: What would you say its biggest missing feature is vs Slack? And conversely what does it bring to the table that Slack can't touch yet?
Are there any plans to support multiple teams / multiple servers from the native client? This is a particularly acute pain point on mobile; I'm reluctant to promote any tool that requires me to be logged in to only one project's instance of the tool at a time, because if it works well, it gets adopted for other projects, and then I'm having to juggle clients. I am unfortunately on two projects that use HipChat, and even there it's a huge pain that I can't be logged in to both simultaneously on my phone. (Some of their desktop apps finally support multiteam which is a huge help, but I still have to pick just one to participate in on mobile..)
Slack isn't perfect, but at least all the native clients will let me be logged in to 5 teams at the same time. (And no, opening multiple browser tabs is not an appropriate solution - it doesn't work at all on iOS, for example.) And obviously, this is something IRC does a great job of as well.
First, let me say that I'm really happy zulip was opened up, and grateful for you and your team to support it.
But does Zulip support server federation? Obviously slack doesn't allow self-host, so if slack is the alternative, that doesn't really make much of a difference. But that is one feature that http://matrix.org/ does support.
It's incredibly intuitive because it's so similar to all the other chat clients we grew up with (presumably because they're based on IRC).
Sure, figuring out bouncers and build bots is a little tricky at first, but so what? That's the fun part. It's kinda fun digging into the IRC protocol and figuring out how it works.
And ok, if that's not fun for you, there are plenty of really "click and install" tools for you (e.g. ZNC is super easy to setup).
Not to sound like an elitist prick, but if you can't figure out how to setup an IRC bouncer, I'm not sure I really trust you contributing to the linux kernel, yaknow?
Reducing friction is great: But the kind of friction we should be trying to reduce is bureaucratic friction. Throwing out PRs and yelling at people because they forgot to cc some particular maintainer - that's the kind of friction that sucks. Having to setup an IRC bouncer? Idk, I think that's fine.
And just because someone doesn't want to spend the time fiddling with IRC bouncers, IRC bots, getting clients to display things nicely doesn't mean that they are a bad developer. Just that they have different priorities for their time than you.
I'm not saying that Slack is perfect or frictionless, but neither is IRC. And especially if you don't do it all the time, getting people set up to work with Slack is way easier than IRC.
I really find these discussions half amusing and half depressing. 2 sides have something that is "good enough", both insist that nearly all you want can be solved with their solution, especially if you just do X1,X2,X3,Y1,Y5, and Z4 and you technically could build something that is perfect for both on top: but sadly (and understandably) no-one actually cares enough to do so. Because what they have is "good enough"(TM).
Some great tools for software development:
* Microsoft * OS X * Linux * Free BSD
To some degree that represents a spectrum and I don't fault the author for having strong beliefs about how software should be built, and agree with them for the most part. I think he could have made a stronger point generally from a philosophical and technical angle, i.e the regular arguments for open source tools, and highlight Slack as an example.
IRC is quite similar to Slack, but for the reasons the author suggests, it is different.
tl;dr Stallman wouldn't use Slack.
Maybe Freenode could implement an enhanced IRC protocol and clients could opt-in to that.
I know at least one project that was very active on IRC, and they moved to HipChat for convenience. They also went full-on with the entire Atlassian stack (again, the fact anyone would choose JIRA is damning against everything else.)
Frankly, it boils down to that I just don't like it. I'm more interested in getting better at programming, or learning about containers, or some other useful thing, than trying to figure out IRC's odd interface. Chat isn't something I should have to think about. It should just work.
So, I agree with most of what @vonklaus said, and disagree with the links pro-irc stance.
I've never used Slack, so I have no opinion on it.
(It probably helps that a lot of in-game chat interfaces use a lot of these same commands, as I'm a gamer as well as a programmer.)
There's a pretty nice web interface to IRC called irccloud.com which also persists your connection (so you can simply log onto irccloud.com somewhere else, and entire history is preserved).
Instead of using slack, use IRC Cloud.
Have you ever noticed just how many open source projects are still using shitty software from the 90s? No doubt, some of that software is actually quite good but I will argue most of it exists primarily as a result of tradition. In other words: a lot of it isn't the best way to do things presently, and perhaps if we stopped using such mediums as: mailing lists, newsgroups, and IRC channels to run our open source projects then presumably our projects might be filled with more diverse people than dinosaurs that still roam our mailing lists.
I don't know why developers do this: but they assume because they have the skill to do just about anything with technology that other people who also have the skill ought to take the same time to do as they have. But honestly: even developer time is too valuable to waste on pointless shit. We ought to be trying to make things easier to use.
If you don't want to use Slack for open source projects because Slack is in fact pretty bad at those workloads, fine. I agree! I think Slack does a pretty bad job at any group application where most of the people communicating don't already know each other.
Where you go off the rails is in suggesting that IRC is competitive with Slack. IRC is awful. It's a medium dominated by 7-bit clients with tiny message limits that provides virtually no useful metadata and no works-by-default history or search --- both things that virtually every open source IRC support channel b a d l y needs.
IRC does exactly one thing better than Slack: it's easier to join a new IRC channel than it is to join a new Slack project. The rest of IRC's "features" are red herrings, many of them more harmful than helpful.
Surely by now someone has built a Slack-like, perhaps with decent IRC support, that big open source projects can champion as a Slack- and IRC alternative.
It will be much easier to keep open source projects from trying to fit their square pegs into Slack's round aperture when people give up on promoting IRC.
The free version of Slack only has a 10k message limit, which runs out very fast with a user count in the 3-figures range. So if you want history, you need to shell out $8/user/mo, which is ridiculously expensive for chat. And not something a FOSS project should be spending it's limited funds on.
Slack has been successful because it's onboarding process is buttery-smooth. They've put a lot of work into making everything easy, from signing up to installing integrations. Unfortunately those integrations also waste a ton of space in the chat window. I use Slack at a couple of companies, and each of them got excited, installed a couple of integrations... and then abandoned the channels with integrations, because they waste so much screen space and you can't follow the flow of a conversation. It's a pity Hipchat got caught napping - they did displaying integrations well.
Another FOSS-specific problem with Slack is that they don't have a linux client, so you have to use the web app, which is terrible when you have to track more than one Slack team - you have to manually switch teams to check for updates, which takes a non-trivial amount of time (and the 'switch' control is right next to the 'sign out' control, which I've accidentally hit a couple of times)
I mean... Hacker News is pretty "awful."
Maybe the things that you claim make IRC "awful" actually have weird benefits in terms of community. Kind of like how HN is kept intentionally awful, to keep out the losers or whatever.
I don't use IRC anymore, I use Slack but only because it's convenient. IRC is all over the place like the majority open source projects. Slack is clearly inspired by IRC, but it's in a pretty package and works OOB. Not sure why people are shitting on Slack or IRC here.
Yeah, that's not nearly the same. What I love about HipChat (and I'm sure Slack is the same, but I don't know) is that you can connect from any device and see the room history when you join a room. Going to some website to scroll back to see what people were talking about before you joined is annoying, especially so on a phone.
I'm don't want to waste time doing that, I've got products to build and maintain.
The closed source option is better because they have a financial incentive to keep it that way. And I'm happy to pay for that because it saves me time and lets me work on things for my customers instead of myself.
I'm a huge fan of open source and used to be a zealot about using open source to run my business. But I've started to see the light in my old age.
If you look at open and closed source across a lot of categories, I think it's more common to see OS "win" where the product is more objective. When it come to more subjective problems like UX, it seems to be more difficult.
If your goal is something fairly objective OS is really amazing. Take VLC's "play everything everywhere" goal. Fantastic, objective goal for and OS project that really plays to its strengths.
Linux is, I guess, the canonical example. It's fantastically successful relative to closed source competitors on every front that is objective. But, its consistently been unsuccessful as a consumer desktop.
That said, I don't think IRC is dead either. Some people/communities prefer IRC.
Linux is a canonical example: it's simply a clone, design wise, of a plain old UNIX. The product vision was "copy UNIX". Where the wheels fell off Linux is the moment it got ahead of the UNIX legacy (i.e. modern desktops) and started having to compete with Windows, so suddenly the "copy UNIX" goal was no longer relevant. But Windows was made by Microsoft, or "the great satan" as Stallman memory called it.
So simply switching the goal to "copy Windows" wasn't possible because Windows and UNIX were very different and anyway, lots of people hated Windows. Linux had picked up a lot of semi-technical and technical users who didn't care much about FOSS purity but loved the club feeling that using an obscure OS brought them. The end result was big splits and bizarre, illogical design decisions being made simply because "do it like Windows did" was ideologically unthinkable, even when Windows had basically got it right (or at least, less wrong).
Agreed. I think one of the main reasons for this is that cohesive design comes from dictatorships, not from distributed decision-making, i.e. design by committee.
The strength of open source is that it is usually "good enough", rather than "great" or "the best it can be".