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.
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.
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...).
> 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.
> 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.
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.
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).
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?
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 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).
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.
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.
> 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.)
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!
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.
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.
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.
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.
[+] [-] KirinDave|10 years ago|reply
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.
[+] [-] orofino|10 years ago|reply
1. Slack is a well-designed interface for allowing teams to communicate via chat.
2. Slack is easy to install is use on Mac, PC, iOS, and Android. It Just Works™.
3. Slack doesn't require me to install IRC somewhere. Which also means I don't have to worry about how people gain connectivity to said server when outside the office.
4. Slack has whimsy. Fun colors, messaging, emoticon, bots, etc.
All of this is what folks in this thread seem to be missing. I've used IRC for a very long time, but have NEVER been successful at getting wide adoption of IRC for communication.
I am well aware that I'm trusting a third party with out information. I'm aware that alternatives exist and you can get them to work. That doesn't matter when I have to try to explain to my CEO how to /join #channel.
There is a reason why IRC, a widely-available, chat solution that has been available for decades didn't catch on. It has nothing to do with how well the software moves messages from one computer to another.
</rant>
[+] [-] emergentcypher|10 years ago|reply
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.
[+] [-] scrollaway|10 years ago|reply
https://plus.google.com/u/0/+JeromeLeclanche/posts/icC6gDToB...
The reason Slack exists and can be so successful yet entirely proprietary is a symptom that IRC is not good enough and that has to be fixed. It is the manifestation of the papercuts we, IRC users, have been having for a long time now. (late edit: If you are interested in fixing this problem, email me, see my profile.)
There are very promising efforts on IRCv3 (http://ircv3.net/) ongoing. I hope they eventually go live to the bigger clients and networks so that we may actually have a good foss alternative to slack (and I don't mean something like Mattermost. Like SirCmpwn said some comments below, having one browser tab per project REALLY SUCKS when you contribute to a lot of projects. I'm in over 20 channels myself, and I do my best to keep that number low...).
[+] [-] ChrisAntaki|10 years ago|reply
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.
[+] [-] randomsearch|10 years ago|reply
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.
[+] [-] smtddr|10 years ago|reply
http://www.tricksofthetrades.net/2015/09/10/slack-irssi-conn...
I feel like that has to diminish the walled-garden, proprietary weight at least a little bit if slack & irssi can communicate. And it works over SSL too. Once I started doing that, I didn't mind using slack. You have to "/ignore" certain server messages though or your whole screen will be spammed with them and you'll barely see the stuff people are saying.
[+] [-] jgalt212|10 years ago|reply
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.
[+] [-] Sanddancer|10 years ago|reply
[+] [-] enraged_camel|10 years ago|reply
[+] [-] ve55|10 years ago|reply
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).
[+] [-] JustSomeNobody|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] manigandham|10 years ago|reply
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?
[+] [-] ash|10 years ago|reply
* Rocket.Chat (https://rocket.chat/)
* Zulip (https://zulip.org/)
* Mattermost (http://www.mattermost.org/)
* Let's Chat (http://sdelements.github.io/lets-chat/)
Oh, and by the way, you could have your own Rocket.Chat instance running in Sandstorm in about 30 seconds: https://sandstorm.io/apps
Update. And I would love to see a modern federated chat protocol to take off. Something like http://matrix.org/.
[+] [-] briandear|10 years ago|reply
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.
[+] [-] Drdrdrq|10 years ago|reply
Don't know others yet, thanks for the list.
[+] [-] zeckalpha|10 years ago|reply
XMPP?
[+] [-] marceloschmidt|10 years ago|reply
[+] [-] lectrick|10 years ago|reply
[+] [-] vonklaus|10 years ago|reply
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.
[+] [-] tabbott|10 years ago|reply
(I'm one of the Zulip maintainers; happy to answer any questions about it).
[+] [-] Uptrenda|10 years ago|reply
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.
[+] [-] tptacek|10 years ago|reply
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.
[+] [-] jedberg|10 years ago|reply
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.
[+] [-] netcan|10 years ago|reply
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.
[+] [-] randomsearch|10 years ago|reply
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".
[+] [-] Arathorn|10 years ago|reply
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.
[Disclaimer: I work on Matrix.org]
[+] [-] zanny|10 years ago|reply
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?
[+] [-] scrollaway|10 years ago|reply
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.)
[+] [-] upofadown|10 years ago|reply
[+] [-] munchor|10 years ago|reply
[1]: http://irccloud.com
[+] [-] peterjmag|10 years ago|reply
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.
[1] https://facebook.github.io/react/blog/2015/10/19/reactiflux-...
[2] https://github.com/reactiflux/volunteers/issues/25
[3] https://twitter.com/discordapp/status/648379244570013696
[+] [-] vjeux|10 years ago|reply
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!
[+] [-] mshenfield|10 years ago|reply
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.
[1] http://www.mattermost.org/ [2] https://www.zulip.org/ [3] https://gitter.im/
[+] [-] d0m|10 years ago|reply
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.
[+] [-] chipotle_coyote|10 years ago|reply
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.
[+] [-] mikeash|10 years ago|reply
I sort of get why people like Slack. It's very low effort. But that's the only advantage I see.
[+] [-] tw04|10 years ago|reply
[+] [-] userbinator|10 years ago|reply
Really? Does using Slack not require opening a client application and logging in, like just about every other realtime messaging platform?
I know many "non-technical" people who use IRC.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] vezzy-fnord|10 years ago|reply
[+] [-] synthmeat|10 years ago|reply
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.
[+] [-] heavenlyhash|10 years ago|reply
- Open! Free on both the beer|culture axis!
- 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.
---
[1] https://matrix.org | https://vector.im
[2] https://news.ycombinator.com/item?id=9772968
[+] [-] rrix|10 years ago|reply
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.
[+] [-] sandGorgon|10 years ago|reply
[+] [-] spankalee|10 years ago|reply
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.
[+] [-] tolmasky|10 years ago|reply
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.
[+] [-] bobbygoodlatte|10 years ago|reply
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.
[+] [-] e12e|10 years ago|reply
And there are clones, like lobste.rs:
https://github.com/jcs/lobsters
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.