Hacker News Reader

Comment by KirinDave | Hacker News Reader

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.

View on HN

> 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 don't think you're going to find evidence for the argument that IRC is more popular than Slack. IRC's user base is declining, Slack's is growing, and the numbers we have now suggest that Slack is already much more popular.

But back before the WWW saw non-trivial deployment, IRC was the #1 use of bandwidth on the internet! Something from the 90's must still be true today!

I was surprised when I read this comment. Do you have any evidence for this? If I had to pick some protocols off the top of my head I would have thought nntp, smtp, ftp, but certainly not irc.

I assume that he'd be talking about the IRC DCC sub-protocol.

CTCP and then SEND bots?

Slack has 1.1 million users _total_ (http://www.fastcompany.com/3047819/with-over-1-million-users...), meanwhile Twitch uses IRC, and has ~3.3 million per day alone (http://blogs.wsj.com/digits/2015/01/29/twitchs-viewers-reach...), using stats taken eleven months ago while more than doubling its monthly viewer numbers every year.

Freenode isn't the only network out there =)

Being powered by IRC is not the same as using it, in the sense meant here.

What do you mean? Every viewer also connects to their IRC chat, hence "using" it. Heck, I personally connect to it using my IRC client.

The discussion is about users who use IRC directly and consciously. Many of Twitch's users have no clue what IRC is. Imagine a new social app that used SMTP in its implementation. You wouldn't bring it up in a discussion about the popularity of email.

No one denies IRC's continued popularity as a protocol for broadcasting text over a network. Slack itself uses it. But it's dying out as measured by the number of people who say to their colleagues e.g. "get on IRC, I have something to tell you."

> The discussion is about users who use IRC directly and consciously.

From the parent post I replied to, "IRC's user base is declining". Every single person watching a Twitch stream is an IRC user, whether they know it or not.

How do you determine the popularity of something? How many people use it.

Android is extremely popular. Do most of the folks realize they're using an Android phone? Nope.

Does it mean Android isn't popular? Nope.

If you don't have a similar understanding, we'll have to agree to disagree.

> The point is more that it's dying out as measured by people who say to their colleagues e.g. "jump on IRC, I've got something to tell you."

Of course they wouldn't, you're already speaking with them. Slack is fine for trusted networks of peers (businesses), but not much else. I won't start chatting with any my friends using it, nor would I bother to sign up somewhere to get access to a random Slack channel/community instead of using IRC, where I also coincidentally wouldn't need any of Slack's features.

Of course they're all IRC users inadvertently. That doesn't add to IRC's popularity. If Twitch disabled IRC and switched its chatrooms to some ghetto socket.io app, most of its users wouldn't know.

> Of course they wouldn't, you're already speaking with them. Slack is fine for trusted networks of peers (businesses), but not much else. I won't start chatting with any my friends using it, nor would I bother to sign up somewhere to get access to a random Slack channel/community instead of using IRC, where I also coincidentally wouldn't need any of Slack's features.

No, what I meant was, people no longer think of IRC as the tool to use to talk about projects and communities. They used to. That was its primary use case. That use case is shrinking, so IRC is becoming less popular.

> How do you determine the popularity of something? How many people use it. Android is extremely popular. Do most of the folks realize they're using an Android phone? Nope.

This isn't quite true, is it? Most Android users seem to know they're using Android. I could be wrong.

Again, your definition of popularity is different than mine, but either way my post still refutes his point about the declining userbase.

> No, what I meant was, people no longer think of IRC as the tool to use to talk about projects and communities. They used to. That was its primary use case. That use case is shrinking, so IRC is becoming less popular.

There's plenty of other avenues to use these days, so the numbers have diluted, absolutely. EDIT: There was no social media, very few IM clients... But the channels I'm in have been steadily rising (Freenode). http://tctechcrunch2011.files.wordpress.com/2013/01/irc-002....

Quakenet took a huge drop once it stopped being used to find CS matches.

> This isn't quite true, is it? Most Android users seem to know they're using Android. I could be wrong.

Obviously this is going to be anecdotal, but with the ~20 people I know who aren't technologically savvy, they'd only be able to tell you if they're using an Apple phone or not. My mother, for instance, has no clue that she's using a Windows phone. EDIT: I guess that really goes to show something about the success of Apple's marketing.

> Obviously this is going to be anecdotal, but with the ~20 people I know who aren't technologically savvy, they'd only be able to tell you if they're using an Apple phone or not. My mother, for instance, has no clue that she's using a Windows phone.

I think this has quite a bit to do with what class of phone they buy. Android is marketed very heavily in certain contexts when buying a phone, just as iPhone is. Walk into Best Buy and ask for help on buying a smartphone that isn't basic and Android or iPhone (or Windows phone even) will be part of the pitch. Similar to how if you buy a sports car you are probably going to know something about the engine, if not when going into it, you probably will by the time the salesman is done. If you are buying a commuter car, they may or may not distinguish the engine, and you may or may not care enough to remember.

Agreed, although I believe the end goal of my comment was that after leaving the store, the term "Android" is completely forgotten, whereas "Apple" is almost a household term because you see them everywhere in pop culture—movies, the news, in schools, etc.

Try "IRC's mindshare is declining". rather than "IRC's popularity is declining".

Agreed, that would have been a far better term if that was the meaning he was attempting to portray.

>> Of course they're all IRC users inadvertently. That doesn't add to IRC's popularity. If Twitch disabled IRC and switched its chatrooms to some ghetto socket.io app, most of its users wouldn't know.

Saying if Twitch disabled IRC is like saying if Slack changed to an IRC core..., which is not meaningful when discussing how many users Slack and IRC have. Twitch has several millions of users of influence. If they didn't use IRC, IRC would have millions fewer users, yet, Twitch chose IRC. Some of Twitch is IRC, and some of IRC is now Twitch, and millions of people use Twitch consciously. Twitch is the IRC client.

If a proprietary IRC network that is managed as basically an API layer for a service that isn't primarily about chat is the primary tentpole for a platform...

That doesn't seem like a really fantastic outcome for IRC. I guess if you're looking to come up with a conclusion that IRC has more users it is a useful tool. If you're looking to see what the future of distributed and local FOSS and corporate software team communication is? Less so.

Android is built on top of Linux, is it reasonable to say that the popularity of Android phones mean that Linux is popular?

I don't know if it is reasonable, but that's what is always said. The primary argument for Linux popularity is always "Android!".

Also, in this context I think it's pretty relevant. My personal opinion is that if Slack was just an IRC client instead of having its own propertiary backend, it would have been a better product.

Of course! And by digging deeper, we can also establish that cellphones are popular, and that electronics are also popular. It's going the other way (away from generality) which lessens popularity, since you're targeting something _more_ specific.

I think that's the problem with IRC. The idea of decentralized IRC networks means that channels are scattered amongst multiple IRC networks. IRC is already not as usable as Slack, and to have multiple networks decreases usability even further. I love IRC, but I see why Slack is full of win.

But decentralized is the best thing ever!

I hate that argument. If decentralized was so great, then it'd be more popular, but it's not. More and more centralized stuff is exploding in popularity.

Centralized is generally easier to implement a given feature in, so it's easier to support more features.

It's also harder to base a business atop decentralized network, and when building a new network there is less of a business case in spending the extra time, stress and expertise to make it decentralized (vs. centralized).

Let's state explicitly why it's harder to base a business atop a decentralized network - because a business makes money by creating friction in the service, and in a decentralized model a friction too strong will be routed around.

Well, I think it depends on whether you are talking about decentralized networks, as I read the parent to your comment to mean, or decentralized ownership/administration of networks, as I read your comment to mean.

That is, the network can be decentralized but still administered by a single business entity, in which case you theoretically get a network more robust to outages, or the network can be composed of many separate entities, in which case you are theoretically protected from the bad behavior of any one administering entity, since there are many others (as in your example).

The other reason it may be harder to build a business atop a decentralized network is that the costs associated extra hardware, software, and locations and troubleshooting required to achieve the gains of a decentralized network may outweigh the gains achieved by doing so.

But that brings us back to mbillie and "if <x> were so great, everyone would already use/do <x>". Does popularity necessarily imply superiority? Adoption just means it's easy for anyone to get aboard. But that doesn't mean it's implicitly good, in any other way. Worse is better works, for example, if one option is more approachable than the other. Decentralization is good, as a rule of the thumb. Not having everyone on the same network, but having the ability to set up your own network or service based on the technology, is a good thing. Why would you want to have everyone on the same network? Networks are often topic-related. For example Freenode for programming-related topics. Minecraft is pretty focused on EsperNet. Quakenet used to be the place to online gaming. This is usefull and good, since communities sort themselves by interest, views, tools or what have you, by default. So why not encourage self-sustainability through means of decentralization?

Centralization is being driven by a lot of things, not least of which is that decentralization is really really hard. But a lot of it comes from mobile -- the idea behind decentralized apps before mobile came along was that bandwidth was not very dear -- oh, sure, it was limited in the days when IRC first became popular, but there was no reason to leave any of it unused. Local compute power was the same -- you may not have had a lot of it, but there was no reason to leave what you had sitting idle. Mobile is different. Idle CPU power can mean the CPU is throttled down to save on power and heat dissipation. Instead of staying connected to a server at all times, use "push" notifications so the server can let you know when it's worth using battery power and metered data to talk to the server.

Decentralized systems, and peer-to-peer systems, and even centralized systems designed around computers designed to sit next to a wall outlet and draw power from a practically unlimited source are all being replaced by systems that are more centralized and better equipped to talk to mobile. AOL Instant Messenger is dying because it was built around an older paradigm and, at least last time I bothered to try it, is an incredible battery drain on Android devices. Newer messenger apps that are built mobile first or at least make mobile an equal partner to PCs are winning instead. And it's the same for group chat -- IRC is built for old-fashioned PCs, Slack is built with mobile in mind.

It's also worth noting that it's not clear what decentralization brings to the table from the perspective any single organization. Most organizations will want a central authority for the history of their group communications.

Such facilities are bolted onto IRC, but never truly integrate with it the way other solutions have offered.

EFnet is a single entity in the exact same way that Slack is. All channels belong to only their service. Introducing yet another chat service only adds another place to the list. https://xkcd.com/927

It's also nice that I don't have to signup anywhere to use most IRC servers.

Don't get me wrong—Slack is the perfect tool for businesses, but not for much else.

The military uses IRC.

Yes they do. Check out ##security on Freenode. I also do some security stuff in ##GRC

Fair enough, and to my credit, I said I was guessing about the popularity of IRC vs Slack. And I wasn't defending IRC; I am a Slack user, and by choice. A quick search showed me that public IRC servers had ~503,000 daily active users last week, while Slack recently had over one million daily active users. I would further guess that the IRC users are more likely to have made that a choice versus the Slack users, who are more likely to have signed in to Slack because that's what their workplace uses, making IRC the more popular "choice" rather than the more popular "service", but that'd be more conjecture on my part, and in any case, my argument remains unchanged: popularity can in fact be a signal that something is better/easier for those that use a device or app or service. Examples to the contrary (BetaMax vs VHS, HD DVD vs Blu Ray, 8-track vs cassette) are interesting from an argumentative point of view (I really wanted HD DVD to win, FWIW), but that's just it: there will always be evidence to the contrary.

It doesn't make it a logical fallacy to say something is popular because it's superior for its audience.

> In many cases, things are popular because they are better/easier for a given audience.

Which is the horse and which is the cart? Slack is easy because it got resources to be easy. Those same resource could have invested time to make IRC just as easy.

There is no inherent reason why IRC cannot be just as simple.

The reason slack is popular is because it got pushed hard and lots of money went into making it easy and popular.

There is nothing inherent about IRC that would have prevented it to be just as easy as slack if the same resources were put for that work.

This is like saying Apple products are popular because Apple has a great marketing team, as opposed to because said products are genuinely easier to use (they "just work") than their alternatives.

Can't tell if this is sarcasm or not...

But that is why Apple is so popular. They are a marketing monster! They sell a "lifestyle" and they do it extremely well. They tell you to "Think Different" (as long as it means buying an apple product). They tell you one button is easy and the best. They tell people what to think and (some) people think that.

Yet they spend less on marketing then most major tech companies. One could just argue they spend their marketing budget well, but you have to wonder.

Less as a percentage of gross income, or less in total dollars?

Both. Apple is infamous for its anemic marketing budgets; e.g.

http://www.engadget.com/2013/11/04/apples-advertising-budget...

They spend just maintenance level. Tech press and media does the marketing for them.

Apple products got good because of large amount of investment, not because they were popular. If IRC tech got the investment slack has now, it would only get better.

It worked for Nike and De Beers.

The entire sports drink industry.

The supplement industry.

Sadly, a lot of people (generally die-hard nerd types) genuinely believe that marketing was the sole reason for the iPhone's meteoric rise in 2007. They don't place any importance on user experience and therefore can't tell the difference between the iPhone and the early-gen smartphone predecessors (Palm/Nokia/etc).

These are the same people that are now confused as to why Slack has risen in popularity despite the existence of IRC, which (in their eyes) is technically superior.

To be fair, (as a Slack user) I'm not sure off-hand what Slack has that couldn't have been done on top of IRC. Almost everything could have been done with an IRC Server + Backend Services + Fancy Client model.

Problem: "Backend services" - how many of the Slack integrations don't have public APIs and Slack was only able to do it by being a single company? Good luck convincing people to set up the API keys for all of those services.

Why can't Slack run irc servers on their own equipment? The "integrations" would just be IRC bots running on private Slack servers, no?

> (they "just work")

Please don't say that Apple products "just work". We've got an office full of them.

and I need to "put a USB keybord, take it out again" when suddenly my Mac keyboard and trackpad stop responding xD

I'd rather have "easier to debug when it doesn't work" than "just works, most of the times"

Yes, it's pretty much self-evident truth. "Genuinely easier to use", even if it was clear-cut thing, doesn't explain the levels of popularity Apple products have. Lifestyle branding does.

It reminds me of Raspberry Pi. There are lots of more powerful boards that you can buy cheaper, but people still mostly buy RPi because it is the brand.

Buying 'the brand' can also lead to much more documentation which can make the 10% change in price worth while.

It seems very unfair to the thousands of people who have donated time, money, and services to IRC over its life span to dismiss it as not having gotten value.

You misunderstood. I am saying IRC would be as easy as slack if the slack team spent the time working on IRC. Their investors would never let them even if they wanted to.

It is not an obscure fact that investing shitton of money in marketing will yield better adoption than investing the same money in the product. People "who have donated time, money, and services to IRC over its life span" generally focused on the technical side.

I'm thinking a huge part of the difference between Slack and IRC audiences has to do with the $340MM Slack has raised. If someone gave "IRC" a quarter of a billion dollars, the differences might not be so obvious.

Correct me if I'm wrong, but don't companies usually get a quarter billion dollars AFTER they have shown traction?

They got $17.5MM in the four years prior to even launching.

If you gave "IRC" a quarter of a billion dollars, we'd have the world's most complex ncurses UI, and a security ACL system whose complexity would rival X509. And normal people would still use Slack, because Slack was able to make simple design decisions that benefit the overwhelming majority of users but piss off Unix nerds like us.

don't be naive, IRC was the simplest solution to a problem 25~ years ago, now systems have changed and things must be thrown away.

that's just the nature of the beast, x.509 is also very old- but old things should be fixed or replaced with better alternatives, slack just fixes a usability problem.. but trades all privacy and freedom for that.

Personally it's not enough, but google has a massive market share because normal people do not consider that their data or freedom has any worth.

at least google is pro-free market in the way that you can extract data out later and migrate, I don't see slack being able to offer that reasonably. (or their incentive to allow it)

1. But isn't that sort of the point? IRC as an ecosystem has had years to get its act together. Like many corners of the tech ecosystem, perverse incentives have frozen IRC's progress. The very things that Slack, Hipchat and others have exploited are the things the old guard IRC users love. Opacity, terminal interfaces and a total lack of accountability are exactly what many IRC users find alluring.

2. Using cloud services in exchange for contributing to aggregate data seems like a pretty clear understanding of personal value.

Giving "IRC" a quarter of a billion dollars isn't a good idea. Giving it to a company making a single IRC client, on the other hand, would probably result in something like Slack, only much better.

I'm not sure how you conclude it would be better. I suspect you'd end up with something approaching Slack, only without interoperability with the rest of the IRC ecosystem.

The stuff IrcCloud, Slack and HipChat undo? That's the stuff that seems to be alluring to the steadfast IRC users. Inscrutable commands, nick and chanserv and unencrypted passwords sent via a command that could very easily be typo'd to broadcast in a channel, obscure partitioning behavior that is very much not what most businesses want, a lack of accountability or verifiability, a lack of robust logging and search...

I say these in a negative way, because that's my perspective. For many people they'd list many of these in positive ways like, "improved anonymity", "off the record by default", "network robustness", etc.

How do we even measure the value that had been donated to various irc technical efforts over the last 26 years? Millions if dollars in person-hours is probably not unfair to imagine.

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.

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?

In a free market with well-informed participants, argument from popularity is entirely legitimate.

only to a minor extent (in that what is most popular still does not necessarily correlate to what is actually best, only to what people favor). Also, network effects still happen in free markets.

Anyway, it's all hypothetical. We don't have a free market with all participants being well-informed.

It is a open market of tools out there... if IRC fulfilled the need and developed features that people really wanted they would be there.

Why does gchat, snapchat, whatsapp, fb messenger exist if AIM had been fulfilling the need of the market?

> Why does gchat, snapchat, whatsapp, fb messenger exist if AIM had been fulfilling the need of the market?

gchat & fb messenger are backed by huge companies trying to sew up the communications of a large community for the purposes of selling marketing services. The need they were created to fill is a corporate need, not a popular one.

Whatsapp was primarily popular because it made it cheap to text on your phone. I don't know the history of snapchat, never used it.

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...

> but you draw a much bleaker portrait of IRC

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.

No, the point was that your description was entirely inaccurate. It's not brutally real because I also use IRC extensively every day on freenode and have almost never encountered the issues you are referring to. I think I've seen one netsplit in the last 2 years.

Okay, well I am sorry your experience and mine differ. Fortunately you can continue to use your solution without regard to my criticism.

But I think if we asked your IRC network how ma you nets plots they experienced in the last 2 years the number would be >1.

Ah, yes, IRC has netsplits. Slack, on the other hand, has "reconnecting...", which I encounter a dozen times a day on it.

I guess it's down to personal preference whether you prefer being able to talk with a partial group knowing that some people are absent, and not being able to communicate at all.

Reconnecting in slack then shows you the missed messages. What's the common case for making sure participants have access to all past messages in IRC? An external log, which doesn't really solve the netsplit problem, because it necessarily is part of the split?

I would much prefer clear indication that there is a problem communicating with others so I can fall back to an alternative method of communication.

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.

Slack's benefits over IRC are largely not subjective:

* The ability to directly send files and images to channels is an objective benefit Slack has over IRC, which has even less ability to do that than MIME email (at least MIME lets you post the base64'd file contents of your image, rather than just a clickable link).

* The ability to send long messages or whole source files is an objective benefit Slack has over IRC.

* The ability to, by default and without running a secondary service that can crash or lose connectivity, log and search channels is an objective Benefit Slack has over IRC, which can support that feature only by using bots, and only by tunneling results through privmsgs or forcing users to leave the IRC protocol itself and visit ancillary web sites.

* The ability to edit and delete messages is an objective benefit Slack has over IRC.

There's probably a bunch more. Don't get me wrong: I don't think Slack is amazing; it's good for what it is, but in 2015 it's pretty unremarkable. The issue is that IRC is so. bad.

There are probably still people making fun of poseurs and hipsters who use IRC instead of ICB. The OpenBSD team used to be like that.

You've been able to directly send files over DCC via IRC clients since like 1995.

Interpreting and displaying those DCC'ed files or cutting longer messages into sub messages and recombining them is something that you could implement via the IRC client just as easily as it was implemented in Slack (not to say that it would be easy, it'd be a lot of work, but it likely would not be much more work than what took to make that function in slack).

If you're modifying IRC anyway, you can modify the server to record logs and make those available to clients.

Same goes for editing.

IRC is not as bad as you think it is, and it wouldn't be an insurmountable effort to make it as good as slack, but open sourced rather than proprietary, which was the entire point of the original article.

No. In Slack, files and images posted to channels are content associated with the channel, not a private and opaque stream of bytes tunneled over another protocol between two specific channel members. The comparison between Slack and DCC is silly.

Given the problem of sharing a diagram with a team of developers on a group message channel, I'm sure there's someone here who would say they prefer the DCC option of receiving a named file and then opening it with a file viewer, rather than simply dragging the file into the chat window and having it appear instantly to everyone on the channel. The existence of that person is not interesting to me.

icb4lyfe

yeah, can you script tcl into slack?

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.

> 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.

I completely disagree with you. My entire team is ~30 or older, and we all used IRC "back in the day". Slack is simply better for communicating with your team because of all the features mentioned elsewhere in this thread.

To suggest ignorance is the only reason Slack and HipChat have taken off is offensive to the people using it because they like it better.

I still use IRC for open source projects I use or contribute to. For the record, I agree with the article insofar as that OSS projects should probably continue to use IRC rather than Slack despite the persistence and team based features. Purely because it's unfair to expect all of your users and contributors to use yet another system for communication that isn't relatively open.

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.

http://royal.pingdom.com/2012/04/24/irc-is-dead-long-live-ir...

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.

Indeed, in the same time period I think Freenode actually grew.

Good point, usage for gaming has also died completely. Old networks like QuakeNet existed to allow gamers to co-ordinate match making. Now who needs that?.

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.

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.

>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.

Absolutely. My company uses it (among other things) for handling production issues.

We'd rather not manage that ourselves. It's just one more thing we can screw up.

This is different than the FOSS subject of the article, but it true that convenience is compelling.

If it's just infra management you want, then use Hipchat. It does the same things Slack does, at $2/user/mo instead of $8. Slack is ridiculously expensive.

It's only expensive compared to HipChat which is a subsidised gateway service that leads to Jira. Our company used HipChat for about a year before moving to Slack. Honestly, the differences are not many and any reasonable team could choose either.

I think we migrated to Slack for connectivity reasons, fonts and general user interface, and the bigger list of integrations. Are these worth $6 per user per month? If you've got the money then maybe. But it's by no means a given.

And that's what I meant by "among other things".

Originally, we were using Campfire.

As needs grew beyond just putting out fires, we looked at Hipchat, Flowdock, and Slack. We probably would have gone with Hipchat (because of the price), if they had SSO, or better JIRA integration. Slack had both.

I highly doubt that slack has more features than IRC, which has thirty years of history in dozens of code bases. I agree that taking a canned solution is easier, and easier is often best. But I think this is the main reason slack is popular; its less to think about. There are many dimensions in which it will be worse.

So use grove.io

My company runs our own private IRC server on an EC2 instance and once it was set up I don't believe we've needed to touch it since.

How very lucky of you.

I hope you have a repeatable provision, AMI, static IP linked to a tcp loadbalancer and autoscaling group in the event AWS rotates out your instance.

And of course, the same goes for your logging and search and file sharing infrastructure. And of course, similar caveats exist for the database said features use.

how very sarcastic of you.

This is the realm of systems administrators, if you can't read a 20 line config file then sure, run slack..

but for a biggish company that values security and publishes NDA's like mine, an IRC server is a better solution.

however, Project Managers fucking -love- emoji and sending word documents across the planet.

How very decisive of you.

And you'd take on the burden of constellation of comparable services as opposed to a white label hipchat because....?

If your file sharing infrastructure is limited to what Slack provides, then your file sharing infrastructure sucks. Slack is good for quick "check this outs", but it's not a file sharing system.

Well, you add the google docs integration, or the dropbox integration, or the box integration, or use the Zapier integration to tie things together.

Slack isn't a file sharing platform, it's a communication platform. As such, they try to make communicating about, discovery and grouping of files in dedicated file sharing platforms easier.

That's a terrible solution for anyone handling data that has to remain on-prem, which is the case for a lot of large corporations that deal with financial data, personal id data, etc.

Of course it's a bad solution in that case. You've picked a case where a specific business requirement precludes using an external service. In which case, why would you use slack anyway, since it would then necessitate a chunk of your communication be external as well?

Your company puts private information on a server that has a 6667/tcp sitting out on the Internet?

I'm guessing it does not, and setting this server up was considerably more irritating than just spawning off another t1.micro and apt installing IRC onto it.

So put in an iptables rule that restricts it to their network and make people remote in to use their client. Done and done.

iptables rules are not magic security talismans.

True, but for this case it's more than adequate. An attacker would need to be able to tunnel through your companies network, and then what? Assuming they're that far, who cares if they can read what you talk about on IRC?

And even then, they'd further need to exploit some vulnerability in your IRC server to do it unnoticed.

Oh yes they are you just need to add the --rabbit-foot switch.

In AWS t1.micros don't really exist anymore (they do, but you have to use oooolldd images), and except for legacy accounts, a default install puts you into a VPC where the instances are never going to have 6667 open to the internet unless you specifically open it (well, that's more of a Security Group thing) and possibly don't even have a public IP address. :)

We have all our instances in a VPC so nothing is available without a VPN. (Openvpn, on phone, laptop, built into the wifi router for everyone else). Once any service for our firm onlt is set up it is effectively private it we manage our keys. Private IRC is a one line apt get on a server. Close to zero cost from there.

Explain why that's any worse than putting private information on a server on with port 80 open. Go!

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!

I, for one, think that reinventing the wheel is a totally great idea and that we should have more npms and less apts

I, for one, think that the march of technological experimentation and progress should stop unless we can convince specifically jarek of the value of any given project, as jarek has demonstrated that they want to become the arbiters of all value judgments.

Yes. My first verdict: outlawing files and having VC land come up with a replacement product with better UX. Then HTTP.

The ICB people thought the same thing about IRC.

The HTTP people thought the same thing about AOL.

No, they didn't.

This is more truthy than actually true.

Since we're talking about FLOSS here, why HipChat? Might as well go with Zulip which Dropbox just open-sourced.

https://blogs.dropbox.com/tech/2015/09/open-sourcing-zulip-a...

> 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.

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.

Not to snark, but my Linux systems also have a configurable message of the day that gets displayed when you SSH in or log in on the console. :)

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.

EsperNet server administrator here. You did not 'nearly break EsperNet' with EiraIRC usage. Our capacity vastly exceeds our load (we could likely run the entire network from a single one of our servers). However, the time our administrative team has to spend differentiating abusive bots from non-abusive ones is finite, which is why we place so many restrictions upon bots.

I do not doubt you.

But that's not what we were told. Another admin from espernet basically had us kill the project because they said the way Eirc was using the system constituted a "significant load" and "would not scale well". We were growing really fast and proxying maybe 3-10 users per bot connection on average. I think your team came to us with the problem right as we were really exploding with users.

We basically massively scaled back that deployment of a really cool and interesting feature. Because we didn't want to be an undue burden on our gracious hosts. Now you tell me that this was just some admin giving us an exaggeration?

That's a very frustrating detail to learn. Probably not your fault, but thanks for the clarification I guess.

There are many issues that prevent us from easily serving your use-case, unfortunately. I'm not completely sure about the details around this specific case, but historically we've had to restrict connections from similar software that makes N:N connections (or even N:M connections) to our network due to our connection limit rules quickly becoming unmanageable. We've recently implemented new software that should make this a little bit easier for us (and we've accordingly started being a bit more lax about it), but this is a fairly recent development.

Additionally, we hesitate to cater to this use-case as it often ends up turning into "we want your network to relay messages between our bots" instead of "we want to talk to other people". We've found that channels used for such bots are typically not sufficiently staffed and frequently a target of abuse, which ends up taking network staff time to resolve.

Lastly, we've had a number of technical issues supporting certain pieces of IRC client software. Older versions of EiraIRC in particular have some nasty bugs; the worst of which is that they tend to get stuck in some state where they hold multiple connections to the network open while continuing to attempt to connect again and again, with no delay. While this doesn't impose load that our servers can't handle, it does generate a lot of administrative log traffic that is bogus and dilutes important log traffic.

Many of these use cases can be covered by IRC, but our network isn't configured to handle such use easily as it often looks very similar to the sort of abuse we usually deal with. The common denominator in most cases like this is that it's taking too much of the staff's time and attention to support the channel and its clients. Our time is finite, and for the health of our network, we'd rather say "no" to a few channels than to make all channels suffer from thinner network staff resources.

Everything you've said in these past few comments basically boils down to:

"Your use case would basically break EsperNet (but it's because of our implementation! We have a lot of issues with our implementation but they're not because IRC can't handle it!)."

If the protocol's limitations mean that their use case is not viable due to the strain it places on the administrative side, it's still a limitation.

I read that more as: "your use case looks like the way people attack our network (and people actually do attack our network). It is too much work to enable your bots to run what amounts to simulated attacks, when what we want is a network for people to communicate with each other".

It certainly is a limitation, but any kind of service needs DDOS mitigation.

Why did you write this post?

I am intimately aware of the EiraIRC bugs. I helped diagnose the cause of more than a few that we relayed back to the mod author.

Personally, I think that you're describing a lot of limitations that we nearly crashed into with the specific implementations of EsperNet at the time. I think if a more modern system were brought to bear on the problem, they wouldn't exist. But that's all speculation; I don't know EsperNet's current or previous software well enough to say with certainty.

I don't want to sound ungrateful. What we had, and what we still do have to a lesser extent, was amazing. I wish we could have scaled it, because it was well on its way to being a 40000-user-a-day connected gaming chat network expressed via the in-game chat of Minecraft.

Sadly, that's the nature of prototypes and free software. I was willing to work on EiraIRC, but the author... seemed uncomfortable with the idea when we approached them. It's... a strange corner of the world that Minecraft modders live in.

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?

Why would this even be desirable?

All of the complaints about IRC relate to service interruptions, channels with a high # of people slowing the server, security, etc. You can fix those things by running a private network, but not for free.

Maybe because it's even cheaper than paying the monthly subscription of a single slack user?

If IRC were good enough to handle the needs of small software company communication

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.

> If IRC were good enough to handle the needs of small software company communication, people would use IRC.

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.

> 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.

> Prior to Slack existing, lots of people who now use Slack weren't using IRC, because Slack offers a lot more.

Wow, going off the deep end here. Unless you are a time traveler, there is no way to not use IRC because of slack, 'prior to slack existing.'

> it's just _obvious_ why

Uh, nope. Most people use communication platforms due to network effects: because they were invited to use it, because their friends/coleagues use it. Slack is no different.

Considering Slack is a per-organization service with minimal cross talk between organizations, your premise seems flawed.

I mean, Slack appeared on scene after many other technologies existed. People recommend it for their friends because it works well. There is no global network effect at play.

I don't think his point needs Slack to have a global network effect built in. I'd assume that, usually, a small handful of people in an organization decide on using Slack. Once the choice is made, network effects lock members in. Assuming the average org has 20 people or so, probably 90% of Slack's users are probably thanks to network effects.

Reply on news.ycombinator.com