Agreed, but with that said... IRC has serious issues, and dancing around them or pretending they're not there is not helping. I talk a bit about them here:
The reason Slack exists and can be so successful yet entirely proprietary is a symptom that IRC is not good enough and that has to be fixed. It is the manifestation of the papercuts we, IRC users, have been having for a long time now. (late edit: If you are interested in fixing this problem, email me, see my profile.)
There are very promising efforts on IRCv3 (http://ircv3.net/) ongoing. I hope they eventually go live to the bigger clients and networks so that we may actually have a good foss alternative to slack (and I don't mean something like Mattermost. Like SirCmpwn said some comments below, having one browser tab per project REALLY SUCKS when you contribute to a lot of projects. I'm in over 20 channels myself, and I do my best to keep that number low...).
I really resonate with this position. IRC is open source and it has had problems FOR DECADES. IM programs from third parties add genuinely useful features which people clearly want. So rather than call for a general boycott of Slack (a negative approach) why not call to fix IRC?
IRC is just a well-established and battle-tested server/client protocol. I'm eager for the day when a competing open source server/client protocol emerges and takes over. I imagine all it would take is a really good reference implementation server and client that everyone can just start using, right?
It's a well-established shitty protocol, largely designed in the early 1990s as the simplest thing that could possibly work for the workloads we had in the early 1990s. It's terribly limited (7 bit, small message sizes, virtually no useful metadata) and in the 98% use case, its "distributed" characteristics cause more problems than they solve.
No competent person setting out to design a group communications protocol in 2015 could honestly say they'd use IRC as a starting point.
Mostly correct, but one nit to pick: IRC is not 7-bit; you can actually transmit unicode messages on every IRC network I've ever seen. It's also not usually unicode-aware, though, so if you send a message too long, it might get truncated halfway through a codepoint. Many IRC networks prohibit non-ASCII channel names and nicknames to prevent impersonation (e.g. with zero-width spaces).
IRC messages have CRLF message delimiters (and ASCII space field delimiters) and no quoting mechanism in the protocol. They're delivered over a long-lived synchronized TCP stream. Does it just happen that no 8-bit sequence people normally want to send on IRC ever manages to collide with 0D:0Ah?
I haven't seen unicode messages on IRC channels, but I don't spend much time on IRC anymore, and so this is interesting new information for me --- but there's more to being 8-bit clean than simply supporting internationalized character sets.
> Does it just happen that no 8-bit sequence people normally want to send on IRC ever manages to collide with 0D:0Ah
This is not possible on a technical level, having nothing to do with IRC itself, but instead written into the encoding design of UTF8.
First of all "7 bit" physical communication never really existed in the age of TCP - the protocol has always moved 8 bits at a time around. The "7 bit" era refers to nobody actually agreeing what codepoints within x80 ~ xFF actually mean. This is even partially true today - not everything has agreed on speaking UTF8 (hi Win32 APIs).
On the actual point of why neither 0x0D nor 0x0A will ever "manage to collide".
In a single-byte encoding (called codepages, https://en.wikipedia.org/wiki/Code_page#Noteworthy_code_page...) 0x0D always means just that, as pretty much all ASCII-derived codepages do... well, respect ASCII ( note - this does not touch on the horror of EBCDIC, which is alive and well today (2015) too ).
In the case of UTF8 any continuation byte can only carry values in the range of \x80 ~ \xBF, and any leading byte can carry values in the range \xC0 ~ \xF7. So no matter how you slice and dice things, the resulting UTF8 will have every ASCII character meaning itself (this includex \x0D and \x0A ), and the only ambiguity when mistakenly treated as any single-byte encoding would be in the "what do we do with the upper 7bit range" part ( \x80 ~ \xFF ). More info here: https://en.wikipedia.org/wiki/UTF-8#Description
True, other multibyte encodings are not so convenient: for example \N{MALAYALAM LETTER UU} ( http://graphemica.com/%E0%B4%8A ) looks really bad CRLF-wise in both UTF16/UCS2 an UTF32.
But this is why UTF8 "won" for all intents and purposes. And this is also why "escaping" is not necessary under virtually any modern environment, so IRC lacking any such mechanism is not really relevant.
( No opinion worth sharing on the rest of the article/discussion ;)
I certainly think having an open source reference implementation for a 21st century (and by that I mean having features like Slack or Yammer or other popular closed source packages) implementation of a successor to IRC would be the minimum starting point.
From what I've been able to gather, the open project that is most like Slack, but also offers self-host, decentralization is Matrix:
http://www.matrix.org/
There's also Zulip, which as far as I can gather, is battle-tested, but does not have a strong story for federated servers, nor a good out-of-box experience for really small servers:
https://github.com/zulip/zulip
Finnaly there's https://tox.chat -- which doesn't have a lot of the things IRC/Slack has (it's focused around p2p chat) -- but extensions are planned, for eg. persistent group chat. Perhaps most excitingly "new" of the three, which predictably is both a good and a bad thing:
https://wiki.tox.chat/users/faq#what_is_tox
For those that "want Slack", but self-hosted, open/free software server -- I think Matrix is the most viable alternative -- if IRC is seen as not good enough.
I've not included any XMPP servers, although eg. Prosody should be simple to set up and use -- because, apparently like IRC, it has too many problems for people to actually embrace out-of-the box XMPP for team chat. The fact that most big public services that host XMPP tend to favour anonymity probably has something to do with the fact that getting reliable server-side message logging and off-line messaging is still not as easy as one would expect, for any(?) of the big free XMMP daemons (or indeed support client side).
Actually, bridging is actually a first class citizen in Matrix - it's why the project's called Matrix (as we want to go federate/matrix together all the existing silos out there). Current bridges include:
...and a whole bunch of 3rd party ones too like https://github.com/SkaveRat/xmpptrix. Some of these are pretty beta, but they're all headed in the right direction. The IRC and Slack ones are the most mature.
Glad to hear that you think we are on the right track! [Disclaimer; i work on Matrix]
IRC lacks a viable attached business model. In fact the act of writing robust services that empower users with data portability and privacy does not appear to have a sustainable model at all currently. I don't know if the current situation is a transitory phase or if this is how large systems will be built in perpetuity.
By "battle-tested" I meant it has lots of patches/updates to the protocol to protect against certain kinds of attacks. Any new protocol would have to go through the same "battle-testing" before it would be reliable enough.
What is wrong with Mattermost? I've never actually used it, but it seems like a better OSS slack competitor than irc. If it really is just the problem of 1 project per tab, surely fixing that minor issue is easier than a whole new IRC spec?
It's the other way around: Mattermost has a ridiculously small userbase, compared to IRC. IRCv3 is compatible with IRC2.1. It's a lot easier to extend the IRC spec than it is to write competing software.
irccloud.com (disclaimer: I'm a subscriber) addresses a number of the deficiencies of standard IRC.
A lot of the other deficiencies are a consequence of any decentralized, open resource, due to "tragedy of the commons" effects. Those will always require active admin participation to resolve.
Freenode sometimes does get a lot of abuse, which is a shame. Some networks definitely do have better anti-spam and anti-botnet functionality, but I don't think most users ever even notice this. Even on Freenode, most channels will go without problems like botnets or channel takeovers for most or all of their life.
If you're running your own irc server, you'll probably never notice anything. If you do, it's as simple as adding a server password (or maybe even changing the default port among some other settings), and anything unwanted will likely be a thing of the past (assuming you don't have dedicated people attacking you).
On your comment about IRC bots and services, networks don't see that as something that is up to them. If something requires a U:line or other network privileges, then it's up to the network staff to implement that, sure, but anything else is for their users to do. If IRC networks were for-profit, maybe you could expect them to have things like this and advertise how amazing all of their features are to potential clients. But IRC is nothing but a money sink for everyone involved, and there's therefore often little incentive for networks to implement and integrate a lot of bots and functionality that aren't integral to network operation.
Apart from this, spam is a really hard problem if there are resourceful people dedicated to it. Email has existed for even longer than IRC, and despite absurd amounts of work into anti-spam systems and functionality with it, it's not too surprising when spam manages to finds its way into your mailbox.
I still agree there's a lot of room for improvement, both at the protocol level and at the user level, though.
is there a way for me to, instead of using a server password, use something like OAuth so that I can grant access to the server based on my companies central login database? otherwise, every time someone leaves the project, we have to rotate the server password...
I don't see why it wouldn't be possible, however, using OAuth would probably need some nice integration on client side you'd have to provide. Maybe just login to the server using your credentials and authenticate via LDAP?
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...).