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 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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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...)
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?
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.
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 ;)
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?
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.
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.
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).
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.
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.
> 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 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.
> 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 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!
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.
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.
> 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....
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.
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.
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.
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.
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!
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.
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.
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...
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?
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'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.
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 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.
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 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).
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 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.
498 comments
[ 3.2 ms ] story [ 350 ms ] threadAdditionally for iOS users, there's a push notification client available for ZNC, which is pretty handy.
[1]: http://irccloud.com
IMO Shout is a UI improvement over Slack for the sheer fact that it is 100% customizable.
Pretty nice though.
Absolutely nothing. Nothing has stopped anyone from making a fully featured IRC client with good UX. Yet there still isn't one.
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.
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.
I love IRC and grew up with it. But don't compare it to Slack for technical knowledge requirement.
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.
Use SSL + SASL auth and it's not any less secure than logging in to most websites.
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 :)
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...
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.
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.
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.
I sort of get why people like Slack. It's very low effort. But that's the only advantage I see.
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
It is, actually. I contribute to dozens of open source projects, and I am joined to hundreds of IRC channels.
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.
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.
Spoken like someone who has never been a serious IRC user.
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.
Does slack do that for you?
I haven't used Slack's Gateway feature [1] but it seems Slack does allow you to connect with standard IRC and XMPP protocols.
[1]: https://slack.zendesk.com/hc/en-us/articles/201727913-Connec...
https://slack.com/pricing https://www.irccloud.com/pricing
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.
- File transfers and snippets are not so essential, but they make working simpler
- You can connect to slack using IRC or XMPP https://slack.zendesk.com/hc/en-us/articles/201727913-Connec...
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).
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...)
We have learned absolutely nothing. Let's all jump on the bandwagon of another closed-source, proprietary, walled-garden service and hand over all of our private intra-company communications to a private third-party in another country. GREAT IDEA.
https://plus.google.com/u/0/+JeromeLeclanche/posts/icC6gDToB...
The reason Slack exists and can be so successful yet entirely proprietary is a symptom that IRC is not good enough and that has to be fixed. It is the manifestation of the papercuts we, IRC users, have been having for a long time now. (late edit: If you are interested in fixing this problem, email me, see my profile.)
There are very promising efforts on IRCv3 (http://ircv3.net/) ongoing. I hope they eventually go live to the bigger clients and networks so that we may actually have a good foss alternative to slack (and I don't mean something like Mattermost. Like SirCmpwn said some comments below, having one browser tab per project REALLY SUCKS when you contribute to a lot of projects. I'm in over 20 channels myself, and I do my best to keep that number low...).
http://ircv3.net/
They need help, go check them out.
https://robustirc.net/
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).
[ed: Matrix also have some support through bots/plugins for IRC bridging: https://github.com/matrix-org/matrix-appservice-irc ]
* IRC (https://github.com/matrix-org/matrix-appservice-irc)
* Slack (https://github.com/matrix-org/matrix-appservice-slack)
* Verto (https://github.com/matrix-org/matrix-appservice-verto) (for talking VoIP with FreeSWITCHes)
* Respoke (https://github.com/matrix-org/matrix-appservice-respoke) (for talking VoIP with Asterisks)
* Purple (https://github.com/matrix-org/node-purple/tree/master/appser...) (for talking through to Skype, Facebook, XMPP, ICQ, AIM... and anything else that libpurple supports)
...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]
Every time it loses another user to a proprietary platform, it loses another battle. Is that what "battle-tested" means?
No competent person setting out to design a group communications protocol in 2015 could honestly say they'd use IRC as a starting point.
The rest of what you've said is pretty much true.
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.
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 ;)
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...
A lot of the other deficiencies are a consequence of any decentralized, open resource, due to "tragedy of the commons" effects. Those will always require active admin participation to resolve.
If you 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).
The article does not even discuss the fact that projects that opened a slack community with a big increase in their audience. Apparently audience is much less important than purity.
I 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 :)
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.
Technology isn't easy. Pretending it should be causes problems.
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.
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.
https://slack.zendesk.com/hc/en-us/articles/201727913-Connec...
For everything else, including at work, I/we use privately hosted solutions like GitLab, where we control our own data.
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.
So don't use AWS or Google App Engine or Heroku? etc. Why?
I use Facebook for a lot of my communications. Seems to be working out OK so far.
Use the tools that help you get your work done efficiently. Consider the long-term consequences, of course, but if someone took all of my Slack team messages and told me I couldn't have them back, I'd be annoyed but it wouldn't affect my productivity much.
OTOH, losing the ability to coordinate via Slack, as you're suggesting, would certainly lower my productivity.
Leaving aside that there are extremely valid reasons not to use those services, communication is a huge deal. Can you imagine if email was a walled garden?
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.
I really don't get this, 99% of the stuff you use everyday is closed-source and proprietary. Most often the tradeoff in something bad happening (which has yet to be with Slack) versus having a functional and productive system is more than worth it.
Or do you also build your own computer from raw silicon and communicate with pirated radio signals?
This is Hacker News; I expect the average to be around 20%
If some basic programming chat about an open source project isn't safe then we should all throw away our phones and turn off the internet immediately, but I don't see that happening. This is basically bikeshedding on how to run open source projects.
Well said, I chuckled. Let me just add something...
If you want a paper trail of anything, use an email you own.
I have a friend who was locked out of a startup's Slack right before he was due to be paid for three months of work. He had been discussing business inside of Slack, and instantly lost access to all of those messages.
Could this have happened if the startup used a private email server, or a private IRC server? Of course. But if they were using more open protocols, he would have at least been able to back up the messages. Slack provides an easy tool for backups to admins, but not for normal team members. Slack provides an API for all users, but team admins can disable the API. Slack also allows team members to connect over IRC and XMPP, if team admins turn on that feature (https://slack.zendesk.com/hc/en-us/articles/201727913-Connec...).
Slack is great, I love using it. Just remember who owns the data. Always use your own personal email if you want to create a papertrail, as my friend found out.
I think your argument is somewhat null....
Previous discussion on this: https://news.ycombinator.com/item?id=10280611
Replace svn by irc and bitkeeper with slack. Figure out the rest.
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.
Instead of using slack, use IRC Cloud.
http://ircv3.net/
1. Have a bot that's in the channel from the start
2. cd into the bot's log directory and type python -m SimpleHTTPServer
3. put the url into the channel topic
How do some developers fail to rise up to this level of problem solving? I am amazed.
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.
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.
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.
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?
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!
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.
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.
I’ve done exactly that.
Should this end up in a separate wiki? Maybe. Will it? Not always.
At which point I got tired of whitelisting people instead, after abuse issues compelled me to disable anonymous access...
(I'm one of the Zulip maintainers; happy to answer any questions about it).
Less importantly: What would you say its biggest missing feature is vs Slack? And conversely what does it bring to the table that Slack can't touch yet?
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.
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.
Are there any plans to support multiple teams / multiple servers from the native client? This is a particularly acute pain point on mobile; I'm reluctant to promote any tool that requires me to be logged in to only one project's instance of the tool at a time, because if it works well, it gets adopted for other projects, and then I'm having to juggle clients. I am unfortunately on two projects that use HipChat, and even there it's a huge pain that I can't be logged in to both simultaneously on my phone. (Some of their desktop apps finally support multiteam which is a huge help, but I still have to pick just one to participate in on mobile..)
Slack isn't perfect, but at least all the native clients will let me be logged in to 5 teams at the same time. (And no, opening multiple browser tabs is not an appropriate solution - it doesn't work at all on iOS, for example.) And obviously, this is something IRC does a great job of as well.
First, let me say that I'm really happy zulip was opened up, and grateful for you and your team to support it.
But does Zulip support server federation? Obviously slack doesn't allow self-host, so if slack is the alternative, that doesn't really make much of a difference. But that is one feature that http://matrix.org/ does support.
It's incredibly intuitive because it's so similar to all the other chat clients we grew up with (presumably because they're based on IRC).
Sure, figuring out bouncers and build bots is a little tricky at first, but so what? That's the fun part. It's kinda fun digging into the IRC protocol and figuring out how it works.
And ok, if that's not fun for you, there are plenty of really "click and install" tools for you (e.g. ZNC is super easy to setup).
Not to sound like an elitist prick, but if you can't figure out how to setup an IRC bouncer, I'm not sure I really trust you contributing to the linux kernel, yaknow?
Reducing friction is great: But the kind of friction we should be trying to reduce is bureaucratic friction. Throwing out PRs and yelling at people because they forgot to cc some particular maintainer - that's the kind of friction that sucks. Having to setup an IRC bouncer? Idk, I think that's fine.
And just because someone doesn't want to spend the time fiddling with IRC bouncers, IRC bots, getting clients to display things nicely doesn't mean that they are a bad developer. Just that they have different priorities for their time than you.
I'm not saying that Slack is perfect or frictionless, but neither is IRC. And especially if you don't do it all the time, getting people set up to work with Slack is way easier than IRC.
I really find these discussions half amusing and half depressing. 2 sides have something that is "good enough", both insist that nearly all you want can be solved with their solution, especially if you just do X1,X2,X3,Y1,Y5, and Z4 and you technically could build something that is perfect for both on top: but sadly (and understandably) no-one actually cares enough to do so. Because what they have is "good enough"(TM).
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 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.
Some great tools for software development:
* Microsoft * OS X * Linux * Free BSD
To some degree that represents a spectrum and I don't fault the author for having strong beliefs about how software should be built, and agree with them for the most part. I think he could have made a stronger point generally from a philosophical and technical angle, i.e the regular arguments for open source tools, and highlight Slack as an example.
IRC is quite similar to Slack, but for the reasons the author suggests, it is different.
tl;dr Stallman wouldn't use Slack.
Frankly, it boils down to that I just don't like it. I'm more interested in getting better at programming, or learning about containers, or some other useful thing, than trying to figure out IRC's odd interface. Chat isn't something I should have to think about. It should just work.
So, I agree with most of what @vonklaus said, and disagree with the links pro-irc stance.
I've never used Slack, so I have no opinion on it.
(It probably helps that a lot of in-game chat interfaces use a lot of these same commands, as I'm a gamer as well as a programmer.)
There's a pretty nice web interface to IRC called irccloud.com which also persists your connection (so you can simply log onto irccloud.com somewhere else, and entire history is preserved).
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.e. does IRC or any IRC client support sent, received, read confirmation the way that What'sApp or Google Hangouts reports this information?
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.