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 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.
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.
>> 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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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?.
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.
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.
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.
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.
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.
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. :)
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.
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.
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?
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 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.
> 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.
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.
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.
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.
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.
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?
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.
> 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.
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.
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 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.
ISTR a -now undoubtedly outdated- answer to a question that was very much like "Why will there not be a real Photoshop clone for mobile devices in the near future?". One of the striking things to come out of the analysis was that -absolute best case- you got something like ~300MB of RAM (and -common case- ~100MB) to work with before you got unceremoniously killed.
I would hope that now you can reliably consume ~500MB of RAM per app, but... that's still a far cry from what you can use on a "real" PC.
How recent is "very recently"? I've been hearing ads in the podcasts I listen to for something close to a year. Prior to that, slack was only something I had seen in HN titles, and even then I had never once clicked on one.
I like slack, I think it's a great product. On finally watching their video and installing it, I immediately saw the draw, it's basically IRC with lots of usability enhancements and a lot of easy-to-configure bots available with a click or two. That said, it took me months or ads to finally take a look, but I did because the advertisements let me know that it was a possible solution for the problem I was dealing with.
It may have spread because they built a good product, but I think it's equally important that they actually exposed a lot of people to information about it. Your great product will die if nobody ever sees how great it is.
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?
IRC is just a well-established and battle-tested server/client protocol. I'm eager for the day when a competing open source server/client protocol emerges and takes over. I imagine all it would take is a really good reference implementation server and client that everyone can just start using, right?
It's a well-established shitty protocol, largely designed in the early 1990s as the simplest thing that could possibly work for the workloads we had in the early 1990s. It's terribly limited (7 bit, small message sizes, virtually no useful metadata) and in the 98% use case, its "distributed" characteristics cause more problems than they solve.
No competent person setting out to design a group communications protocol in 2015 could honestly say they'd use IRC as a starting point.
Mostly correct, but one nit to pick: IRC is not 7-bit; you can actually transmit unicode messages on every IRC network I've ever seen. It's also not usually unicode-aware, though, so if you send a message too long, it might get truncated halfway through a codepoint. Many IRC networks prohibit non-ASCII channel names and nicknames to prevent impersonation (e.g. with zero-width spaces).
IRC messages have CRLF message delimiters (and ASCII space field delimiters) and no quoting mechanism in the protocol. They're delivered over a long-lived synchronized TCP stream. Does it just happen that no 8-bit sequence people normally want to send on IRC ever manages to collide with 0D:0Ah?
I haven't seen unicode messages on IRC channels, but I don't spend much time on IRC anymore, and so this is interesting new information for me --- but there's more to being 8-bit clean than simply supporting internationalized character sets.
> Does it just happen that no 8-bit sequence people normally want to send on IRC ever manages to collide with 0D:0Ah
This is not possible on a technical level, having nothing to do with IRC itself, but instead written into the encoding design of UTF8.
First of all "7 bit" physical communication never really existed in the age of TCP - the protocol has always moved 8 bits at a time around. The "7 bit" era refers to nobody actually agreeing what codepoints within x80 ~ xFF actually mean. This is even partially true today - not everything has agreed on speaking UTF8 (hi Win32 APIs).
On the actual point of why neither 0x0D nor 0x0A will ever "manage to collide".
In a single-byte encoding (called codepages, https://en.wikipedia.org/wiki/Code_page#Noteworthy_code_page...) 0x0D always means just that, as pretty much all ASCII-derived codepages do... well, respect ASCII ( note - this does not touch on the horror of EBCDIC, which is alive and well today (2015) too ).
In the case of UTF8 any continuation byte can only carry values in the range of \x80 ~ \xBF, and any leading byte can carry values in the range \xC0 ~ \xF7. So no matter how you slice and dice things, the resulting UTF8 will have every ASCII character meaning itself (this includex \x0D and \x0A ), and the only ambiguity when mistakenly treated as any single-byte encoding would be in the "what do we do with the upper 7bit range" part ( \x80 ~ \xFF ). More info here: https://en.wikipedia.org/wiki/UTF-8#Description
True, other multibyte encodings are not so convenient: for example \N{MALAYALAM LETTER UU} ( http://graphemica.com/%E0%B4%8A ) looks really bad CRLF-wise in both UTF16/UCS2 an UTF32.
But this is why UTF8 "won" for all intents and purposes. And this is also why "escaping" is not necessary under virtually any modern environment, so IRC lacking any such mechanism is not really relevant.
( No opinion worth sharing on the rest of the article/discussion ;)
I certainly think having an open source reference implementation for a 21st century (and by that I mean having features like Slack or Yammer or other popular closed source packages) implementation of a successor to IRC would be the minimum starting point.
From what I've been able to gather, the open project that is most like Slack, but also offers self-host, decentralization is Matrix:
http://www.matrix.org/
There's also Zulip, which as far as I can gather, is battle-tested, but does not have a strong story for federated servers, nor a good out-of-box experience for really small servers:
https://github.com/zulip/zulip
Finnaly there's https://tox.chat -- which doesn't have a lot of the things IRC/Slack has (it's focused around p2p chat) -- but extensions are planned, for eg. persistent group chat. Perhaps most excitingly "new" of the three, which predictably is both a good and a bad thing:
https://wiki.tox.chat/users/faq#what_is_tox
For those that "want Slack", but self-hosted, open/free software server -- I think Matrix is the most viable alternative -- if IRC is seen as not good enough.
I've not included any XMPP servers, although eg. Prosody should be simple to set up and use -- because, apparently like IRC, it has too many problems for people to actually embrace out-of-the box XMPP for team chat. The fact that most big public services that host XMPP tend to favour anonymity probably has something to do with the fact that getting reliable server-side message logging and off-line messaging is still not as easy as one would expect, for any(?) of the big free XMMP daemons (or indeed support client side).
Actually, bridging is actually a first class citizen in Matrix - it's why the project's called Matrix (as we want to go federate/matrix together all the existing silos out there). Current bridges include:
...and a whole bunch of 3rd party ones too like https://github.com/SkaveRat/xmpptrix. Some of these are pretty beta, but they're all headed in the right direction. The IRC and Slack ones are the most mature.
Glad to hear that you think we are on the right track! [Disclaimer; i work on Matrix]
IRC lacks a viable attached business model. In fact the act of writing robust services that empower users with data portability and privacy does not appear to have a sustainable model at all currently. I don't know if the current situation is a transitory phase or if this is how large systems will be built in perpetuity.
By "battle-tested" I meant it has lots of patches/updates to the protocol to protect against certain kinds of attacks. Any new protocol would have to go through the same "battle-testing" before it would be reliable enough.
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?
It's the other way around: Mattermost has a ridiculously small userbase, compared to IRC. IRCv3 is compatible with IRC2.1. It's a lot easier to extend the IRC spec than it is to write competing software.
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.
is there a way for me to, instead of using a server password, use something like OAuth so that I can grant access to the server based on my companies central login database? otherwise, every time someone leaves the project, we have to rotate the server password...
I don't see why it wouldn't be possible, however, using OAuth would probably need some nice integration on client side you'd have to provide. Maybe just login to the server using your credentials and authenticate via LDAP?
> 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.
At which point I'll reevaluate the use of the application and potentially move elsewhere. FOSS developers pull these kinds of things all the time as well. Look at the cessation of interoperability after Lennart Poettering decided to "deprecate" consolekit in favor of the non-interoperable systemd. Or they'll stop development of software, like RedHat decided to cease development of the Insight Debugger they gained control of after they bought out Cygnus. The FOSS world is chock full of the same kind of silly, shady underhanded behavior of the rest of the software world.
And you were fully welcome to continue the development of ConsoleKit if you wanted. Slack, on the other hand, can hold all your important logs & metadata hostage.
Completely different situations. Neither of your examples could sanely be described as shady or underhanded - neither of them gave the producer a business advantage it wouldn't otherwise have. FOSS developers don't owe anything to you - they don't have to continue to develop your favourite feature for the rest of their lives. They do however give you the freedom to do that yourself.
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.
somewhat agreed, but I sort of think folks here get a bit insulated and have an inflated view of what "trivial" is. I've done a lot of sysadmin stuff for years, and web work for 20. Setting up an IRC server for me would not be 'trivial' either. Earlier this year I was told by several people that setting up an icecast server was 'trivial' too - anything but, ime.
It's the sort of thing that's really easy to do poorly. I can skim ircd docs and get something running, but making sure it's set up correctly and securely is another thing entirely.
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.
You're correct, I understand why most people don't want that, and thus also why Slack is so hugely popular. I'm primarily thinking about technical people who actually do want this (such as what's referred to in the article, people working on open source projects or who otherwise require things not offered by slack).
You underestimate how much effort it is to mantain a service running. I setup a irc logger for React and it would go down every other week, I was pinged at random times by people saying it was down and either needed to drop everything I was doing to fix it or let it be broken for a while.
I want to spend my time working on React, not be a sysadmin for the irc bot. I switched to botbot.me and it's been always up and with a much better interface :)
> 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.
Sure, but ve55 said "trivial", not "interesting" or "worth the time." It just means that you value your data and its ownership a certain way and your time a certain way. Also note that a for-profit company will have that balance in a different spot than a FOSS project.
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'll field the latter. I've used both Zulip and Slack in small team (5-20 people) settings and I much prefer Zulip.
In particular I like how the zulip UI is single-stream by default. Messages from different channels are interleaved, so you can read all new messages at a glance, but still well separated by visual elements including color - I don't find it confusing. And I can focus down to any particular channel , or reply to that channel, in one click.
It goes all-in on this "many streams, one view" model with the concept of topics - lightweight "subject headers" for individual sub-streams of a channel. This neatly avoids the "two conversations at once" problems that can occur in other systems occasionally.
Some more minor points are a wider range of markup available than slack (including syntax highlighting for code), and better support for short-lived private groups (ie. "a PM between Alice, Bob and Charlie")
As to what I think Slack does better: More one-click integrations (and likely other backend admin stuff that I don't see as a simple user). AFAIK Zulip doesn't have an irc gateway. Also when I last used it (over a year ago) Zulip's mobile client was quite poor.
I'm sure others can come up with more differences - to be honest I tend to treat slack as "slightly smarter irc" so I don't pay attention to all the bells and whistles.
Finally I should caveat that these same features I like are things people dislike about Zulip - it's more dissimilar to existing solutions and people will always have their preferred ways of doing things. I personally find Zulip amazing for me.
FWIW Zulip does have a beta-quality IRC gateway (bots/irc-mirror.py); anyone interested in working on improving that should check out this issue: https://github.com/zulip/zulip/issues/249
I especially like the concept of topics in zulip. It helps maintain different subjects in a given channel, which is way more readable imo. I'm a big fan.
Other answers address the big user experience advantages (e.g. threading) that it has over Slack, but there's a bunch of smaller features we have that I don't think Slack does (e.g. you can configure regular expressions to automatically linkify patterns like T123 to link to your bug/ticket tracker).
In terms of features Slack has that Zulip doesn't, I think the biggest ones are features that Zulip has today on zulip.com (which isn't taking new users) but you can't easily setup for your own Zulip server (e.g. the Android app doesn't support talking to a custom server without patching it yourself, mobile push notifications aren't available with your own server, etc.). Contributions on those things are welcome -- they're all relatively easy problems for someone with some mobile experience.
In terms of features that aren't just missing configuration in the run-your-own-server model, I'd say the biggest one is that Slack has a really slick onboarding experience and it has more slick integrations. It's hard to compete on onboarding with a company with like a hundred engineers, but I don't see the integrations piece as being a long-term advantage for Slack -- they're easy to write and I expect the open source community to produce a lot of them for Zulip over time.
IMO, push notifications for mobile applications is a big hole. It's not an easy problem to solve, but as of right now I believe you have to release your own flavor of the mobile applications for this to work.
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.
That isn't currently supported since it wasn't super important before Zulip was open sourced a month ago, but I definitely consider it one of the major problems that need work for both the desktop and mobile apps.
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.
Ping me over email (tabbott@mit.edu) and we can discuss; I'd definitely like to add a federation story. Haven't looked at Matrix's technical approach before...
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).
> Which chat systems were similar to IRC, but not to Slack, outside of IRC clients?
Slack is very similar to IRC at its core, so I'm not sure I see what you're asking here. I meant that IRC isn't foreign or alien to anyone who's familiar with chat clients - the basic concept of servers and channels and nicknames is pretty universal.
> 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.
I feel like I covered this point already:
> 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).
> And especially if you don't do it all the time, getting people set up to work with Slack is way easier than IRC.
What are you referring to here by "getting people setup"? Like a corporate environment? It's fairly easy to setup bouncers and the like in a corporate environment using tools like chef, etc. I really don't feel like this is a strong argument for a corporate setting.
If you mean on a personal level for individual contributors to get up and running on contributing to FOSS, sure it's not 100% frictionless - but pretty much. Again, there are lots of bouncers that can be setup with <5 commands.
If the argument is that it takes an extra ten minutes to install ZNC vs. Slack, then I dunno - I guess I don't see that as very much friction when the tradeoff is using non-free software.
> I really find these discussions half amusing and half depressing
I feel the same way, but for different reasons. It's a little depressing to me how averse people are to spending 10 extra minutes to use FOSS, usually under the guise of "I have different priorities." I thought developers in the wild would at least be slightly more willing to invest the time, especially post-Snowden, to use FOSS. I guess that was just a college pipe-dream of mine.
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.
I think that's true, but I also think it's a little silly to contribute to FOSS but be unwilling to spend the extra time to use FOSS.
I guess it's kinda just sad to me that you'd be unwilling to spend the time to use FOSS while you're contributing to FOSS. If it was incredibly costly, sure, but IRC? I dunno.
We're interested in tinkering with a lot of technology. We're not interested in tinkering with boring (admittedly a very subjective judgment) technology like a chat server.
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).
I don't understand what on that page would let you read messages people sent while you're not connected, or let you participate in IRC over an unreliable connection such as a mobile network.
Or use Quassel (an open source project very similar to the proprietary IRC Cloud) and you can easily import the entire history of a channel into the backlog for a new user.
What if I didn't have the foresight to put that bot into the channel in the first place?
Or what happens when the bot goes down? So now I really need to build some alerting into it so that someone can restart the thing when it dies, or the server is upgraded, or it's moved.. because I'm losing valuable history along the way.
Or I can just use Slack.
The snark about developer skill is an interesting one, as you failed to actually solve the problem in your hypothetical.
Seems you've only explored failures for the IRC option.
What happens when Slack closes? Or they change their payment plan? Or they decide that they don't like your project? Or they're acquired by Microsoft and stop supporting your OS? What if a rogue Slack employee spies on your chat and steals your secrets?
So slack manages everything for you with their service. They ensure their logger is always running, their web services is always available and a Miriam of other things.
What you want is to outsource your messaging service. If you want this to be managed in-house, you must monitor the service as well. You can outsource IRC as well however, and they'll manage the boys and infrastructure for you.
Not sure if I understand what the issue truly is here!
I'm a developer. The problem is not that I'm "failing to rise up to this level of problem-solving". The problem is how much free time I have, and whether I can afford distractions from my main project to fiddle with IRC and get it to do what I want.
We use Slack because "it just works". You get invited, you join, and BAM! You're done. There is one uniform client for all platforms and a bazillion integrations already developed for you. And creating your own is usually a simple matter of sending a POST request to a channel's webhook using a unique token.
Essentially it comes down to this: IRC is a protocol that requires a fair amount of research and configuration to make it do exactly what you want it to do. Slack is a product that comes with the vast majority of features most teams need. That's why a ton of people are gravitating towards the latter.
But that's substantially less useful than Slack's search utility. Believe me, I've spent my fair share of time grepping IRC logs and it certainly works up to a point. What you describe is a pretty lightweight, low-utility solution (are you really going to download six months/a year/10 years worth of logs and depend on your browser's search?).
Plus, keep in mind there are other people besides developers. There are product managers, UX engineers, designers, translators, and any other number of people who might not be familiar with grep and would otherwise not need to be. Assuming that only developers need to chat is pretty naive.
Should I take the time to create a solution that not only works for me, but is a pleasant user experience for my entire organization? That is a piece of work that is bigger than "python -m SimpleHTTPServer".
Or, I can trade money for a team that is actively solving the problem already.
Or, people who care could get a group together to tackle the inadequacies of IRC for the business use case as mattermost is trying. But let's not pretend that IRC fits the Slack use case well.
> How do some developers fail to rise up to this level of problem solving?
It does seem to solve the problem of how to set up a channel log in IRC but I sort of find this quite a narrow redefinition of the problem. The problem could also be:
* What is the best technology to use for collaboration?
* What kind of software and tooling is in line with our project philosophy.
I don't find either this comment, nor the one it is in reply to something that can be applied more generally. This is, at best, solving a problem that is a component of a much more expansive problem.
Why do you want that? At my company I don't think anybody has IRC logs enabled, and it is highly suggested that you don't do so - chat, much like real life conversations, is inherently ephemeral.
I can't tell you how many times I've went back and searched for a solution to a similar issue we had six months ago and solved it through collaboration in slack.
Should this end up in a separate wiki? Maybe. Will it? Not always.
I wrote a bot to serve log history search requests in my local IRC channel, because I got tired of fishing through my logs on behalf of other people, who wanted my history for basically the same reason.
At which point I got tired of whitelisting people instead, after abuse issues compelled me to disable anonymous access...
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".
There are an increasing number of plausible FOSS alternatives to Slack out there like Zulip, Mattermost, LetsChat, RocketChat etc. Classic IRC simply doesn't compete in terms of the featureset, glossy clients and web-dev friendliness. However, most of the FOSS Slack clones miss one vital point: they just provide a random custom API to their clients which may not even be published. Despite being FOSS software they're not actually promoting Open Communication - they are just building yet more silos that fragment your conversation history and contacts/contactability even further. If you want to pick your own client, or pick your own server, or interoperate with other comms networks (other than naive bridging), you're generally out of luck.
This is why I personally believe it's vital to support open standards for communication like Matrix.org or XMPP or IRCv3, and build glossy clients and services on top, so that rather than being locked into a single server & client from any given project, we retain the freedom to pick the clients, servers, services and service providers that we want rather than being forced into using particular ones for particular communities. A good start would be for the Zulips and Mattermosts of this world to federate with Matrix or XMPP out of the box, even at the lowest-common-denominator functionality set, to support open communication rather than causing yet more fragmentation.
Somewhat tangential but relevant, what the hell happened to XMPP, period? Wasn't it supposed to be our one communication account we do groupchat, video calls, IMs with persistence, and file transfers over? Why did it just up and die with nobody working on it and nobody using it?
http://xmpp.org/extensions/xep-0045.html exists. Its groupchat, it could probably be amended to support inline code, and its persistence model lets a server chose to broadcast the message history or not.
And it is incredibly more user-friendly to make an XMPP account through a GUI client, have username@server, then join group@server for groupchat. No /join, no /register, no port management or #channel management. Hell, any reasonable XMPP client would default to your current server for groupchat so when you click "join chat room" you get the server part prefilled and you just enter the group name (or pick it from a list of groups - the protocol supports channel announcements).
I get that XMPP is a horrible format (XML) and horribly bloated (committee) and horribly old (1999?) but if its that broken why can't we make another protocol for peer to peer realtime communications? Why isn't webrtc becoming that transport? Why do we keep getting these one shot web startups trying to replace open protocols every other weekend for a quick buck?
It's sad. But the only thing that can be done is work on an actual protocol that will solve these problems. It's a big burden to bear, and more often than not, building something that will bear such a burden just kills it outright (cf... xmpp.)
I am following it from afar. I don't see how it'll gain traction, ever, though. The marketing problem is one devs don't like to solve, but it has to be solved.
* Ensure there are glossy Matrix-native clients out there with a Slack-equivalent level of good UI and UX (e.g. http://vector.im/beta)
* Build bridges to federate together as many different protocols as possible. This includes IRC, Slack, XMPP, SIP, Lync, Verto, Respoke etc. We're trying to make this as easy as possible by providing some high level building blocks like http://github.com/matrix-org/matrix-appservice-bridge. This hopefully will make it easy for others to bridge themselves into Matrix once we have critical mass.
* Release a stable version of actual Matrix standard itself, keeping it as simple but capable as possible. (Right now it's not frozen, and it's still in beta)
* Provide a really capable reference server implementation. (The current one, synapse, is a good starting point and works well for experimenting with Matrix, but we still have work to do on performance and scalability).
* Run around the world encourage existing projects/networks/solutions/developers to get involved and defragment their comms - a bit like the early internet guys had to do with defragmenting email.
It's obviously hugely ambitious, but we actually have some good traction already (despite still being in beta). Hopefully the trend will continue!
But she's not a developer. I couldn't reasonably get her to use IRC.
I couldn't get her to use XMPP.
I couldn't get her to use Facebook chat. (Moral reasons, there, mostly.)
She could get started using Matrix in a single sitting. We're still using it to communicate.
Anecdata? Absolutely. With a dash of emotional appeal, even -- the worst kind of anecdata! Still: true. So, while Matrix may not have a million dollar marketing budget in play... there's reasonable hope that the ease-of-use requirement for mass adoption is well on its way.
Completely agreed. I love Slack and it makes sense for a lot of things, but not for FOSS projects. If you're looking for a great IRC Client look into IRCCloud[1]. It has a really nice and easy-to-use interface plus it allows you to be always logged in, just like with Slack.
It's not as simple as "just use IRC". Even in cases where an IRC channel is both available and relatively well-promoted, some communities still seek out other tools. The first example that comes to mind is Reactiflux, a rather large React.js community that recently moved from Slack to Discord[1][2], another closed source app that will probably stay that way[3].
To me, the fact that a community of tech-savvy developers won't use IRC exclusively is a pretty good indication that IRC is not enough.
For context, we've always promoted IRC for real time communication on React. I encouraged people to setup other mediums for communication and many people attempted but only one took off: Reactiflux on Slack. The official way is still IRC on the website but most people are using Reactiflux which is pretty incredible.
Now, we got the bad news a month ago that we've been kicked off of Slack :( So, I started looking at all the options and frankly, all the alternatives I tried had a really bad user experience. Sure, they had all the features of Slack but the polish was not there.
Until I randomly stumbled upon Discord, a chat app for gamers. It turns out that it does everything that we used Slack for, has better perf than Slack... Before we even made the switch officially, people were already using it organically in favor of Slack which is a testament of its qualities.
I highly recommend using Discord for your open source project!
Hi Christopher! :) Thanks for expanding. To clarify, I didn't mean to imply that moving to another closed source solution was the wrong decision. In fact, Discord seems like a great tool for the job. I just wanted to use the migration as an example of how/why some groups don't switch "back" to IRC or other open source solutions, because their needs are better met by something proprietary.
I'm a big proponent of open source, but I'm also all for using the right tools, whether that means open, closed, or some combination of the two.
We received the following email from someone at Slack:
"I’m writing to inform you that we've disabled the ability to add more users to the Reactiflux Slack team. We're happy that you've found Slack to be a great platform for your community but from both an administrative and performance perspective this is proving to be unsustainable.
Although we do simple chat and file-sharing very well, Slack simply isn’t designed for communities of thousands of users to chat. Slack's ideally designed for teams of coworkers who collaborate closely and frequently to get work done. That said, looking into ways to better support communities like yours in the future is something that has been suggested many times! The idea is under consideration, and if changes are implemented to make this easier in the future, we'll be sure to get the word out.
I’m not sure how you’re sending out your invites, because if you’re using the web interface it should tell you that your maximum user limit was reached. If you’re using the undocumented API, we’re returning a user_limit_reached error that you'll run into soon.
If you do want to continue to use Slack to manage this community, I'd recommend you spin up multiple smaller teams and cap each one around no more than 1,000 users. Once one team fills up, stop inviting people to that team and start a new one for the next group of people who want to join your community. That's the best way to ensure that your teams remain manageable and that the service stays nice and snappy for you.
Thanks so much for your understanding. If you have any questions, please don't hesitate to drop us a line!"
Slack is the wrong choice for large community projects for one pragmatic reason: the 10,000 message limit for free teams. I participate in a large developer community that lives on Slack. Conversations are deleted quickly on less active channels like #lisp or #volleyball, sometimes within a day. This is frustrating when trying to connect to like minded people and also maintain a record and resource for community members. And at $6.67/user/month it really isn't viable to upgrade.
I can't speak to the quality of projects like Mattermost [1] and Zulip [2], though I'm excited by their concepts. IMO trying these, or using a hosted service designed for community projects like Gitter [3] are necessary alternatives.
Yes, the 10k limit kills it. After that you can still search old messages and find them but you lose the context because you see only a few lines around them. Either your FOSS project has a budget to pay Slack or you're bound to lose any valuable knowledge and decision buried in the archive.
Main thing that Slack solves as far as I'm concerned is a great and uniform client on every platform.
Don't get me wrong, I love irc. This is where I started learning everything I know about computer.
I tried many times to get various team on it and it always failed. I think it's mainly because the learning curve is too big for non-technical/busy people, and that there's no good and uniform clients on all platform.
I think this is a really important point. What Slack solves -- speaking in the general case, not specifically for FOSS projects -- is that it's an essentially out-of-the-box solution. Not just for non-technical users, although that's very important, but for all users.
Both the linked article and the various suggestions in comments give all sorts of IRC-based alternatives to what Slack does, but they're all things that, let's be honest, require a lot more work to set up and are often far more fiddly to use. "Oh, this is easy, just run daemon X for this functionality and daemon Y for this functionality, and set them all up using stuff you can get here, here and here. Wait, that last one is out of date. Try using this gist instead. Okay, now, you can get that client-side feature you want if you switch to a different IRC client, use the following .config file, and look for the following plugins, although you'll probably want to change the defaults..."
Compare this to Slack, which for most users is: sign up, click here, and in Jeff Goldblum's words, "There is no step 3." From a practical standpoint you have to install zero new pieces of software (assuming you already have a browser), you have to edit zero fiddly text files, you need to install zero Perl scripts. Once your IRC is set up it seems "easy," but it's possible to spend an inordinate amount of time finding the answers not to questions like "how do I get snippet previews of links to show up in the client like it automatically does in Slack" (the answer is probably that you do not), but questions like "how do I get all the nicknames to show up in different colors?"
For certain FOSS projects, this may be less of an issue because the team may be more experienced in setting up frankly fiddly Unix software, and I think having an IRC channel is a good idea. It may be all you need; what Slack gives you above IRC is generally "nice to haves" rather than "must haves." But the FOSS crowd, to make a very rough generalization, often tends to deprioritize "nice to haves" to a point where they miss, well, just how nice it really is to have some of them.
You're absolutely right. But it's sad that comments like this even need to be made. Like people constantly forget that usability is a thing and not everyone has infinite free time to burn on setting things up.
..especially for open source. Increasing the time barrier/complexity just to chat is a big turn off. I already use Slack for work, so adding FOSS projects would be easy. But if I have to fiddle with chat, that's time I could be coding or doing something more productive.
This whole discussion is similar to that Ogg vs MP3 file nonsense on Wikipedia; the victory of philosophical purity over practicality and usability. I still can't just click a Wikipedia sound file on my iPhone and have it just work. Victory for ideological purity big fail for the 98% of the world that doesn't give a s--t about file formats or Jimmy Wales's religion.
As someone with no ops experience, can't most of this automation be done with Puppet or Chef? If so, is there anyone with public github share of those files?
As far as I know, most of this complexity surrounds setting up the _client_ software, not the server bits (though that, considering availability and so on, is its own bucket of worms) -- you just don't get Any Random User to install Puppet or Chef and pull in a cookbook or recipe or I don't know what they're called and ... well, I guess you get the point.
I think it's that it never gained a groundswell in the US. In Europe, and I can think of sweden and norway in particular, there were all sorts of completely technically illiterate people on IRC. Their friends just showed them how to download the client and connect.
I remember using IRC in the early 90s here in Norway, there was basically a channel for every municipal, school, social group etc. Even my mother used it.
That anyone find it hard to use is flabbergasting to me as it is a matter of opening a client, entering a nick and selecting server.
With the web IRC clients it's even easier I guess.
I still hang out in several of the channels from my early days :)
Yeah, nothing about IRC is intrinsically difficult. There's some things that are much easier on Slack, like archive search, but how many people actually use that?
If you tell people something is hard to use, they'll believe you. If you tell them how to use something, they'll use it...
The really big thing for me is persistence. If you want your client to stay online when you are not, things get very painful. Bouncers are a pain to setup, command-line IRC clients are awful, and I've seen countless people horribly confused by screen and tmux.
With slack, persistence comes for free. The only thing I've seen that comes close is irccloud, which is in my opinion an excellent competitor to slack. In the end my organisation went with slack because it's nice to have everything grouped and billed to the organisation, as well as being even simpler for end users to join.
As opposed to IRC's NickServ, ChanServ, and their variants depending on the server? Expired nick, exposed passwords due to insecure authentication mechanism, no standard client, and so many more I can cite.
I love IRC and grew up with it. But don't compare it to Slack for technical knowledge requirement.
I know people who don't understand what a Server is and even they can use IRC. Not saying that it's as simple and convenient as Slack, but making it out to be this huge complex thing is being disingenuous.
My PM was able to set up Slack integration with Trello and Github in a few moments, and found that connection incredibly useful. She didn't have to KNOW that she wanted it, she just saw it on the list of possibilities. She didn't have to go looking for instructions, she just hit connect. She didn't have to ask me or one of the other consultants to stop billing project time to set up some tech for the office, she could do it herself.
In my firm at least, Slack is an incredible tool for our PMs and owner, and it also works well and covers all use cases for the consultants.
The people who clamor about IRC's death evidently don't spend much time in FOSS communities, especially system software. It's absolutely pivotal in those areas.
I find it surprising that everyone apparently thinks that it goes without saying that Slack's interface is superior to other choices.
It is full of visual noise. You end up in desparate need of splitting most types of information streams in separate channels because of it, and then before you know it, you're channel-hopping all day long.
For core functionality - chatting - I've found that most IRC clients I've used are superior to it. Hell, even Facebook's chat is superior.
It'd take fully redesigned fully native client idiomatic to every platform abounding with customization options to make me take a stroll through that garden. Not web client and especially not some Electron (is it?) desktop client that looks more like afterthought than carefully crafted experience.
- Modern! (There's actually control structures in the protocol. Imagine: a chat protocol that's actually ascii safe! (Yes, yes, unicode too: the joke is, IRC isn't even ascii safe.))
- Many platforms! (The matrix.org site has a full client list; I'm personally using it via a linux desktop client (that also works on windows and mac), the web, my ipad, and my android phone.)
- IRC bridged. (I use it constantly in this mode. It's a better IRC experience than any other IRC client I've used, honestly. Even in rooms with 100s/1000s of people. Consistent logs, instantly accessible from multiple computers/clients, no need to set up bouncers, and so on.)
- File uploads, images, videos. All of it. A friend streamed me a video from his halloween party last night via the Matrix client on his iPhone. It worked.
- Did I mention it even supports webRTC? That's right: it's also a completely functional skype replacement. (Yes, pending your browser's support and all that jazz: that said, it's a more complete product than most of the other webRTC demos floating out there.)
The entire protocol is just... good. On the nerdier deep end of things: It's the first federated chat standard I've seen proposed that actually has reasonable message IDs baked in and loose timing systems that's both available during a partition and can reach consistency afterward (messages list their last-seen messages, and so act like vector clocks, an accepted good solution to problems in CAP territory). You could actually take two systems with clock skew and have them reach a single, reconciled view of the world, even after netsplits. Compared to IRC (or XMPP) this is either magical or a deep relief, or both.
I discovered Matrix while I was in the process of writing a chat client of my own for XMPP. I abandoned the project (and XMPP, as well, though that's a subject all its own [2]). Matrix already did everything I ever wanted. Really, really well.
Not affiliated; just a happy user who's never found any better platform for communicating openly.
matrix solves a lot of problems that IRC has and even lets you solve those problems on IRC through the Matrix<->IRC bridge :)
I've been using it as a replacement for my IRC bouncer for a while, barring a bug that prevents support of SSL-only rooms, and it's been wonderful. Great web client on vector.im, pretty decent mobile clients given they are "reference implementations", support for VoIP voice and video chat, coming support for e2e encryption (the DAG just stores encrypted blobs now)
I've long felt that a big piece of my love of IRC was the spontaneous intersections of my communities. I got involved in FOSS and open source because one time a person mentioned there was a LUG chat for the city I was in; that led me in to a long chain of events that ended with me getting involved in the Fedora Project and other FOSS communities. Slack is creating a world where that is simply not possible. One of the big things that this discussion misses is that tribal-intersections that IRC allows opens up a huge door for abuse. Slack "solves" that by siloing you away from the world, but that has always been a lazy and error prone solution.
I feel like Matrix is in a position to move the needle on that. It's got a huge distributed DAG specifically designed for human-metadata like chat and presence and, well, why not put Karma or Reputation on that DAG as well? People have talked of dogecoin and similar as a Whuffie (https://en.wikipedia.org/wiki/Whuffie) and in my mind Matrix is an interesting platform to build something like that on. I could create a room that requires a certain reputation level to post in, and you'd have to gain reputation in other communities to be allowed to post in to mine. When you realize that Matrix.org 1:1 chats are just "rooms with only two people in them" that becomes a really nice way to solve the spam/abuse issue. Prove to my friends in the public chat that you aren't a shitbag and you can talk to me.
I'm curious if you ever evaluated something like Pubnub or Pusher and how matrix stacks up versus them (as a self hosted chat API for mobile platforms)
This post is completely disregarding the ease-of-use of Slack (and other silo'ed chat rooms), mainly due to it's pretty monolithic structure.
Yes, there are many things that Slack does that _can_ be done with IRC, but they require significantly more coordination between various parts than Slack. I'd love to see an alternative to Slack not just a clone, as easy to use and administer, and built on an open protocol. Individual teams should be an easy entry point for a tool like that.
I will add one silver lining to all of this (since I agree with everyone talking here that IRC is "hard"), Slack is also hard. That is to say, we're still in low hanging fruit phase. I don't know if I was just doing it wrong, but when I had to join the Slack channel for a FOSS project, I found it very confusing:
1. I had to be invited or something? (Still don't know if this is the case always)
2. It still remains a mystery to me exactly how Slack treats different accounts (or are
they all the same account?) for different projects. It makes me like sign in to them differently but then they all show up together?
3. The Slack app is great or whatever, but its cool when a project can just embed an IRC channel, and even just make you an automatic account, right inline on their site and not have to deal with signup for anything.
If someone wanted to enter this space, they still could. Just make something that allows you to have one "Account" that would work across the board, had an embeddable widget so there's no "going" to the chat, its just there on the project page, has bots and emoji or what have-you. Maybe Gitter is working on this (already has all these abilities?). But suffice to say, I find it funny (sad?) that the discussion is around how easy Slack is vs IRC when IMHO Slack is still pretty hard and confusing.
Hacker News:
is closed source
is a walled garden
requires a "Y Combinator" account to communicate
Most people don't use software because of the driving philosophy behind it — they use it because it solves a problem of theirs.
If a tool is the best one for the job, you should use it. And if Slack has a substantially better UI for communication, maybe developers of IRC clients should try to build a better UI rather than complain about adoption of Slack.
In all fairness, while the currently running incarnation of HN isn't open, earlier versions of Arc and hn/news (along with forks) is open source, eg: https://github.com/arclanguage/anarki/
Then there's the API, that allows anyone to export data. So while I get your point, and agree with it to a certain extent, it's also not entirely fair.
There is a chance to repeat git success story. Remember what happened? 1. Everyone uses cvs or svn. 2. Bitkeeper comes along with a good DVCS, gets adopted by Linux. 3. Linus rants about closedness of BK, reimplements it as git. 4. Git takes life on its own gets wildly popular and makes way for many awesome things such as github and gitlab.
Replace svn by irc and bitkeeper with slack. Figure out the rest.
2.5 Tridge starts implementing a Free version of the bitkeeper software so the Linux project doesn't have to rely on closed-source software to build their Free project, and Bitmover revokes the no-cost license given to the Linux project, just like they said they would.
Slack is awesome. It's way better than IRC in many ways. But I agree with the OP. Please don't use it for FOSS projects, use it for your company or other private use cases. But FOSS projects an communities require open tools. Slack won't save your history unless you pay for the service. The pricing is per user which makes it very bad for a FOSS community.
> I put a lot more faith in something that’s been going full speed ahead since the 80s than in a Silicon Valley fad startup.
That's how I felt during the dot bomb era when I heard that General Electric had been eclipsed in market cap by one of the new startups, Amazon.
Although IRC has an old heritage, it's arcane and user-hostile. To some extent it wants to be that way, to help keep the unwashed masses away.
IRC isn't as easy to use as Slack for things like persistent history accessible from mobile and desktop, and integration to git. That's why alternatives are gaining ground.
If this situation bothers you ideologically, there's actually something you can do! You can help open source alternatives be as easy to use and integrate as Slack is. If your goals are less ideological and you just want your team to immediately get on the task of solving business problems, consider Slack.
Amen. To add to the list, there's also Bitlbee (https://www.bitlbee.org) that acts as an other protocol (AIM, MSN, XMPP/Jabber, Twitter, etc.) to IRC translator, so you can consolidate all your short messaging into one IRC client. The ZNC + Bitlbee combination is quite powerful.
Additionally for iOS users, there's a push notification client available for ZNC, which is pretty handy.
IRC kind of sucks. The experience is worse. That's why people keep making these different tools - Campfire, HipChat, Slack.
It's not just a technical thing. It's an experience thing. IRC is technically fine, just way too nerdy to be main line of business software these days.
Twitch.tv is using IRC in their main line of business (their chat).
It seems to work fine for them and it is easy to write custom bots etc for it as it is based on an open protocol.
I can't agree more with this headline. I can concede that IRC isn't the most modern of technologies, but it is effective and well-developed at what it does. There is a FOSS ecosystem that can be achieved with IRC, which cannot be achieved with Slack. As a FOSS project, you can commit to only using free and open software when you also use IRC, as software such as atheme or charybdis are all open.
Additionally, Slack is more privatized, with a less opportunities for enhancement (e.g IRC bots, IRC webchat, many clients). All users also need to sign up prior to use, which is just simply not viable. IRC manages large influx of help-seekers or project members well with its op-voice-user and ban/quiet system, allowing for channel operators to handle the high amount of users without a problem.
On the other hand, Slack fails at all of these points, as it is intended for internal team usage and struggles with this specific usecase.
Furthermore, most FOSS contributors are also not contributors to a single project only. For instance, I personally contribute to a variety of FOSS projects, and it is extremely easy for me to coordinate with all of those projects simply by opening a new channel on my freenode or OFTC network in my IRC client. Slack lacks this, requiring a new tab for each project and really lacking support for FOSS operating systems such as Linux distributions, a problem that is likely not going to be fixed due to its closed-source one-client structure.
I hate irc. I hate it for one main reason, nobody uses it. Now, before you say "over x million users" I mean use, like I actually talk, not just sit there logged on. I have tried to join a lot of open source or product channels on irc (pypi, python, docker, wercker, kubernetes, etc.) And every time without fail, I join the channel and there are over 50 people signed in and I'm like "awesome people actually use this channel", then I proceed to ask the question the prompted me to lognin in the first place. After four hours and no answer or response at all, I usually have to go home, or shut my computer down. I don't have a desktop running 24/7 just so I can irc. So once I log off, I know I'm never getting an answer. I might try again if I have another burning question, but with a couple of tries and no luck, I eventually give up.
Now slack on the other hand I've never had this problem. I don't know what it is, but some of the same communities switched over to slack (i.e. kubernetes) and once they were on slack, I was getting responses and discussions from multiple people within 15 min or less.
The beauty is even if the channel wasn't as active it would still be a million times better because I can shut down my laptop, and get notified on my phone when someone replies. I can then continue with the conversation publically or privately, even if the two of us are on other sides of the world, because history is saved and I don't miss anything I'm notified on, even if I'm not logged in anywhere.
I know of at least one tech company using slack as a support channel. It's not a great experience for the user at all. I love slack as a company communications platform but I totally agree that it's not well suited to being used as an open communications platform.
At Qbix (our company) we believe that there will be a platform for social apps the way that Wordpress is for blogs.
We just recently met with a VC who was impressed with our platform pitch, saying he hasn't seen something large in our space that's open source yet. Slack specifically came up as something that Andreessen Horowitz made a big bet on. I'm not going to say much (unless someone asks) except that:
* It is designed to put control back in people's and communities' hands. It should be installed by communities, or they can choose us to host, like wordpress.com does
* Each community can release its own client app, BUT you can also have client apps which provide a seamless experience ACROSS communities and let you do identity + connect with friends + get notifications across communities!
* This was not easy to build. It took us over four years.
We started before Diaspora* and we built an open platform on which app developers can build apps which communities can install, and which can aggregate social experiences across communities. The apps can be ANY social apps and the platform takes care of all the underlying details, including app versioning, user identities, "finding your friends" in each new community, registration/password stuff, email / mobile notifications, native app integration and caching, and much more.
I'm responsible for a medium to large FOSS project. I noticed that Wordpress had recently moved to Slack, and asked someone I knew over there how engagement had changed after the move.
I get the arguments about not using it, but my priority is providing the best tools to the community to enable them to work together productively, as well as providing the most effective forum to encourage more people to get involved. How can I ignore that sort of order of magnitude increase in the number of people who can engage in real-time with the project?
I've heard the Wordpress tale and I would guess that it's more related to the announcement and press around it generating attention than it is the merits of either platform. A lot of people who didn't know Wordpress had a chat room probably joined up.
Completely agree with this. We use Slack for our Business Communication and love it, we pay for it so we can see all our messages and it definitely has its place. (Office Managers, Project Managers, Directors, PR are all in it, super simple and easy for them)
For Open Source projects or just general communities IRC is the best medium suited to it. Yes IRC has its issues but maybe that's because no one has brought it forward with the kind of velocity other projects seem to have these days.
I don't boycott Slack teams I just find it difficult to manage more than 2 teams in the client so I just don't, I like channels in IRC. I can flip between them regardless of server or team and can see the entire history.
Scans as a case of the "I like X better than Y, therefore X is objectively better than Y" rationalization fallacy. Someone else could easily use the same set of facts to argue the opposite case: "irc doesn't support code snippets, so ....". The political argument that you shouldn't use a closed-source product also irritates me. I use a tool because it's the best tool for s job, and FOSS is very often the winner there. But if the FOSS option isn't the best choice, don't tell me I should be using it anyway. I don't attach moral weight to a choice of licensing model.
Are any particular irc networks recommended for FOSS collaboration? I'm guessing channel and Nick services should probably be a prerequisite but other than that, where do people prefer to congregate?
Main problem with IRC is that it's not "always on" and I really need this feature. Sure you can use IRCCloud or SSH/Screen into a server, but they both cost money while Slack is free.
If you don't care losing the chat history after 10,000 messages, then Slack is free. 10k seems a big limit but it's only a few days away if you start integrating bots for GitHub, Bitbucket, Frontify etc.
On a project a customer of mine disabled all those integrations because we couldn't go more than one week back into the past. Thery were not willing to pay Slack and we were losing track of decisions and accountability. When that happened we started writing down more things into Google Docs and the conversation shifted naturally from Slack to the comments of the docs. That had the (IMHO positive) side effect of reducing the time spent chatting about the project and of increasing the time spent to actually build stuff.
How is Slack free? You have to pay per user or apply for an exemption if you are a non-profit. IRCCloud is free by default and you only pay to unlock some extra features.
Completely agree! I see free software projects depend on proprietary tools all the time and it is very frustrating. I often see projects using JIRA or asking companies like JetBrains for gratis licenses to proprietary development tools, and now I'm seeing Slack more frequently. I will not participate in your free software project if you depend on SaaSS or proprietary software to get work done.
The company I work for uses Slack, and luckily there is an IRC bridge to connect to so I can keep my workflow in Emacs rather than having to use a clunky web interface, but there are many special Slack things that they don't render correctly in plain text form so I feel like a second-class citizen. If this is the future of text-based communication, I don't want to participate.
I like IRC. I like that things aren't centrally logged by default. I like the bots that I've been interacting with for many years (that I find to be better than whatever Slack bot I've come across, by the way.) I like Freenode as an IRC network. I like the variety of clients available (I prefer ERC, a client written in Emacs Lisp.) Could we use some sexy web clients to get less technical people on board? Sure! Should we use a proprietary, centralized, surveillance system until someone else fixes IRC issues for us? No way! We must reject Slack because it isn't a tool for the people, but a tool for profit.
What makes you think IRC isn't centrally logged? You realise that the Freenode staff have root on all Freenode servers, right? It's not actually a decentralised network at all, it just looks superficially like one from the outside: they could log whatever they wanted at any time.
I'm not even sure the servers use encryption between each other. If they do I didn't see any mention of it on the freenode website.
Heck, given that SSL isn't even a default for many IRC clients, I suspect that in practice it's vastly easier for governments to eavesdrop on IRC than on Slack which is fully SSL, always.
The software is very simple and doesn't have the ability to log messages like that. I maintain a fork of the ircd freenode uses and that simplicity has actually been a bit of a pain as things grow.
SaaSS? Seriously? The FSF's use of that is about as childish as Microsoft with a dollar sign. Is getting your taxes done by another party Accounting as a Calculator Substitute? Is taking your car to a shop Mechanic as a Toolbox Substitute? Slack has a lot of useful parts that go beyond just chat. Having a simple way of sharing snippets, saving history, using shared file repositories, all of which are easier if you don't strip out metadata and just throw a bare link into the channel. Finally, your false equivalency, that making money is always antisocial behavior, is ridiculous. Slack fills a niche that IRC doesn't and can't, and the developers decided that they would rather prefer a way to work on the project full-time without having to beg for donations.
Times do change, and tools do get better. Yes, it means having to change yourself, but stagnant work habits probably mean that you're missing other toolings, other methods, that can make you more productive. Sometimes, you do have to pull yourself out of your comfort zone, even if it means using eeevil software made by people with a salary.
From http://www.gnu.org/philosophy/who-does-that-server-really-se... : "Neither is publishing your own materials via a blog site or a microblogging service such as Twitter or StatusNet. (These services may have other problems, of course.) The same goes for other communication not meant to be private, such as chat groups."
Isn't another huge thing that Slack solves the need to set up a local client? Why is that not addressed in this article, I wonder if the author really doesn't see it as a problem?
The things slack can do (at least according to this article) that IRC can't are do small it's negligible. If slack is web-based, then what is to stop someone from making a web-based IRC client with all the features and good UX design of slack?
One thing even private organizations should think about is the potential for chats on Slack to embarrass the heck out of them. Slack doesn't let an organization sunset and delete private chats/DMs after a certain amount of time. When employees think they aren't overheard they start to get very frank with each other (which is good, I think frank and direct communication is important). But sometimes they say things that are ignorant or even their frankness can reveal things about the company that are embarrassing. This isn't even a theoretical scenario anymore, look no further than dumps from recent hacks.
I like Slack's default-to team member privacy but you can implement these features without compromising that. I opened a case with Slack about it but they closed it with the standard "consider it in the future" response that I expected (which I don't hold against them, I can't say I wouldn't have done the same). It may take a breach of Slack's infrastructure and subsequent leak of private chats for them to make the changes needed for organizations to protect themselves from this.
It might only take user education to protect a company from this, but in the end if you're a big enough organization there are going to be people that don't care, hate the organization or are just to jaded to take the ramifications seriously.
Thanks a bunch for this. I'm surprised the person helping me didn't know about this (unless it's fairly new) but I should have put more effort into researching it myself.
I think it's perfectly fine for FOSS projects to use non-FOSS. This article is a wee bit on the fanatical side for my taste, and I'm the guy who bought the lemote. ;)
A public FOSS project should be able to use whatever they want for bug management, issue management, support, and other things that do not affect the core project in any way if compromised or monitored.
Especially if the company behind said product even give out discounts or free usage accounts to such projects like Atlassian or github.
Yeah, IRC clients are hard to use, too many are command-line based, although on Linux you can still find a few with GUI, but not as pretty as Adium on Mac OSX. Your mileage may be different, but when I was working at Mozilla everyone used IRC and it was not a huge burden because most people really just do /join or pm a person. As long as you provide a documentation on how to use IRC, you are golden for the most part. If you mandate people to use IRC and have resource available to help troubleshoot or setting up IRC, you are good. If you need to set up some complicated things with IRC, well, it is tough, but you are on your own.
Slack's interface is not very impressive, very messy in my opinion, but that's me. There are businesses out there offer IRC as a service, so that's another option.
Final point: I really don't care about FOSS vs OSS vs Proprietary. As long as the company truly respects my data privacy and security, and is easy to use, I can give zero damn about either of three. It's 2015, we need to stop arguing and actually make things better. Business needs to focus on improving product experience and security. But you know what, some people do, that's fine, none of my business anyway.
If you want to communicate with a person or organization in ways that don't involve online chat, you have a variety of standard ways for doing so:
- E-mail address
- Phone number
- Mailing address
What is it about chat protocols that has resisted convergence on anything as remotely standard as these other methods? I mean, I could tell somebody that I spray-painted hieroglyphics on my house and that "there are 3 shipping companies in the world that know how to find my house using hieroglyphics so please ship through one of them", yet somehow my "address" has remained the sensible way to handle that problem.
The problem isn't Slack or IRC or any other client, it's that we have any choices at all. At this point we don't need choices for chat protocols any more than we need a choice of ways to put an address on a house. The technical community needs to start loudly criticizing clients that aren't converging on some standard, and standardize more and more behaviors every year until it really doesn't matter what people are using.
While we're on it, can anyone recommend a good open source calendar app with decent web and mobile interfaces? (if there is one)
I'm building internal tools for the record label I make music with. We're going to try self-hosting Zulip vs. Mattermark for collaboration, and it would be great to have a calendar that integrates well.
Slack is starting to be used as the communication platform at events now as well. Most of the hackathons and conferences I've attended recently have used it and added all of the attendees.
It's worked really nicely for communicating announcements and updates with the added benefit of allowing attendees to socialize before, at, and after the event. It's also really changed how things like mentorship are done [0].
The problem I've had is the lack of any form of SSO. With all the events, FOSS projects, and actual organizations I'm up to 19 Slack accounts. Having to signup and create a new account almost every weekend is getting crazy.
I've used IRC a lot. For work and for projects. The experience is always horrible, and the clients always suck. We switched over to using slack for projects and for work and everything got instantly better. It takes seconds to setup and destroy places to chat that are private. It also takes seconds to search your entire history, on any device, and find what you talked about 3 weeks ago. Sharing code that doesn't get removed is amazing. It's a pain in the ass when the IRC client removes code and tells you nothing. I've sent entire messages to people which "get blocked" because the message is too long or contains code, and it never gives feedback.
I agree account creation in slack sucks though, and the author is correct that slack is not built for FOSS projects.
None of the problems listed seem like problems to me. All of the solutions that make IRC fill this role seem like they will require more work and time to set up than I am to put in just to get communication set up. Slack just works. So unless I am going to be working on something highly sensitive that I can't trust a third party reading about, I'm going to keep using it.
Wouldn't the best solution be to adapt one of the existing open source slack clients to use a local server? Then we have all of the feature set and none of the security and privacy concerns.
I understand the urge of certain people to fight Slack but if you think irc is a legitimate alternative, you probably don't understand the problem enough to offer a suggestion.
More credible alternatives would be Hipchat or Gitter but anyone who has used these two tools know that they are still way, way behind Slack in functionalities and user friendliness.
Slack is succeeding because it's a great tool.
Want to beat it? Create a better tool and people will migrate to it for its merits, not because it's open source.
We (sameroom.io) bridge channels/room in Slack, IRC, Gitter, and several other systems (about 14). It's a commercial venture, mainly aimed at helping large companies manage the lack of federation between team chat factions.
However, we do what we can to support open source and we'd be happy to provide sameroom functionality to open source projects. Please reach out on sameroom.io/contact to take us up on the offer.
Fact: IRC doen't persist chat messages on the server, so to view old messages you need to install a bot that provides you with the last n messages... and you have to manually query the bot for them. No thanks. Have you people heard of this thing called "mobile"? Spotty connections are the new normal. Having the last N messages autoloaded when I view a channel is a necessity.
I hear a lot of people talking about the problems with IRC, and I truly wish someone would enumerate them. It works great for our needs but I'm very curious the ways it isn't working for some.
We use a self hosted IRC server, along with an IRC bot written in Go for everything from automated deployments to chat logs to weather and traffic and bus schedules.
I run a large FOSS project; we use both Slack and IRC. Working with maintainers in 3 or 4 different timezones you can’t afford to lose your IRC session if you don’t want to miss messages. As pointed in the article however Slack is for teams, not communities. We use IRC for open discussions and keep internal discussions on Slack.
Some of the features mentioned here: persistent log, powerful search, comment editing, easy onboarding and invites, code blocks; some even ask for thousand of users in a chat room and moderation tools! Wouldn't this communities be better served by a modern forum, like Discourse instead of a chat?
I just also want to make the argument that github is a walled garden, so is google code. They're proprietary systems that we're able to use and take advantage of. I use github and I love it, but it can still have the same potential issues as slack.
I don't think that's true. GitHub is a frontend for the open git protocol. You can take your repositories and move somewhere else with next to no effort. Heck, almost all of my repositories exist in multiple situations.
All that being said, I've personally been doing more things on a private git server and less things on GitHub.
I think you would be better off using a full fledged forum. Then use a chat (IRC or whatever) on top of that for real time communication. Where the important stuff goes to the forum, and general talk in the chat.
Just wondering here can someone explain to me why campfire didn't move to fill the need of IRC/slack better? was it ever truly competitive in this space?
I hadn't even heard of Slack before this article, but definitely IRC. Perhaps it would be opposite for the newer generation?
IRC is also my preferred protocol for realtime messaging, for the reasons mentioned in the article and also the fact that it's extremely simple - you can even use it with nothing more than a network terminal like netcat. My second preference would be the older versions of MSNP (before they started stuffing XML into everything...)
Wouldn't Slack be ideal for FOSS projects? My fear would be of losing sensitive data when using Slack, but with a FOSS project this isn't an issue.
Slack is a tool, like a debugger or IDE, which aren't all open source.
If you are working on a government project with secret clearance, then these issues make sense. Otherwise, the article feels like it has more of a "whippersnapper" message.
I disagree with some of the things in this article (mainly that IRC is necessarily better for your company) but Slack isn't ideal for FOSS projects. It's a very long way from ideal.
Main reason being: Slack is a company and as such they can change their policy at any time. There isn't any specific right granting FOSS projects any status. Slack can ban the users they want, can deny access to accounts they want, they can be sold to other companies and can be bankrupted, bring it all crashing down.
Slack isn't a tool, it's a service. It's not in any way whatsoever like a debugger or IDE, even if those may be closed source. A tool is something you have and can use. You might not own its manufacturing but you own its potential use. Like a hammer you didn't make but is yours to do anything with. You can use it a million times if you want.
Slack is someone else's hammer that you pay to use. That's a service. The fact that they allowed you to use it for free for some undefined period of time doesn't mean you own it or dictate any rule of its use. It's still their hammer. They can stop you from using it at any point in time.
FOSS projects are supposed to be inclusive, open, transparent and fully decided by an owner or a community. Giving away control to a third party with no contract whatsoever is a terrible idea and a good way to break many of those premises.
Slack is being used for FOSS because of the failings of IRC noted by others in this thread, but that doesn't mean it's a good idea. Certainly not when the audience for Open Source is already very accustomed to IRC.
Slack is great for the turnkey solution it is, it offloads that IRC configuration you'd have to do, and it's easier to introduce non-technical people to. It's good for paying customers that have a clear contract with the company and as such gain certain rights. It's not, in any way, ideal for other cases. It might fit them, but it's not a great idea.
using irc on a daily basis, I wish it supports some basic tags such as <pre>, <code>, <img> and <video>, to make it more like a html chat IM...but anyway I like it and use it all the time.
Maybe by default, but given the author talks about the dozens of different bots available, logging the chat is a trivial thing to do, and most irc clients automatically log.
In the case of linode, (at least back in the day I remember) they automatically post those online for anyone to search in case you could learn something from someone else asking questions in their irc channel.
IRC and mailing lists and forums is pretty much were open source communities live and work together for several decades.
Competitors want to reach out to such communities and vendor lock-in them. Nothing new, had been tried before with MSN Messenger, AIM, Skype videochat, etc. though IRC will hopefully stay about such waves and fades - it's a rather simple protocol, has a good file transfer mechanism and thousands of native, it cannot be censored (words filtered) and web clients for every platform and needs (incl bots).
I was also curious about this. As the article mentions, Slack doesn't make it easy for your organization to allow open registration. People have developed hacks around this by running a server on Heroku [0], or using Typeform combined with Slack's API [1].
I agree Slack is a poor fit for this. But god, using Slack makes it painfully obvious how shitty IRC is. I almost wish people would stop mentioning them together. I hate IRC and I have since the 90s, it's just bad.
>That the reasoning is fallacious doesn't make the conclusion incorrect.
This is trivially true by the [material implication, modus ponens, modus tollens, other name, etc] truth table. However, if you study the truth table a bit longer, you will realize that you should stop reading any text which contains fallacious or self-contradictory logic. While the conclusion may be "correct", it is correct despite all of the other text you read (so, go find a logical argument [instead of relying on known bad information]). The text you read can tell you nothing about whether the conclusion is true.
Fallacious reasoning needs to be identified, targeted, and destroyed.
Edit: I've been rate-limited, so any fallacious (or non) arguments posted in response will need to wait a while for a proper response (some have already been typed up).
For HN purposes, an egotistical spat is not on any topic.
If you want to keep commenting here, you need to err on the side of following the HN guidelines rather than breaking them. Your account has a long pattern of breaking them, and of straddling them when not breaking them outright. That's not the discourse we want here.
If you can show me the ego, I will concede to being off-topic.
I reject any notion that I have ever intentionally broken a guideline. I also reject any notion that I have a pattern of repeatedly breaking any actual guideline.
Indeed. So if someone doesn't actually make a claim, but then another party begins to rebut said claim as if it were part of a formal argument, that's called a Straw Man Argument or "Burning a straw man" colloquially.
That's what you're doing. We should identify it, target it, and destroy it.
Actually I don't really think that it should be destroyed. It's human nature. We find any post-facto justifications for our gut reactions all the time. If we can't find one, we tend to distort what we saw to create one. It's part of human cognition.
It should be logically destroyed; the full path of destruction should be visible to all though.
You have claimed a Straw Man, but in my 20 second analysis, I do not believe you have identified it. (as in, quote the actual text containing the Straw Man)
I am terribly sorry I missed your request. I've been busy tending to my daughter and hastily dashing out some code I need for a teaching opportunity next week. I can see it caused you enough distress to post twice.
Let me be straightforward with you, since you seem to be the sort that will not appreciate the standard cultural niceties.
So perhaps maybe you just did a poor job to express your specific point as you tripped over yourself to demonstrate to everyone you have read a bit of philosophy and logic. But it certainly would be reasonable that you entered a conversation without invitation responding to
> That the reasoning is fallacious doesn't make the conclusion incorrect.
With:
> However, if you study the truth table a bit longer, you will realize that you should stop reading any text which contains fallacious or self-contradictory logic.
Implying that if you could construe any single statement in my post as lacking in robustness from a logical perspective, then you should simply ignore the entire thing. This is regardless of the author's intent that this actually be a real point, or perhaps just a literary device or joke. One might actually read the whole post first, notice there is some technical substance, and come to a different conclusion before posting.
This impression is further reinforced by your frustration over rate limiting as you implied that my response, specifically saying that I didn't actually present my tautology as anything but a cute literary device to open what I considered to be a rather dry if somewhat acidic post.
You said,
> I've been rate-limited, so any fallacious (or non) arguments posted in response will need to wait a while for a proper response (some have already been typed up).
Which from my perspective certainly looks like you were ready to fire off a post explaining to me with as many latin words as possible aimed at trying to prove exactly that.
Perhaps, in the future, you may want to consider efficacy first and strict correctness secondly when discussing things in a casual forum with the (entirely barbaric, I agree) feature of "downvoting." Or perhaps just not entering conversations you don't have anything substantial to add to.
You might feel some irritation at this, because it can seem like an anti-intellectual stance. Sadly, you're existing in a community that has to deal with many people perpetually misusing terms like "ad hominem" and "genetic fallacy" and "truth table" in the worst way, to the point where it's a cognitive shortcut to simply pass it by or perhaps even express this cultural signal via downvotes.
I don't like it very much either, but cultural norms are not something we rationally argue with but instead can only hope to influence gradually.
Sorry, HN doesn't provide the clearest interface for communication.
My last two posts were specifically referring to the people who were downmodding me without posting any specifics. Unless HN hands out additional powers, which I have not been granted, you cannot downmod my responses to you. I did not mean to rush you (nor were my two parent posts in any way directed at you).
I will read your post now.
Edit: And likely post edit this post with responses.
>I can see it caused you enough distress to post twice.
I hope I was clear before, but I feel the need to state it clearly: you have not distressed me.
------------
Ok, many points are not relevant, but I'll respond.
>Let me be straightforward with you, since you seem to be the sort that will not appreciate the standard cultural niceties.
Thank you.
>So perhaps maybe you just did a poor job to express your specific point as you tripped over yourself to demonstrate to everyone you have read a bit of philosophy and logic.
I am waiting for the Straw Man.
> But it certainly would be reasonable that you entered a conversation without invitation responding to
No invitation required here.
>> That the reasoning is fallacious doesn't make the conclusion incorrect.
This actually depends on the conclusion. It depends on how all the words are defined, but basically, people come to non-real conclusions all the time.
>With:
>> However, if you study the truth table a bit longer, you will realize that you should stop reading any text which contains fallacious or self-contradictory logic.
>Implying that if you could construe any single statement in my post as lacking in robustness from a logical perspective, then you should simply ignore the entire thing.
My response was not directed at you. No, seriously. Go check the post history.
Also, that is basically the implication. And it's basically true. It's pretty much what you should do. Of course, there are many reasons not too: historical, curiosity, "maybe I read it wrong", etc. However, according the the rule of logic: there is no reason to consider fallacious logic in regards to any particular conclusion.
>This is regardless of the author's intent that this actually be a real point, or perhaps just a literary device or joke. One might actually read the whole post first, notice there is some technical substance, and come to a different conclusion before posting.
Fallacies should be called out as soon as they are detected. Consider the alternative: you are operating on fallacious logic. Good luck!
>This impression is further reinforced by your frustration over rate limiting as you implied that my response,
Again, my apologies for the confusion, but those frustrations were not directed at you, nor were/are they about you. You seem like a mostly pleasant person. (seriously)
>specifically saying that I didn't actually present my tautology as anything but a cute literary device to open what I considered to be a rather dry if somewhat acidic post.
And, yes. The Straw Man has not been presented (in my ~20min analysis).
>You said,
>> I've been rate-limited, so any fallacious (or non) arguments posted in response will need to wait a while for a proper response (some have already been typed up).
>Which from my perspective certainly looks like you were ready to fire off a post explaining to me with as many latin words as possible aimed at trying to prove exactly that.
The response I gave you is what I wrote up immediately before receiving the rate limit notice. I just kept the tab open and tried to post it every so often. I may have edited slightly after the first post attempt. I'd go read my response, then read the post the response was for, then come back here and read the above excerpt from your post.
>Perhaps, in the future, you may want to consider efficacy first and strict correctness secondly when discussing things in a casual forum with the (entirely barbaric, I agree) feature of "downvoting."
Please consider in any future encounters with me that I have already considered such concerns. Efficacy without correctness is madness. I cannot guarantee that I have considered all concerns, however.
>Or perhaps just not entering conversations you don't have anything substantial to add to.
I'm not not sure what this means. I don't consider posting a response on HN to be "entering conversations". It's some text in a tree, people can read it or not.
>You might feel some irritation at this, because it can seem like an anti-intellectual stance. Sadly, you're existing in a community that has to deal with many people perpetually misusing terms like "ad hominem" and "genetic fallacy" and "truth table" in the worst way, to the point where it's a cognitive shortcut to simply pass it by or perhaps even express this cultural signal via downvotes.
I don't like it very much either, but cultural norms are not something we rationally argue with but instead can only hope to influence gradually.
I just try to point out the flaws as I see them. I'm not sure anyone else can do better.
No value for me either if you claim a Straw Man [if you are reading this, and are wondering "wtf is this person talking about?", please, please, go back and read this full thread (although, that has been made more difficult by the overzealous moderators on this site)], but are unable to produce one after many words.
Edit: I also don't see the immediate relevance of your post to my specific rebuttals of your prior points. Want to go in-line?
I call FUD. Something to the effect of "Please people, don't drive cars, they are not FOSS".
My company pays for Slack and we get a ton of value from it. Kthxbai!
This seems to be similar to the argument of "don't use Github or Bitbucket, use your own hosted Gitlab". Some of the complaints are a bit petty (really, an extra browser tab per project is a burden?)
IRC is better for occasional participants that wish to remain anonymous and/or use less screen real estate, but Slack is generally a better experience for regulars and way less hassle than hosting your own server/bots. Ymmv
Fair. My point is that you have a fairly unique set of requirements, such that there is a tradeoff in tooling to cater to part-time/open contributors vs. a core/extended team doing active engineering.
You bring up some reasonable points, even though I disagree with asking teams to not use Slack (as I vastly prefer it to IRC these days, but I am focused on open source collaboration with active engineering teams). I think a compromise would be for teams that want open contribution or a chat support channel to turn on Slack's IRC gateway.
No, it's more like "don't use BitKeeper, use CVS."
My first experience with IRC was 1994, I believe. I get IRC. However, slack has been a better experience. The biggest advantage has been persistent history and search for any member of a slack team. A new employee should have access to a conversation from a year ago.
I used IRC every day for 15 years from high school through work. This is akin to saying having a different tab for each IRC SERVER (not channel) is a burden. I personally prefer having separate tabs for each project, but ymmv.
I mean, you're not limited to one browser window. Having one browser window for just Slack is like having a mIRC window for all the IRC channels you're in.
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.