
Please don't use Slack for FOSS projects - ddevault
https://drewdevault.com/2015/11/01/Please-stop-using-slack.html
======
KirinDave
If IRC were good enough to handle the needs of small software company
communication, _people would use IRC_. Sitting here pretending everyone just
doesn't know about a 20+ year old technology is comical.

The "IRC Features" section bugs me, too. Unless you run a private IRC server
IRC has a long, tortured history of design-based security difficulties. Gone
are the days of netsplits permanently owning channels, but the so called
"distributed" design of IRC makes it very brittle and easy to deny service.

Oh, and did you know that with modest, low volume channels (>200 <1000, some
networks tolerate more) you can make IRC networks struggle? Turns out that
their lousy distributed design hurts more than helps when single channels get
heavy.

Slack also offers a logging service that, for what it's worth, is configured
correctly and secured by default. For organizations with 1-3 technical staff,
maintaining and securing a reasonable approximation of Slack's feature is
probably time better spent working on your product.

IRC is a classic example of the "it's broke but we don't fix it because it's
familiar" mentality of old school services. While it may be a good choice for
running low-volume (<500 users) public communication. Most tooling around it
is woefully inadequate and often tedious to use for small software-oriented
teams where Slack thrives.

But if you're genuinely concerned about security, HipChat will sell you a
whitelabel product you can host and monitor and its setup is quite good for
what it is.

~~~
mbillie1
> If IRC were good enough to handle the needs of small software company
> communication, people would use IRC. Sitting here pretending everyone just
> doesn't know about a 20+ year old technology is comical.

I'd just like to point out that this argument ("if <x> were so great, everyone
would already use/do <x>") is just a slightly different form of the ancient
appeal to popularity argument and is entirely fallacious.

~~~
spdustin
Respectfully, I disagree. In many cases, things are popular because they are
better/easier for a given audience. I'm a smart guy, have managed (and
continue to manage) many, many UNIX-based services, and have run several IRC
daemons in my life.

I still use Slack for internal use, and for our students.

What makes Slack (and its ilk, though the title of the post makes a bias
against Slack clear) so great is that it's simple, easy, full-featured and has
a low barrier to entry to the non-HN crowd that is being asked, in many cases,
to use it.

I can promise you, out of experience and out of just plain statistics, that
Slack and IRC have different audiences, and those audiences will not likely
prefer the other.

Also, I'd guess that IRC is actually the more popular choice. But the majority
of the IRC using audience is too busy getting work done in IRC to comment on
an HN post.

~~~
tptacek
I don't think you're going to find evidence for the argument that IRC is more
popular than Slack. IRC's user base is declining, Slack's is growing, and the
numbers we have now suggest that Slack is already much more popular.

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

Freenode isn't the only network out there =)

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

~~~
Killswitch
But decentralized is the best thing ever!

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

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

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

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

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

------
orofino
Allow me to shout into the void for a minute here...

1\. Slack is a well-designed interface for allowing teams to communicate via
chat.

2\. Slack is easy to install is use on Mac, PC, iOS, and Android. It Just
Works™.

3\. Slack doesn't require me to install IRC somewhere. Which also means I
don't have to worry about how people gain connectivity to said server when
outside the office.

4\. Slack has whimsy. Fun colors, messaging, emoticon, bots, etc.

All of this is what folks in this thread seem to be missing. I've used IRC for
a very long time, but have NEVER been successful at getting wide adoption of
IRC for communication.

I am well aware that I'm trusting a third party with out information. I'm
aware that alternatives exist and you can get them to work. That doesn't
matter when I have to try to explain to my CEO how to /join #channel.

There is a reason why IRC, a widely-available, chat solution that has been
available for decades didn't catch on. It has nothing to do with how well the
software moves messages from one computer to another.

</rant>

~~~
Hello71
> 1\. Slack is a well-designed interface for allowing teams to communicate via
> chat.

subjective. I consider a bloated web interface taking several tens to hundreds
of megabytes of RAM compared to a text-based interface taking less than 100 kB
to be poorly designed.

> 2\. Slack is easy to install is use on Mac, PC, iOS, and Android. It Just
> Works™.

spelled wrong, and IRC clients are harder to configure only because there are
so many options for servers, whereas Slack only supports one server.

> 3\. Slack doesn't require me to install IRC somewhere. Which also means I
> don't have to worry about how people gain connectivity to said server when
> outside the office.

webchat was invented for a reason

> 4\. Slack has whimsy. Fun colors, messaging, emoticon, bots, etc.

IRC has had mIRC-style colors supported and even adjustable by the majority of
clients for at least 10 years. I don't know what "messaging" means. If you
mean "private messaging", pretty much every chat software in the world has
that. AOL and ICQ have that. You can put emoticons in your text manually if
you want. It was on IRC that the concept of chat bots was _invented_ , not on
Slack.

> There is a reason why IRC, a widely-available, chat solution that has been
> available for decades didn't catch on. It has nothing to do with how well
> the software moves messages from one computer to another.

Yes, it is about how much money a for-profit company has to spend on marketing
and copy as opposed to a standards organization.

~~~
notwedtm
This whole response reads like it was written in the 90's. Most people don't
care if something takes up 10's of MB's of RAM when new PC's are shipping with
16-32GB standard.

Your comparison of what amounts to ASCII art versus Slack's rich-media
embedding reads like it is straight out of a Fortran developer's "I'm still
relevant" handbook. You even offer up AOL and ICQ as counter examples!

If we're going there, I guess we should simply assign everyone a GUID and be
done with it, right?

HMU on ICQ: 110339943

~~~
simoncion
> Most people don't care if something takes up 10's of MB's of RAM when new
> PC's are shipping with 16-32GB standard.

ISTR a -now undoubtedly outdated- answer to a question that was very much like
"Why will there not be a _real_ Photoshop clone for mobile devices in the near
future?". One of the striking things to come out of the analysis was that
-absolute best case- you got something like ~300MB of RAM (and -common case-
~100MB) to work with before you got _unceremoniously_ killed.

I would _hope_ that now you can _reliably_ consume ~500MB of RAM per app,
but... that's still a _far_ cry from what you can use on a "real" PC.

Unfortunately, memory usage still matters. :(

------
emergentcypher
Please for the love of god just don't use Slack.

We have learned absolutely nothing. Let's all jump on the bandwagon of another
closed-source, proprietary, walled-garden service and hand over all of our
private intra-company communications to a private third-party in another
country. GREAT IDEA.

~~~
scrollaway
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:

[https://plus.google.com/u/0/+JeromeLeclanche/posts/icC6gDToB...](https://plus.google.com/u/0/+JeromeLeclanche/posts/icC6gDToBsQ)

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/](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...).

~~~
ChuckMcM
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?

~~~
sdegutis
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?

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

~~~
e12e
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](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).

[ed: Matrix also have some support through bots/plugins for IRC bridging:
[https://github.com/matrix-org/matrix-appservice-
irc](https://github.com/matrix-org/matrix-appservice-irc) ]

~~~
Arathorn
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:

* IRC ([https://github.com/matrix-org/matrix-appservice-irc](https://github.com/matrix-org/matrix-appservice-irc))

* Slack ([https://github.com/matrix-org/matrix-appservice-slack](https://github.com/matrix-org/matrix-appservice-slack))

* Verto ([https://github.com/matrix-org/matrix-appservice-verto](https://github.com/matrix-org/matrix-appservice-verto)) (for talking VoIP with FreeSWITCHes)

* Respoke ([https://github.com/matrix-org/matrix-appservice-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...](https://github.com/matrix-org/node-purple/tree/master/appservice)) (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](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]

------
ash
Some open source self-hosted alternatives to Slack:

* Rocket.Chat ([https://rocket.chat/](https://rocket.chat/))

* Zulip ([https://zulip.org/](https://zulip.org/))

* Mattermost ([http://www.mattermost.org/](http://www.mattermost.org/))

* Let's Chat ([http://sdelements.github.io/lets-chat/](http://sdelements.github.io/lets-chat/))

Oh, and by the way, you could have your own Rocket.Chat instance running in
Sandstorm in about 30 seconds:
[https://sandstorm.io/apps](https://sandstorm.io/apps)

 _Update._ And I would love to see a modern federated chat protocol to take
off. Something like [http://matrix.org/](http://matrix.org/).

~~~
briandear
Not sure why I would want to self host what is effectively a phone system. I
have actual products to build. We could ease time self hosting source control
as well -- to what end? I have members of the team spending time (and thus
money) setting up something that pleases people philosophically but really
adds zero value -- in fact, it actually costs money (through very expensive
developer time.)

I don't get the point of complaining about Slack. It works great, it's simple
to use and it has an amazing feature set. IRC is pretty terrible. Try doing a
drag and drop file transfer. Try using markdown. Try displaying images inline.

I don't get what the problem is with closed source Slack. Do we avoid the
phone company because their software is closed source? There comes a point
where this FOSS obsession sort of jumps the shark. Worrying about a 'walled
garden' for a chat tool is kind of silly. If it bothers people so much, create
a FOSS Slack with the ease of use and setup and maybe people would be more
interested. But anything that requires me to 'self host' something that
amounts to a service means that is a bad use of time. I can pay the Slack guys
to maintain chat while my devs work on maintaining our products. IRC is
terrible. Try and get someone from your marketing department to use IRC. The
neck beard and almost hipster pontification about the 'bloat' of Slack is kind
of ridiculous. We have better things to worry about. Slack works on all my
devices perfectly. I have a searchable log of everything. I don't have to
think or worry about anything. It's simple and works. Until there's a viable
alternative that exceeds Slack's ease of use, that's what I recommend people
use.

~~~
ash
> IRC is terrible.

I didn't mention IRC in my comment :)

It's interesting how you compare Slack with a phone company. There are
important differences between Slack and a phone company. 1. If you give me
your phone number I could be talking with you in a few seconds without me even
knowing the name of our phone company. 2. You could decide to change your
phone service provider and (in some countries) even keep your number.

How would you do these things with Slack? Slack is great, and I like it, but
it could stop being great at some point in the future.

(Yes, I realize that Rocket.Chat user couldn't chat with Zulip user, for
example. That's why I'm excited about efforts like
[https://matrix.org/.](https://matrix.org/.))

I agree with you: it's expensive to self-host. [1] But when it is _possible_
to self-host, you could hire a specialized company to host the chat system for
you. And - if you are careful - you can later switch your chat-system-hosting
provider if you want.

[1]: That's what [https://sandstorm.io](https://sandstorm.io) is trying to
fix, by the way.

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

~~~
tabbott
It's worth mentioning that Zulip ([https://zulip.org/](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).

~~~
brazzledazzle
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?

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

~~~
tabbott
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](https://github.com/zulip/zulip/issues/249)

------
Uptrenda
The author makes a huge list of all the things Slack does and then goes on to
suggest time-consuming ways to hack standard IRC clients to do the same thing.
The question is: why in this day and age should we have to do that?

Have you ever noticed just how many open source projects are still using
shitty software from the 90s? No doubt, some of that software is actually
quite good but I will argue most of it exists primarily as a result of
tradition. In other words: a lot of it isn't the best way to do things
presently, and perhaps if we stopped using such mediums as: mailing lists,
newsgroups, and IRC channels to run our open source projects then presumably
our projects might be filled with more diverse people than dinosaurs that
still roam our mailing lists.

I don't know why developers do this: but they assume because they have the
skill to do just about anything with technology that other people who also
have the skill ought to take the same time to do as they have. But honestly:
even developer time is too valuable to waste on pointless shit. We ought to be
trying to make things easier to use.

------
tptacek
If you don't want to use Slack for open source projects because it's closed-
source, fine. That's a reasonable argument.

If you don't want to use Slack for open source projects because Slack is in
fact pretty bad at those workloads, fine. I agree! I think Slack does a pretty
bad job at any group application where most of the people communicating don't
already know each other.

Where you go off the rails is in suggesting that IRC is competitive with
Slack. IRC is awful. It's a medium dominated by 7-bit clients with tiny
message limits that provides virtually no useful metadata and no works-by-
default history or search --- both things that virtually every open source IRC
support channel _b a d l y_ needs.

IRC does exactly one thing better than Slack: it's easier to join a new IRC
channel than it is to join a new Slack project. The rest of IRC's "features"
are red herrings, many of them more harmful than helpful.

Surely by now someone has built a Slack-like, perhaps with decent IRC support,
that big open source projects can champion as a Slack- and IRC alternative.

It will be much easier to keep open source projects from trying to fit their
square pegs into Slack's round aperture when people give up on promoting IRC.

~~~
mbrock
"Awful" technologies can still be fulfilling.

I mean... Hacker News is pretty "awful."

Maybe the things that you claim make IRC "awful" actually have weird benefits
in terms of community. Kind of like how HN is kept intentionally awful, to
keep out the losers or whatever.

~~~
tptacek
Yes, I think the comparison to HN is especially apt.

------
jedberg
This is the perfect counter example to "Open source is better". IRC has been
around for 20+ years. But a company that is just a few years old blows it away
feature-wise. Sure, you _can_ do all the same stuff in IRC, but look right at
the article for why you wouldn't. The answer to every "missing feature" in IRC
is to install some extra software and then maintain it.

I'm don't want to waste time doing that, I've got products to build and
maintain.

The closed source option is better because they have a financial incentive to
keep it that way. And I'm happy to pay for that because it saves me time and
lets me work on things for my customers instead of myself.

I'm a huge fan of open source and used to be a zealot about using open source
to run my business. But I've started to see the light in my old age.

~~~
netcan
I generally agree, though I'm not sure financial incentive is the reason. Open
source has really shown that financial incentive is (A) complex and (B) not
the only thing that motivates people.

If you look at open and closed source across a lot of categories, I think it's
more common to see OS "win" where the product is more objective. When it come
to more subjective problems like UX, it seems to be more difficult.

If your goal is something fairly objective OS is really amazing. Take VLC's
"play everything everywhere" goal. Fantastic, objective goal for and OS
project that really plays to its strengths.

Linux is, I guess, the canonical example. It's fantastically successful
relative to closed source competitors on every front that is objective. But,
its consistently been unsuccessful as a consumer desktop.

That said, I don't think IRC is dead either. Some people/communities prefer
IRC.

~~~
mike_hearn
What you're trying to say is that open source works best when there's little
or no design work involved and little or no product vision required.

Linux is a canonical example: it's simply a clone, design wise, of a plain old
UNIX. The product vision was "copy UNIX". Where the wheels fell off Linux is
the moment it got ahead of the UNIX legacy (i.e. modern desktops) and started
having to compete with Windows, so suddenly the "copy UNIX" goal was no longer
relevant. But Windows was made by Microsoft, or "the great satan" as Stallman
memory called it.

So simply switching the goal to "copy Windows" wasn't possible because Windows
and UNIX were very different and anyway, lots of people hated Windows. Linux
had picked up a lot of semi-technical and technical users who didn't care much
about FOSS purity but loved the club feeling that using an obscure OS brought
them. The end result was big splits and bizarre, illogical design decisions
being made simply because "do it like Windows did" was ideologically
unthinkable, even when Windows had basically got it right (or at least, less
wrong).

------
Arathorn
[Slightly naughty crosspost from [https://drewdevault.com/2015/11/01/Please-
stop-using-slack.h...](https://drewdevault.com/2015/11/01/Please-stop-using-
slack.html#comment-2337758257)]

There are an increasing number of plausible FOSS alternatives to Slack out
there like Zulip, Mattermost, LetsChat, RocketChat etc. Classic IRC simply
doesn't compete in terms of the featureset, glossy clients and web-dev
friendliness. However, most of the FOSS Slack clones miss one vital point:
they just provide a random custom API to their clients which may not even be
published. Despite being FOSS software they're not actually promoting Open
Communication - they are just building yet more silos that fragment your
conversation history and contacts/contactability even further. If you want to
pick your own client, or pick your own server, or interoperate with other
comms networks (other than naive bridging), you're generally out of luck.

This is why I personally believe it's vital to support open standards for
communication like Matrix.org or XMPP or IRCv3, and build glossy clients and
services on top, so that rather than being locked into a single server &
client from any given project, we retain the freedom to pick the clients,
servers, services and service providers that _we_ want rather than being
forced into using particular ones for particular communities. A good start
would be for the Zulips and Mattermosts of this world to federate with Matrix
or XMPP out of the box, even at the lowest-common-denominator functionality
set, to support open communication rather than causing yet more fragmentation.

[Disclaimer: I work on Matrix.org]

------
zanny
Somewhat tangential but relevant, what the hell happened to XMPP, period?
Wasn't it supposed to be our one communication account we do groupchat, video
calls, IMs with persistence, and file transfers over? Why did it just up and
die with nobody working on it and nobody using it?

[http://xmpp.org/extensions/xep-0045.html](http://xmpp.org/extensions/xep-0045.html)
exists. Its groupchat, it could probably be amended to support inline code,
and its persistence model lets a server chose to broadcast the message history
or not.

And it is incredibly more user-friendly to make an XMPP account through a GUI
client, have username@server, then join group@server for groupchat. No /join,
no /register, no port management or #channel management. Hell, any reasonable
XMPP client would default to your current server for groupchat so when you
click "join chat room" you get the server part prefilled and you just enter
the group name (or pick it from a list of groups - the protocol supports
channel announcements).

I get that XMPP is a horrible format (XML) and horribly bloated (committee)
and horribly old (1999?) but if its that broken why can't we make another
protocol for peer to peer realtime communications? Why isn't webrtc becoming
that transport? Why do we keep getting these one shot web startups trying to
replace open protocols every other weekend for a quick buck?

~~~
scrollaway
Previous discussion on this:
[https://news.ycombinator.com/item?id=10280611](https://news.ycombinator.com/item?id=10280611)

It's sad. But the only thing that can be done is work on an actual protocol
that _will_ solve these problems. It's a big burden to bear, and more often
than not, building something that will bear such a burden just kills it
outright (cf... xmpp.)

~~~
ZenoArrow
> "But the only thing that can be done is work on an actual protocol that will
> solve these problems."

What about the Matrix protocol (referenced in other comments made in this
discussion)?

~~~
scrollaway
I am following it from afar. I don't see how it'll gain traction, ever,
though. The marketing problem is one devs don't like to solve, but it has to
be solved.

~~~
Arathorn
The plan for marketing it is:

* Ensure there are glossy Matrix-native clients out there with a Slack-equivalent level of good UI and UX (e.g. [http://vector.im/beta](http://vector.im/beta))

* Build bridges to federate together as many different protocols as possible. This includes IRC, Slack, XMPP, SIP, Lync, Verto, Respoke etc. We're trying to make this as easy as possible by providing some high level building blocks like [http://github.com/matrix-org/matrix-appservice-bridge](http://github.com/matrix-org/matrix-appservice-bridge). This hopefully will make it easy for others to bridge themselves into Matrix once we have critical mass.

* Release a stable version of actual Matrix standard itself, keeping it as simple but capable as possible. (Right now it's not frozen, and it's still in beta)

* Provide a really capable reference server implementation. (The current one, synapse, is a good starting point and works well for experimenting with Matrix, but we still have work to do on performance and scalability).

* Run around the world encourage existing projects/networks/solutions/developers to get involved and defragment their comms - a bit like the early internet guys had to do with defragmenting email.

It's obviously hugely ambitious, but we actually have some good traction
already (despite still being in beta). Hopefully the trend will continue!

[Disclaimer: i work on it]

~~~
scrollaway
Best of luck! I'll do my best to support you.

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

[1]: [http://irccloud.com](http://irccloud.com)

------
peterjmag
It's not as simple as "just use IRC". Even in cases where an IRC channel is
both available and relatively well-promoted, some communities still seek out
other tools. The first example that comes to mind is Reactiflux, a rather
large React.js community that recently moved from Slack to Discord[1][2],
another closed source app that will probably stay that way[3].

To me, the fact that a community of tech-savvy _developers_ won't use IRC
exclusively is a pretty good indication that IRC is not enough.

[1]
[https://facebook.github.io/react/blog/2015/10/19/reactiflux-...](https://facebook.github.io/react/blog/2015/10/19/reactiflux-
is-moving-to-discord.html)

[2]
[https://github.com/reactiflux/volunteers/issues/25](https://github.com/reactiflux/volunteers/issues/25)

[3]
[https://twitter.com/discordapp/status/648379244570013696](https://twitter.com/discordapp/status/648379244570013696)

~~~
vjeux
For context, we've always promoted IRC for real time communication on React. I
encouraged people to setup other mediums for communication and many people
attempted but only one took off: Reactiflux on Slack. The official way is
still IRC on the website but most people are using Reactiflux which is pretty
incredible.

Now, we got the bad news a month ago that we've been kicked off of Slack :(
So, I started looking at all the options and frankly, all the alternatives I
tried had a really bad user experience. Sure, they had all the features of
Slack but the polish was not there.

Until I randomly stumbled upon Discord, a chat app for gamers. It turns out
that it does everything that we used Slack for, has better perf than Slack...
Before we even made the switch officially, people were already using it
organically in favor of Slack which is a testament of its qualities.

I highly recommend using Discord for your open source project!

~~~
emp_
It also seems the Discord web client is built on React, which is oddly
satisfying. Having trouble finding more info on their stack.

~~~
vjeux
"@discordapp: @DenisIzmaylov Our backend is a mix of Python+Elixir/Erlang+C++
depending on which piece of the infrastructure.

@discordapp: @DenisIzmaylov do you mean our encryption? If so, it varies by
which version of DIscord you use. TLS, DTLS, and xsalsa20.

@discordapp: @DenisIzmaylov TokuMX and Redis, moving some things to Cassandra"

[https://twitter.com/denisizmaylov/status/656181143205773313](https://twitter.com/denisizmaylov/status/656181143205773313)

------
mshenfield
Slack is the wrong choice for large community projects for one pragmatic
reason: the 10,000 message limit for free teams. I participate in a large
developer community that lives on Slack. Conversations are deleted quickly on
less active channels like #lisp or #volleyball, sometimes within a day. This
is frustrating when trying to connect to like minded people and also maintain
a record and resource for community members. And at $6.67/user/month it really
isn't viable to upgrade.

I can't speak to the quality of projects like Mattermost [1] and Zulip [2],
though I'm excited by their concepts. IMO trying these, or using a hosted
service designed for community projects like Gitter [3] are necessary
alternatives.

[1] [http://www.mattermost.org/](http://www.mattermost.org/) [2]
[https://www.zulip.org/](https://www.zulip.org/) [3]
[https://gitter.im/](https://gitter.im/)

~~~
pmontra
Yes, the 10k limit kills it. After that you can still search old messages and
find them but you lose the context because you see only a few lines around
them. Either your FOSS project has a budget to pay Slack or you're bound to
lose any valuable knowledge and decision buried in the archive.

------
d0m
> Problems with IRC that Slack solves

Main thing that Slack solves as far as I'm concerned is a great and uniform
client on every platform.

Don't get me wrong, I love irc. This is where I started learning everything I
know about computer.

I tried many times to get various team on it and it always failed. I think
it's mainly because the learning curve is too big for non-technical/busy
people, and that there's no good and uniform clients on all platform.

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

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

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

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

------
synthmeat
I find it surprising that everyone apparently thinks that it goes without
saying that Slack's interface is superior to other choices.

It is full of visual noise. You end up in desparate need of splitting most
types of information streams in separate channels because of it, and then
before you know it, you're channel-hopping all day long.

For core functionality - chatting - I've found that most IRC clients I've used
are superior to it. Hell, even Facebook's chat is superior.

It'd take fully redesigned fully native client idiomatic to every platform
abounding with customization options to make me take a stroll through that
garden. Not web client and especially not some Electron (is it?) desktop
client that looks more like afterthought than carefully crafted experience.

------
heavenlyhash
Come to the Matrix! [1]

\- Open! Free on both the beer|culture axis!

\- Modern! (There's actually control structures in the protocol. Imagine: a
chat protocol that's actually ascii safe! (Yes, yes, unicode too: the joke is,
_IRC isn 't even ascii safe_.))

\- Many platforms! (The matrix.org site has a full client list; I'm personally
using it via a linux desktop client (that also works on windows and mac), the
web, my ipad, and my android phone.)

\- IRC bridged. (I use it _constantly_ in this mode. It's a better IRC
experience than any other IRC client I've used, honestly. Even in rooms with
100s/1000s of people. Consistent logs, instantly accessible from multiple
computers/clients, no need to set up bouncers, and so on.)

\- File uploads, images, videos. All of it. A friend streamed me a video from
his halloween party last night via the Matrix client on his iPhone. It worked.

\- Did I mention it even supports webRTC? That's right: it's also a completely
functional skype replacement. (Yes, pending your browser's support and all
that jazz: that said, it's a more complete product than most of the other
webRTC demos floating out there.)

The entire protocol is just... _good_. On the nerdier deep end of things: It's
the first federated chat standard I've seen proposed that actually has
reasonable message IDs baked in and loose timing systems that's both available
during a partition and can reach consistency afterward (messages list their
last-seen messages, and so act like vector clocks, an accepted good solution
to problems in CAP territory). You could actually take two systems with clock
skew and have them reach a single, reconciled view of the world, even after
netsplits. Compared to IRC (or XMPP) this is either magical or a deep relief,
or both.

I discovered Matrix while I was in the process of writing a chat client of my
own for XMPP. I abandoned the project (and XMPP, as well, though that's a
subject all its own [2]). Matrix already did everything I ever wanted. Really,
really well.

Not affiliated; just a happy user who's never found any better platform for
communicating openly.

\---

[1] [https://matrix.org](https://matrix.org) |
[https://vector.im](https://vector.im)

[2]
[https://news.ycombinator.com/item?id=9772968](https://news.ycombinator.com/item?id=9772968)

~~~
rrix
+1

matrix solves a lot of problems that IRC has and even lets you solve those
problems on IRC through the Matrix<->IRC bridge :)

I've been using it as a replacement for my IRC bouncer for a while, barring a
bug that prevents support of SSL-only rooms, and it's been wonderful. Great
web client on vector.im, pretty decent mobile clients given they are
"reference implementations", support for VoIP voice and video chat, coming
support for e2e encryption (the DAG just stores encrypted blobs now)

I've long felt that a big piece of my love of IRC was the spontaneous
intersections of my communities. I got involved in FOSS and open source
because one time a person mentioned there was a LUG chat for the city I was
in; that led me in to a long chain of events that ended with me getting
involved in the Fedora Project and other FOSS communities. Slack is creating a
world where that is simply not possible. One of the big things that this
discussion misses is that tribal-intersections that IRC allows opens up a huge
door for abuse. Slack "solves" that by siloing you away from the world, but
that has always been a lazy and error prone solution.

I feel like Matrix is in a position to move the needle on that. It's got a
huge distributed DAG specifically designed for human-metadata like chat and
presence and, well, why not put Karma or Reputation on that DAG as well?
People have talked of dogecoin and similar as a Whuffie
([https://en.wikipedia.org/wiki/Whuffie](https://en.wikipedia.org/wiki/Whuffie))
and in my mind Matrix is an interesting platform to build something like that
on. I could create a room that requires a certain reputation level to post in,
and you'd have to gain reputation in other communities to be allowed to post
in to mine. When you realize that Matrix.org 1:1 chats are just "rooms with
only two people in them" that becomes a really nice way to solve the
spam/abuse issue. Prove to my friends in the public chat that you aren't a
shitbag and you can talk to me.

------
spankalee
This post is completely disregarding the ease-of-use of Slack (and other
silo'ed chat rooms), mainly due to it's pretty monolithic structure.

Yes, there are many things that Slack does that _can_ be done with IRC, but
they require significantly more coordination between various parts than Slack.
I'd love to see an alternative to Slack not just a clone, as easy to use and
administer, and built on an open protocol. Individual teams should be an easy
entry point for a tool like that.

------
tolmasky
I will add one silver lining to all of this (since I agree with everyone
talking here that IRC is "hard"), Slack is also hard. That is to say, we're
still in low hanging fruit phase. I don't know if I was just _doing it wrong_
, but when I had to join the Slack channel for a FOSS project, I found it very
confusing:

1\. I had to be invited or something? (Still don't know if this is the case
always)

2\. It still remains a mystery to me exactly how Slack treats different
accounts (or are they all the same account?) for different projects. It makes
me like sign in to them differently but then they all show up together?

3\. The Slack app is great or whatever, but its cool when a project can just
embed an IRC channel, and even just make you an automatic account, right
inline on their site and not have to deal with signup for _anything_.

If someone wanted to enter this space, they still could. Just make something
that allows you to have one "Account" that would work across the board, had an
embeddable widget so there's no "going" to the chat, its just there on the
project page, has bots and emoji or what have-you. Maybe Gitter is working on
this (already has all these abilities?). But suffice to say, I find it funny
(sad?) that the discussion is around how easy Slack is vs IRC when IMHO Slack
is still pretty hard and confusing.

------
bobbygoodlatte
Hacker News: is closed source is a walled garden requires a "Y Combinator"
account to communicate

Most people don't use software because of the driving philosophy behind it —
they use it because it solves a problem of theirs.

If a tool is the best one for the job, you should use it. And if Slack has a
substantially better UI for communication, maybe developers of IRC clients
should try to build a better UI rather than complain about adoption of Slack.

~~~
e12e
In all fairness, while the currently running incarnation of HN isn't open,
earlier versions of Arc and hn/news (along with forks) is open source, eg:
[https://github.com/arclanguage/anarki/](https://github.com/arclanguage/anarki/)

And there are clones, like lobste.rs:

[https://github.com/jcs/lobsters](https://github.com/jcs/lobsters)

Then there's the API, that allows anyone to export data. So while I get your
point, and agree with it to a certain extent, it's also not entirely fair.

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

~~~
Zeebrommer
www.matrix.org?

------
ceronman
Slack is awesome. It's way better than IRC in many ways. But I agree with the
OP. Please don't use it for FOSS projects, use it for your company or other
private use cases. But FOSS projects an communities require open tools. Slack
won't save your history unless you pay for the service. The pricing is per
user which makes it very bad for a FOSS community.

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

------
zdw
Amen. To add to the list, there's also Bitlbee
([https://www.bitlbee.org](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.

------
programminggeek
IRC kind of sucks. The experience is worse. That's why people keep making
these different tools - Campfire, HipChat, Slack.

It's not just a technical thing. It's an experience thing. IRC is technically
fine, just way too nerdy to be main line of business software these days.

~~~
chris_wot
So what you are saying is that the client software is not intuitive.

You do know that all that needs to occur is to make a nice client?

~~~
detaro
Sure. "all that needs to occur" is pretty useless if it hasn't occurred.

~~~
chris_wot
Which means IRC itself doesn't suck, only the UIs we have made so far.

------
cydrobolt
I can't agree more with this headline. I can concede that IRC isn't the most
modern of technologies, but it is effective and well-developed at what it
does. There is a FOSS ecosystem that can be achieved with IRC, which cannot be
achieved with Slack. As a FOSS project, you can commit to only using free and
open software when you also use IRC, as software such as atheme or charybdis
are all open.

Additionally, Slack is more privatized, with a less opportunities for
enhancement (e.g IRC bots, IRC webchat, many clients). All users also need to
sign up prior to use, which is just simply not viable. IRC manages large
influx of help-seekers or project members well with its op-voice-user and
ban/quiet system, allowing for channel operators to handle the high amount of
users without a problem.

On the other hand, Slack fails at all of these points, as it is intended for
internal team usage and struggles with this specific usecase.

Furthermore, most FOSS contributors are also not contributors to a single
project only. For instance, I personally contribute to a variety of FOSS
projects, and it is extremely easy for me to coordinate with all of those
projects simply by opening a new channel on my freenode or OFTC network in my
IRC client. Slack lacks this, requiring a new tab for each project and really
lacking support for FOSS operating systems such as Linux distributions, a
problem that is likely not going to be fixed due to its closed-source one-
client structure.

------
nhumrich
I hate irc. I hate it for one main reason, nobody uses it. Now, before you say
"over x million users" I mean use, like I actually talk, not just sit there
logged on. I have tried to join a lot of open source or product channels on
irc (pypi, python, docker, wercker, kubernetes, etc.) And every time without
fail, I join the channel and there are over 50 people signed in and I'm like
"awesome people actually use this channel", then I proceed to ask the question
the prompted me to lognin in the first place. After four hours and no answer
or response at all, I usually have to go home, or shut my computer down. I
don't have a desktop running 24/7 just so I can irc. So once I log off, I know
I'm never getting an answer. I might try again if I have another burning
question, but with a couple of tries and no luck, I eventually give up.

Now slack on the other hand I've never had this problem. I don't know what it
is, but some of the same communities switched over to slack (i.e. kubernetes)
and once they were on slack, I was getting responses and discussions from
multiple people within 15 min or less. The beauty is even if the channel
wasn't as active it would still be a million times better because I can shut
down my laptop, and get notified on my phone when someone replies. I can then
continue with the conversation publically or privately, even if the two of us
are on other sides of the world, because history is saved and I don't miss
anything I'm notified on, even if I'm not logged in anywhere.

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

------
EGreg
At Qbix (our company) we believe that there will be a platform for social apps
the way that Wordpress is for blogs.

We just recently met with a VC who was impressed with our platform pitch,
saying he hasn't seen something large in our space that's open source yet.
Slack specifically came up as something that Andreessen Horowitz made a big
bet on. I'm not going to say much (unless someone asks) except that:

* It's open source and on GitHub ([http://github.com/EGreg/Platform](http://github.com/EGreg/Platform))

* It is designed to put control back in people's and communities' hands. It should be installed by communities, or they can choose us to host, like wordpress.com does

* Each community can release its own client app, BUT you can also have client apps which provide a seamless experience ACROSS communities and let you do identity + connect with friends + get notifications across communities!

* This was not easy to build. It took us over four years.

We started before Diaspora* and we built an open platform on which app
developers can build apps which communities can install, and which can
aggregate social experiences across communities. The apps can be ANY social
apps and the platform takes care of all the underlying details, including app
versioning, user identities, "finding your friends" in each new community,
registration/password stuff, email / mobile notifications, native app
integration and caching, and much more.

------
Pxtl
IRC? Really? That's your solution? Not some kind of self-hosted Wave-like tool
or something? Not something web-based?

~~~
e12e
Technically, there's no contradiction in using IRC and something "web-based"
\- there are a number of decent IRC web clients.

------
wldcordeiro
To add to this, don't use Gitter for FOSS projects either. I've been seeing
lots of projects abandon IRC for Gitter.

~~~
SeriousM
In addition, Gitter is open source, has many client apps and, it, or really
need, a irc bridge

~~~
e12e
I'm sorry, the Gitter server part is open source? AFAIK it's a closed source
service?

------
yokohummer7
It seems that the author is following his own lesson faithfully:

[https://www.reddit.com/r/programming/comments/3r3m6q/please_...](https://www.reddit.com/r/programming/comments/3r3m6q/please_dont_use_slack_for_foss_projects/cwktw5j)

------
jbarciauskas
I'm responsible for a medium to large FOSS project. I noticed that Wordpress
had recently moved to Slack, and asked someone I knew over there how
engagement had changed after the move.

He reported they saw about a 10x increase in users moving to Slack (100 ->
1,000).
([https://twitter.com/HypertextRanch/status/627122747664113664](https://twitter.com/HypertextRanch/status/627122747664113664))

I get the arguments about not using it, but my priority is providing the best
tools to the community to enable them to work together productively, as well
as providing the most effective forum to encourage more people to get
involved. How can I ignore that sort of order of magnitude increase in the
number of people who can engage in real-time with the project?

~~~
Sir_Cmpwn
I've heard the Wordpress tale and I would guess that it's more related to the
announcement and press around it generating attention than it is the merits of
either platform. A lot of people who didn't know Wordpress had a chat room
probably joined up.

------
jordz
Completely agree with this. We use Slack for our Business Communication and
love it, we pay for it so we can see all our messages and it definitely has
its place. (Office Managers, Project Managers, Directors, PR are all in it,
super simple and easy for them)

For Open Source projects or just general communities IRC is the best medium
suited to it. Yes IRC has its issues but maybe that's because no one has
brought it forward with the kind of velocity other projects seem to have these
days.

I don't boycott Slack teams I just find it difficult to manage more than 2
teams in the client so I just don't, I like channels in IRC. I can flip
between them regardless of server or team and can see the entire history.

------
ajarmst
Scans as a case of the "I like X better than Y, therefore X is objectively
better than Y" rationalization fallacy. Someone else could easily use the same
set of facts to argue the opposite case: "irc doesn't support code snippets,
so ....". The political argument that you shouldn't use a closed-source
product also irritates me. I use a tool because it's the best tool for s job,
and FOSS is very often the winner there. But if the FOSS option isn't the best
choice, don't tell me I should be using it anyway. I don't attach moral weight
to a choice of licensing model.

------
snorrah
Are any particular irc networks recommended for FOSS collaboration? I'm
guessing channel and Nick services should probably be a prerequisite but other
than that, where do people prefer to congregate?

~~~
Sir_Cmpwn
Freenode.

[http://freenode.net/](http://freenode.net/)

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

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

[https://slack.com/pricing](https://slack.com/pricing)
[https://www.irccloud.com/pricing](https://www.irccloud.com/pricing)

~~~
sktrdie
Slack is free, we use it for free and it's always on. IRCCloud's free service
disconnects after 2 hours of inactivity.

------
terravion
Are there IRC clients that work well in poor connectivity situations?

I.e. does IRC or any IRC client support sent, received, read confirmation the
way that What'sApp or Google Hangouts reports this information?

~~~
Drup
With a properly configured bouncer (ZNS is rather easy to setup), it will work
regardless of the client.

------
davexunit
Completely agree! I see free software projects depend on proprietary tools
_all the time_ and it is very frustrating. I often see projects using JIRA or
asking companies like JetBrains for gratis licenses to proprietary development
tools, and now I'm seeing Slack more frequently. I _will not_ participate in
your free software project if you depend on SaaSS or proprietary software to
get work done.

The company I work for uses Slack, and luckily there is an IRC bridge to
connect to so I can keep my workflow in Emacs rather than having to use a
clunky web interface, but there are many special Slack things that they don't
render correctly in plain text form so I feel like a second-class citizen. If
this is the future of text-based communication, I don't want to participate.

I like IRC. I like that things aren't centrally logged by default. I like the
bots that I've been interacting with for many years (that I find to be better
than whatever Slack bot I've come across, by the way.) I like Freenode as an
IRC network. I like the variety of clients available (I prefer ERC, a client
written in Emacs Lisp.) Could we use some sexy web clients to get less
technical people on board? Sure! Should we use a proprietary, centralized,
surveillance system until someone else fixes IRC issues for us? No way! We
must reject Slack because it isn't a tool for the people, but a tool for
profit.

~~~
mike_hearn
What makes you think IRC isn't centrally logged? You realise that the Freenode
staff have root on all Freenode servers, right? It's not actually a
decentralised network at all, it just looks superficially like one from the
outside: they could log whatever they wanted at any time.

I'm not even sure the servers use encryption between each other. If they do I
didn't see any mention of it on the freenode website.

Heck, given that SSL isn't even a default for many IRC clients, I suspect that
in practice it's vastly easier for governments to eavesdrop on IRC than on
Slack which is fully SSL, always.

~~~
xena
The software is very simple and doesn't have the ability to log messages like
that. I maintain a fork of the ircd freenode uses and that simplicity has
actually been a bit of a pain as things grow.

------
polarix
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?

~~~
pmx
There are lots of web-based IRC clients out there

~~~
d0m
Which is part of the problem. People don't want "a lot of web-based IRC
clients", they want only one and it has to be amazing.

~~~
chris_wot
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?

~~~
hbosch
And there is: [http://shout-irc.com](http://shout-irc.com)

IMO Shout is a UI improvement over Slack for the sheer fact that it is 100%
customizable.

~~~
chris_wot
You realise you just increased traffic on their demo by like 1000%? :-)

Pretty nice though.

------
brazzledazzle
One thing even private organizations should think about is the potential for
chats on Slack to embarrass the heck out of them. Slack doesn't let an
organization sunset and delete private chats/DMs after a certain amount of
time. When employees think they aren't overheard they start to get very frank
with each other (which is good, I think frank and direct communication is
important). But sometimes they say things that are ignorant or even their
frankness can reveal things about the company that are embarrassing. This
isn't even a theoretical scenario anymore, look no further than dumps from
recent hacks.

I like Slack's default-to team member privacy but you can implement these
features without compromising that. I opened a case with Slack about it but
they closed it with the standard "consider it in the future" response that I
expected (which I don't hold against them, I can't say I wouldn't have done
the same). It may take a breach of Slack's infrastructure and subsequent leak
of private chats for them to make the changes needed for organizations to
protect themselves from this.

It might only take user education to protect a company from this, but in the
end if you're a big enough organization there are going to be people that
don't care, hate the organization or are just to jaded to take the
ramifications seriously.

~~~
daenney
Looking at this page it seems entirely possible to configure a DM retention
policy: [https://slack.zendesk.com/hc/en-
us/articles/203457187-Settin...](https://slack.zendesk.com/hc/en-
us/articles/203457187-Setting-up-custom-message-and-file-retention)

It seems to by default use the team retention settings.

~~~
brazzledazzle
Thanks a bunch for this. I'm surprised the person helping me didn't know about
this (unless it's fairly new) but I should have put more effort into
researching it myself.

------
INTPenis
I think it's perfectly fine for FOSS projects to use non-FOSS. This article is
a wee bit on the fanatical side for my taste, and I'm the guy who bought the
lemote. ;)

A public FOSS project should be able to use whatever they want for bug
management, issue management, support, and other things that do not affect the
core project in any way if compromised or monitored.

Especially if the company behind said product even give out discounts or free
usage accounts to such projects like Atlassian or github.

------
yeukhon
Yeah, IRC clients are hard to use, too many are command-line based, although
on Linux you can still find a few with GUI, but not as pretty as Adium on Mac
OSX. Your mileage may be different, but when I was working at Mozilla everyone
used IRC and it was not a huge burden because most people really just do /join
or pm a person. As long as you provide a documentation on how to use IRC, you
are golden for the most part. If you mandate people to use IRC and have
resource available to help troubleshoot or setting up IRC, you are good. If
you need to set up some complicated things with IRC, well, it is tough, but
you are on your own.

Slack's interface is not very impressive, very messy in my opinion, but that's
me. There are businesses out there offer IRC as a service, so that's another
option.

Final point: I really don't care about FOSS vs OSS vs Proprietary. As long as
the company truly respects my data privacy and security, and is easy to use, I
can give zero damn about either of three. It's 2015, we need to stop arguing
and actually make things better. Business needs to focus on improving product
experience and security. But you know what, some people do, that's fine, none
of my business anyway.

------
BogusIKnow
Been a heavy IRC users in the 90s, no a Slack user. There just is no
comparison for me. Do I miss channel wars, nickbots, take overs and hacks? No.

------
makecheck
If you want to communicate with a person or organization in ways that don't
involve online chat, you have a variety of standard ways for doing so:

\- E-mail address

\- Phone number

\- Mailing address

What is it about chat protocols that has resisted convergence on anything as
remotely standard as these other methods? I mean, I _could_ tell somebody that
I spray-painted hieroglyphics on my house and that "there are 3 shipping
companies in the world that know how to find my house using hieroglyphics so
please ship through one of them", yet somehow my "address" has remained the
sensible way to handle that problem.

The problem isn't Slack or IRC or any other client, it's that _we have any
choices at all_. At this point we don't _need_ choices for chat protocols any
more than we need a choice of ways to put an address on a house. The technical
community needs to start loudly criticizing clients that aren't converging on
_some_ standard, and standardize more and more behaviors every year until it
really doesn't matter what people are using.

~~~
kbenson
So, in the US:

> \- Phone number

Originally supplied through a monopoly.

> \- Mailing address

Government assigned.

> \- E-mail address

Originated on a government funded and used network, but eventually settled on
open standard.

Having the ability to impose usage until a critical mass is achieved and being
first seem to both be criteria.

------
shubhamjain
> has only one client

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.zendesk.com/hc/en-
us/articles/201727913-Connecting-to-Slack-over-IRC-and-XMPP)

~~~
apocalyptic0n3
It does but you lose a lot of little features that other people using Slack
will expect you to have and be able to see/interact with.

------
giis
Anyone here tried [https://botbot.me/](https://botbot.me/) for logging?

------
shmerl
Agreed. No more proprietary IM services please.

------
jarmitage
While we're on it, can anyone recommend a good open source calendar app with
decent web and mobile interfaces? (if there is one)

I'm building internal tools for the record label I make music with. We're
going to try self-hosting Zulip vs. Mattermark for collaboration, and it would
be great to have a calendar that integrates well.

------
eddiezane
Slack is starting to be used as the communication platform at events now as
well. Most of the hackathons and conferences I've attended recently have used
it and added all of the attendees.

It's worked really nicely for communicating announcements and updates with the
added benefit of allowing attendees to socialize before, at, and after the
event. It's also really changed how things like mentorship are done [0].

The problem I've had is the lack of any form of SSO. With all the events, FOSS
projects, and actual organizations I'm up to 19 Slack accounts. Having to
signup and create a new account almost every weekend is getting crazy.

[0]: [https://medium.com/mhacks-hackathon/hackathon-mentorship-
can...](https://medium.com/mhacks-hackathon/hackathon-mentorship-can-be-
better-425d9a190ce4#.92mrjzcjg)

------
digitalpacman
I've used IRC a lot. For work and for projects. The experience is always
horrible, and the clients always suck. We switched over to using slack for
projects and for work and everything got instantly better. It takes seconds to
setup and destroy places to chat that are private. It also takes seconds to
search your entire history, on any device, and find what you talked about 3
weeks ago. Sharing code that doesn't get removed is amazing. It's a pain in
the ass when the IRC client removes code and tells you nothing. I've sent
entire messages to people which "get blocked" because the message is too long
or contains code, and it never gives feedback.

I agree account creation in slack sucks though, and the author is correct that
slack is not built for FOSS projects.

------
paulryanrogers
If IRC's limitations are too cumbersome to workaround there is also XMPP.

~~~
scrollaway
IRC's limitations are not those fixed by XMPP.

Previous discussion on this:
[https://news.ycombinator.com/item?id=10280611](https://news.ycombinator.com/item?id=10280611)

------
unfamiliar
None of the problems listed seem like problems to me. All of the solutions
that make IRC fill this role seem like they will require more work and time to
set up than I am to put in just to get communication set up. Slack just works.
So unless I am going to be working on something highly sensitive that I can't
trust a third party reading about, I'm going to keep using it.

Wouldn't the best solution be to adapt one of the existing open source slack
clients to use a local server? Then we have all of the feature set and none of
the security and privacy concerns.

------
nzoschke
We use Slack to support the open source development for Convox (open source
PaaS). The main benefits are:

Mobile client with push notification

First class photos, files, code snippets

Moderation tools

Same tool for private organization chat

Users that use Slack for the jobs seem to really like Slack for community
support

The downsides are:

No invite system. Needs an hack app

Unsupported use case for community chat

Closed system. Exclusionary compared to IRC

So far the productivity gains feel worth it. I can only guess Slack doesn't
mind this usage will provide better public chat offering someday.

A few people have given the same feedback about using IRC over Slack, however
so it's on my mind.

Would chatting in both work?

------
raverbashing
\- The Slack client is an improvement over IRC ones. I don't remember free IRC
clients (GUI) for Mac OS or Windows (there's Pidgin, but still...)

\- 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...](https://slack.zendesk.com/hc/en-
us/articles/201727913-Connecting-to-Slack-over-IRC-and-XMPP)

~~~
Nyubis
HexChat is a pretty great free client for Windows. It's basically XChat.

~~~
Sir_Cmpwn
HexChat supports OSX, too.

------
incepted
I understand the urge of certain people to fight Slack but if you think irc is
a legitimate alternative, you probably don't understand the problem enough to
offer a suggestion.

More credible alternatives would be Hipchat or Gitter but anyone who has used
these two tools know that they are still way, way behind Slack in
functionalities and user friendliness.

Slack is succeeding because it's a great tool.

Want to beat it? Create a better tool and people will migrate to it for its
merits, not because it's open source.

------
rekoros
We (sameroom.io) bridge channels/room in Slack, IRC, Gitter, and several other
systems (about 14). It's a commercial venture, mainly aimed at helping large
companies manage the lack of federation between team chat factions.

However, we do what we can to support open source and we'd be happy to provide
sameroom functionality to open source projects. Please reach out on
sameroom.io/contact to take us up on the offer.

------
mariuolo
Do I sound backward if I thought it was about Slackware?

------
m3talridl3y
Fact: IRC doen't persist chat messages on the server, so to view old messages
you need to install a bot that provides you with the last n messages... and
you have to manually query the bot for them. No thanks. Have you people heard
of this thing called "mobile"? Spotty connections are the new normal. Having
the last N messages autoloaded when I view a channel is a _necessity_.

------
kumarharsh
I agree to most of the points you make, except that none of those points would
work in real world without a LOT of effort.

I've summed up my thoughts on this topic here:
[https://medium.com/@kumarharsh/please-use-slack-for-foss-
pro...](https://medium.com/@kumarharsh/please-use-slack-for-foss-projects-
bf9d53ce3f7d#.ea6xotd8m)

------
donatj
I hear a lot of people talking about the problems with IRC, and I truly wish
someone would enumerate them. It works great for our needs but I'm very
curious the ways it isn't working for some.

We use a self hosted IRC server, along with an IRC bot written in Go for
everything from automated deployments to chat logs to weather and traffic and
bus schedules.

------
hk__2
I run a large FOSS project; we use both Slack and IRC. Working with
maintainers in 3 or 4 different timezones you can’t afford to lose your IRC
session if you don’t want to miss messages. As pointed in the article however
Slack is for _teams_ , not _communities_. We use IRC for open discussions and
keep internal discussions on Slack.

------
berns
Some of the features mentioned here: persistent log, powerful search, comment
editing, easy onboarding and invites, code blocks; some even ask for thousand
of users in a chat room and moderation tools! Wouldn't this communities be
better served by a modern forum, like Discourse instead of a chat?

------
nerdwaller
> requires users to have a different tab open for each project they want to be
> involved in

This isn't true, down the left side bar you can select other teams if you've
signed into more than one.

I'm not suggesting we should only use slack, but at least they do make it
fairly easy to navigate.

------
agmcleod
I just also want to make the argument that github is a walled garden, so is
google code. They're proprietary systems that we're able to use and take
advantage of. I use github and I love it, but it can still have the same
potential issues as slack.

~~~
Sir_Cmpwn
I don't think that's true. GitHub is a frontend for the open git protocol. You
can take your repositories and move somewhere else with next to no effort.
Heck, almost all of my repositories exist in multiple situations.

All that being said, I've personally been doing more things on a private git
server and less things on GitHub.

------
z3t4
I think you would be better off using a full fledged forum. Then use a chat
(IRC or whatever) on top of that for real time communication. Where the
important stuff goes to the forum, and general talk in the chat.

------
stephenitis
Just wondering here can someone explain to me why campfire didn't move to fill
the need of IRC/slack better? was it ever truly competitive in this space?

I was casual fan of 37 signals/Basecamp.

------
late2part
I don't use Slack because they had a significant security breach and I'm not
convinced they are doing things differently or better since then.

------
pronoiac
I've noticed many hosts call out IRC in the TOS, as IRC is prone to DOS
attacks.

And is there Giphy integration? Or editing of posted comments?

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

------
ninjakeyboard
[http://gitter.im](http://gitter.im) is well suited for github projects!

------
spectrum1234
Nothing to see here. Just another engineer who is so obsessed with engineering
they think UX doesn't matter.

------
Yuioup
Unfortunately, you managed to pull off a Streisand. So... what is Slack? And
where can I use it? Sounds useful.

------
legohead
Wouldn't Slack be ideal for FOSS projects? My fear would be of losing
sensitive data when using Slack, but with a FOSS project this isn't an issue.

Slack is a tool, like a debugger or IDE, which aren't all open source.

If you are working on a government project with secret clearance, then these
issues make sense. Otherwise, the article feels like it has more of a
"whippersnapper" message.

~~~
dlisboa
I disagree with some of the things in this article (mainly that IRC is
necessarily better for your company) but Slack isn't _ideal_ for FOSS
projects. It's a very long way from ideal.

Main reason being: Slack is a company and as such they can change their policy
at any time. There isn't any specific right granting FOSS projects any status.
Slack can ban the users they want, can deny access to accounts they want, they
can be sold to other companies and can be bankrupted, bring it all crashing
down.

Slack isn't a tool, it's a service. It's not in any way whatsoever like a
debugger or IDE, even if those may be closed source. A tool is something you
have and can use. You might not own its manufacturing but you own its
potential use. Like a hammer you didn't make but is yours to do anything with.
You can use it a million times if you want.

Slack is someone else's hammer that you pay to use. That's a service. The fact
that they allowed you to use it for free for some undefined period of time
doesn't mean you own it or dictate any rule of its use. It's still their
hammer. They can stop you from using it at any point in time.

FOSS projects are supposed to be inclusive, open, transparent and fully
decided by an owner or a community. Giving away control to a third party with
no contract whatsoever is a terrible idea and a good way to break many of
those premises.

Slack is being used for FOSS because of the failings of IRC noted by others in
this thread, but that doesn't mean it's a good idea. Certainly not when the
audience for Open Source is already very accustomed to IRC.

Slack is great for the turnkey solution it is, it offloads that IRC
configuration you'd have to do, and it's easier to introduce non-technical
people to. It's good for paying customers that have a clear contract with the
company and as such gain certain rights. It's not, in any way, ideal for other
cases. It might fit them, but it's not a great idea.

------
jkot
I am surprised nobody mentions Jabber, it is better alternative to Slack than
IRC

------
ausjke
using irc on a daily basis, I wish it supports some basic tags such as <pre>,
<code>, <img> and <video>, to make it more like a html chat IM...but anyway I
like it and use it all the time.

------
xtat
Honestly I still prefer irc

------
jadeddrag
And same goes for hipchat.

------
bdcravens
And yet the author links to his Github profile.

------
j_s
Apparently Slack has become the new BitKeeper!

------
wfzimmerman
Tide, please don't rise.

------
l1ambda
What about gitter.im?

~~~
giis
users need a github account to use gitter.

~~~
Touche
They need accounts for Slack as well. In fact they need an account for _every_
Slack, at least with Gitter you just have to have a GitHub account.

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

------
anon5_
> that Heroku hack

What is the "that Heroku hack?" mentioned in that article

~~~
jnpatel
I was also curious about this. As the article mentions, Slack doesn't make it
easy for your organization to allow open registration. People have developed
hacks around this by running a server on Heroku [0], or using Typeform
combined with Slack's API [1].

0: [https://github.com/rauchg/slackin](https://github.com/rauchg/slackin)

1: [https://levels.io/slack-typeform-auto-invite-sign-
ups/](https://levels.io/slack-typeform-auto-invite-sign-ups/)

------
draw_down
I agree Slack is a poor fit for this. But god, using Slack makes it painfully
obvious how shitty IRC is. I almost wish people would stop mentioning them
together. I hate IRC and I have since the 90s, it's just bad.

------
tatter
irc.buttes.org #flashsupport.

tell them tater sent you

------
jsprogrammer
>That the reasoning is fallacious doesn't make the conclusion incorrect.

This is trivially true by the [material implication, modus ponens, modus
tollens, other name, etc] truth table. However, if you study the truth table a
bit longer, you will realize that you should stop reading any text which
contains fallacious or self-contradictory logic. While the conclusion may be
"correct", it is correct _despite_ all of the other text you read (so, go find
a logical argument [instead of relying on _known bad_ information]). The text
you read _can tell you nothing_ about whether the conclusion is true.

Fallacious reasoning needs to be identified, targeted, and destroyed.

Edit: I've been rate-limited, so any fallacious (or non) arguments posted in
response will need to wait a while for a proper response (some have already
been typed up).

~~~
dang
We detached this subthread from
[https://news.ycombinator.com/item?id=10487585](https://news.ycombinator.com/item?id=10487585)
and marked it off-topic.

~~~
jsprogrammer
Care to elucidate the topic and how this subthread was not on it?

Edit: I know it's a lot to ask for.

Heh. Downmods.

~~~
dang
For HN purposes, an egotistical spat is not on any topic.

If you want to keep commenting here, you need to err on the side of following
the HN guidelines rather than breaking them. Your account has a long pattern
of breaking them, and of straddling them when not breaking them outright.
That's not the discourse we want here.

~~~
jsprogrammer
If you can show me the ego, I will concede to being off-topic.

I reject any notion that I have ever intentionally broken a guideline. I also
reject any notion that I have a pattern of repeatedly breaking any actual
guideline.

My claims are easy to falsify.

------
AdamGibbins
There's also a hard user limit on free accounts - 5000 iirc.

------
mdumic
I call FUD. Something to the effect of "Please people, don't drive cars, they
are not FOSS". My company pays for Slack and we get a ton of value from it.
Kthxbai!

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

~~~
davexunit
>really, an extra browser tab per project is a burden?

Spoken like someone who has never been a serious IRC user.

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

