Please don't use Slack for FOSS projects

It's really difficult for me to take this point seriously if the only proposed alternative is IRC. I understand the benefits of IRC for FOSS and have used it many times in the past, but there's a reason why projects are adopting Slack over IRC. It's easier to use, it deals with on/offline states a lot more gracefully, it allows joining and inviting to rooms much easier, it has a clean and easy to use design and it's available pretty much anywhere using the same interface without having to install a client through their web interface (which is the exact same as their app interface). Along side that, there are hundreds of other minor to major features (File Sharing! Ticketing/build integration! Link Previews! Editing a message after it's sent!!!) that make it much more useful for many use cases than IRC. I think there is definitely room for competition with Slack for FOSS projects, but trying to pretend like IRC is that ultimate solution will ignore the problem completely.

Things I care about:<p>- User experience. In 2016, I&#x27;m not using the hacker&#x27;s AIM to collaborate. I know many people love it, but there are seriously better options. Syntax highlighting inline and file attachments that Just Work are fantastic.<p>- Product development. I want products I use to be continually improving. Not yearly but weekly. If something breaks, I don&#x27;t want to fix it because I&#x27;m not here to build a chat program or manage one.<p>Things I don&#x27;t care about:<p>- Closed Source. A dedicated team paid to work on the product full time, financially incentivized to expand the ecosystem is a major plus.<p>- A walled garden. This sounds like the same as #1. Slack allows many integration points, including chatbots that can be programmed to do anything. I&#x27;m not sure it is that closed off.<p>There is a reason large teams collaborate over Slack as opposed to IRC. If IRC filled people&#x27;s needs, they would use it. It doesn&#x27;t.

Author here. There&#x27;s not much to say here that wasn&#x27;t said last time, but here are some retrospective thoughts on this post:<p>- Probably would have come across better if I didn&#x27;t pitch IRC as better than Slack in general, but only that it&#x27;s better for FOSS projects. This blog post wasn&#x27;t meant to shame Slack in general, even if it kind of did in the end.<p>- Importantly, Slack has come out as saying that they don&#x27;t want big public projects to host themselves on Slack. It&#x27;s really just not a good use-case for Slack to put a FOSS project on it.<p>- In hindsight, a lot of the FOSS-friendly alternatives (Matrix, Gitter, etc) are quite good and I should have put more effort into researching them and discussing them in my article.<p>It&#x27;s probably too late to steer the discussion, but please remember that my post addresses the use of Slack for <i>FOSS projects</i>, not in general.

One problem that they failed to address in the Slack over IRC section is a damn near non-existent barrier to entry. I&#x27;ve introduced people and small teams to IRC. I&#x27;ve also introduced people to Slack. IRC is just different enough, even when introduced to a team of technologists who grew on AIM and the like. Consider the onboarding experience - I emailed someone a link to a Slack channel, and before I heard back from them they&#x27;d signed up on my account and, unsolicitedly, downloaded the mobile client and were chatting with me. My setup time was nil, and there was no training. Sure, they could have downloaded Colloquy to their Mac and iPhone, and entered the settings, and hoped for the best, but I&#x27;m almost positive it wouldn&#x27;t have gone so smoothly. That doesn&#x27;t even include time to configure a bouncer for persistence. It&#x27;s just anecdata, sure, but it counts for something, and helps to explain Slack&#x27;s explosive growth.

Previous thread: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10486541" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10486541</a>

If you don&#x27;t want to use Slack for FOSS projects then don&#x27;t, but if you do, go for it. This is what OSS is all about, Freedom, use what you think is right. Diversity is good, maybe people leaving IRC will lead to innovations in IRC that address it&#x27;s 20 year old deficiencies that have never been addressed.

There&#x27;s a Free and Open Source Alternative to Slack called Mattermost: <a href="http:&#x2F;&#x2F;www.mattermost.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.mattermost.org&#x2F;</a>

An additional option which is now available is to host your own Mattermost server. GitLab has integration for it even.<p>IRC is still my preference, but it takes a fairly technical person to appreciate it and host their own server. If you&#x27;re catering to more general people, having 1 technical person spin up Mattermost in docker might be a good solution.

&gt; Slack makes it so that you can see what you missed when you return. With IRC, you don’t have this. If you want it, you can set up an IRC bouncer like ZNC.<p>So perhaps I&#x27;m hoding it wrong, but I&#x27;ve been using ZNC for a couple of years and every time I forget to close Xchat at work and people keep talking, I can&#x27;t see what they said on my phone or at home. Also I can&#x27;t scroll up nor search for stuff which were said in the past.<p>For me that is the biggest drawback with IRC.<p>A sensible alternative, which I also was able to push at work, is Mattermost <a href="http:&#x2F;&#x2F;www.mattermost.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.mattermost.org&#x2F;</a><p>Although I would love to see us using <a href="http:&#x2F;&#x2F;matrix.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;matrix.org&#x2F;</a> but I don&#x27;t expect our customers to install their own instance so we could federate any time soon.

Honestly, my group uses Discord (<a href="http:&#x2F;&#x2F;discordapp.com" rel="nofollow">http:&#x2F;&#x2F;discordapp.com</a>) now. We love it. It replaces IRC and Teamspeak for us. Plus, I can get a user on the service in 5 seconds just by sending a link to them.<p>It is mostly used for gaming, but coding with it is just as great. There are a lot of public servers also for all sorts of things. (<a href="http:&#x2F;&#x2F;discord.me&#x2F;servers" rel="nofollow">http:&#x2F;&#x2F;discord.me&#x2F;servers</a>).<p>The voice is what we love it for, chat is awesome during the day when some of us are not able to talk over voice.

Why not Mattermost?<p><a href="http:&#x2F;&#x2F;www.mattermost.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.mattermost.org&#x2F;</a>

If this post were titled &quot;Please don&#x27;t use OS X for FOSS projects&quot; nobody would take it seriously. I&#x27;m struggling to see the difference ...

Open source is a form of software licensing that lots of people develop and use for lots of different reasons. That&#x27;s it.<p>Everything else is politics and philosophy. Some people really get into the very specific politics and the very specific philosophies of the FSF. What they don&#x27;t seem to get is that the FSF merely has one out of infinitely many perspectives on why open source is important and what people should do about it.<p>It&#x27;s fine if someone wants to run an ideologically pure (per FSF criteria) FOSS project, or not contribute to projects that don&#x27;t meet their criteria for ideological purity. Where it gets counterproductive is asserting that one group&#x27;s philosophy has some sort of primacy over the entirety of the FOSS world. It gets especially dicey when that group claims moral superiority over everyone else.<p>Instead of complaining about this or that FOSS project not being &quot;true FOSS&quot;, the FSF should define a set of standards and practices that go beyond mere software licensing that DO meet their standards for ideological purity. Then a project that wants to comply with the FSF have an easy way to state up front that they are politically aligned with the FSF in every respect. Those who care about such things can use that information to set their expectations about how the project is run outside of the software licensing aspect. Maybe it draws them to the project, maybe it drives them away, but at least no one gets surprised and no mailing lists devolve into pointless political flamewars.<p>That way no one gets disappointed (for example) when a project wants to use Slack for communication, assuming that that project has not stated up front that FSF-compliant ideological purity is a goal. Alternatively, if a contributor to a self-declared FSF-compliant ideologically pure project wants to use Slack, the other contributors to that project have grounds for denying that on a purely philosophical basis. They can focus on maintaining their standards for ideological purity rather than continually arguing over whether or not FSF-compliant ideological purity itself is valid goal.

Also free service has limit, so older messages will be eventually lost.

In my experience, I like IRC (been using it for ~10 years), but sometimes there is a lot of noise. For example, the Angular.js IRC channel devolved into a flood of bad questions with not enough information to help, and some entitled users. Many in the Angular community ran away to Slack in response. Code snippets aren&#x27;t as nice either in IRC vs. Slack.<p>I&#x27;m not sure what the solution is, but IRC is lacking (and sometimes blocked at workplaces) &amp; Slack seems to solve most of the issues, but it not wanting to support large open source communities is an issue as well. There is a hole in tools available.

The fact that Slack has made it clear they don&#x27;t intend to support large open source projects is the biggest thing in my opinion. Reactiflux was basically forced off Slack for getting too big. Other large communities like the Clojurians Slack community will likely be forced off soon in the near future too (some members of the community have begun discussing this and evaluating alternatives). The Elixir Slack community is also similar in size, and I see the same thing happening there eventually.

I&#x27;m not real keen on the Church of FOSS.<p>Don&#x27;t get me wrong, I love a great many FOSS projects; but my entire life does not need to be constructed of such. Posts like this smack of dogma and fanaticism to me, and engender mistrust of whatever projects the person in question is a part of. After all, if they&#x27;re that dogmatic about one thing, then what&#x27;s to say they aren&#x27;t dogmatic about other things?

Projects can use <a href="https:&#x2F;&#x2F;hack.chat" rel="nofollow">https:&#x2F;&#x2F;hack.chat</a>, for which I am the main developer. I am also working on an overhauled version (temporarily named Libre Chat) supporting file transfers, mobile apps, channel subscriptions, and chat history. Both are GPL, can be installed on your own server, and have &quot;official&quot; hosted versions.

Weechat in tmux&#x2F;screen with a bouncer is fantastic. Weechat has a ton of scripts like highlight monitoring, filtering of join&#x2F;part&#x2F;quit that you can customize for timeouts. Has a great support channel on freenode too.<p>If you&#x27;re doing FOSS projects, you can probably get your way around a command line enough to install and run both of these in a $3 VPS or even an AWS instance.

On a related note, Debian annonced [1] a new unified communications in November:<p><a href="https:&#x2F;&#x2F;wiki.debian.org&#x2F;UnifiedCommunications&#x2F;DebianDevelopers&#x2F;UserGuide" rel="nofollow">https:&#x2F;&#x2F;wiki.debian.org&#x2F;UnifiedCommunications&#x2F;DebianDevelope...</a><p>I&#x27;m not a DD, so can&#x27;t comment on how well it works - but I&#x27;ve had it on my todo-list s while to look at their real-world setup as inspiration.<p>[1] <a href="https:&#x2F;&#x2F;lists.debian.org&#x2F;debian-devel-announce&#x2F;2015&#x2F;11&#x2F;msg00000.html" rel="nofollow">https:&#x2F;&#x2F;lists.debian.org&#x2F;debian-devel-announce&#x2F;2015&#x2F;11&#x2F;msg00...</a><p>Previously submitted to hn, but didn&#x27;t gain any traction: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10531061" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10531061</a>

Those bullet point against slack are really common around here, but I&#x27;ve yet to hear an explanation as to why they&#x27;re a con.<p>Example: It&#x27;s closed source.<p>Apparently that in itself is intrinsically &quot;bad&quot;, and obviously so, because I&#x27;ve yet to see any explanation attached to that argument.

I appreciate the sentiment but the message is a bit weak. There are many things that are &quot;closed source&quot; that we have to use to collaborate on FOSS, I ride in closed source airplanes to get to conferences but I realize I could use a Prarie Schooner that I built out of freely obtainable materials to get there instead.<p>Ok perhaps that is a bit too harsh, but it is the essence of the argument. Its easy to get an open source tool that replaces IRC and works like Slack, you take $5M and you hire a half dozen engineers and a couple of designers and you build a set of tools and then you give it away for free and never see your $5M ever again. Welcome to the prisoner&#x27;s dilemma, FOSS edition.

I have only one complaint of Slack. It should be much easier to find and join open slack communities and switch between them.<p>I&#x27;ve used it for a small team before but we quickly finished what we were doing and now it&#x27;s dissolved. So I&#x27;ve been hearing awesome things about it and how people are using it and I haven&#x27;t really had a chance to try it out. I&#x27;ve applied to join a few communities but I&#x27;ve never received a reply.<p>That process should be so much easier.<p>For open source projects or communities I think Discord fits the bill much better. It allows you to take part in multiple communities in one interface and you can use it without an official account.

I&#x27;ve tried and failed many times to keep IRC in my workflow. I always wind up opening it for a few days&#x2F;weeks then eventually just kinda fizzle out.<p>My company installed slack and it was just like wildfire - the whole team was on it instantly and never have looked back.<p>If there was a client + bot setup that would offer the same functionality out of the box over IRC I&#x27;m sure we would have picked it up just as quickly. And I would have liked to be on the irc channel for a few of my favorite OS projects as well. But as far as I know, without there is no such setup?

Jabber rooms seem like a pretty good idea. Lots of open source servers to choose from. Is there a reason not to use them, other than relative obscurity?

IRC is fine if you package it right. IRC is just a protocol anyway. Slack is way more convenient versus IRC + etc. However, we can change that.

A lot of the popular FOSS irc channels have devolved into rooms with thousands of people there with nobody talking. Seriously, over the past few years, it seems like people are still on IRC, but they just don&#x27;t engage on it. I wonder if that has to do with a lot of people becoming more used to other platforms doing a better job of assisting in communication.

This comes off as a snobbish article IMO. I don&#x27;t want to discredit the work the author has done, but it&#x27;s all over a communication tool, one that many of us have adopted in other environments. Having open source projects on the same platform as our other groups is simply a matter of convenience for the project organizer.

It hasn&#x27;t been mentioned yet but glowing bear (<a href="http:&#x2F;&#x2F;glowing-bear.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;glowing-bear.org&#x2F;</a>) is a nice web client that plus into any instances of a weechat process (that you let run in a multiplex terminal on a raspberry you plug in the kitchen, on the fridge).

Finally someone said it. I have a tough time with one of the project I am working on during my personal time. By the time I go home and get time to work on it or ask a few questions, I don&#x27;t see anyone in that slack room. When I am work, slack is blocked, so I have to wait till weekends to get someone answer my question.

The basic problem with Slack is that it&#x27;s not libre. It&#x27;s a fine product in many other ways. I won&#x27;t defend the ethics of libre: I&#x27;ll leave that up to rms, who has done a more-than-adequate job. But <i>libre</i> is a more ethical choice than <i>proprietary</i>.

I&#x27;m starting to see slack repeaters in IRC channels all around IRC and I am leaving those channel as it ruins my IRC settings and makes things confusing. My colored nicknames no longer work. It splits communities and makes people leave the channel.<p>Please don&#x27;t repeat slack to IRC.

Why IRC and not XMPP?

I don&#x27;t mind FOSS projects adopting slack - whatever it takes to make devs&#x2F;users happy. But slack&#x27;s tab-completion is woefully pathetic when there&#x27;s more than a few hundred members in a chat room.<p>This is a solved problem - get it together slack!

I recently decided on gitter.im plus a channel on IRC and a bot [1] that syncs them.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;finnp&#x2F;gitter-irc-bot" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;finnp&#x2F;gitter-irc-bot</a>

The nice thing with IRC is that it&#x27;s scriptable. So for example if you want a klaxon to sound every time the secret word is mentioned, it&#x27;s easy to do.

Makes total sense. Let&#x27;s say I have an open source project, how do I create a FREE irc channel for my users and what server to I choose to host it on?

Almost all brazil FOSS community is in our completely open app: <a href="https:&#x2F;&#x2F;actor.im" rel="nofollow">https:&#x2F;&#x2F;actor.im</a>

I&#x27;ve heard this argument before. The only problem is that IMO slack is awesome and IRC is not anymore.<p>I&#x27;m on 3 slack teams, one with some former co-workers, one for a non-profit that teaches coding and one for a side project.<p>If any of them suggested IRC I probably wouldn&#x27;t have bothered.<p>As it is, I have the desktop client on my Mac Mini, MacBook Pro and my Windows laptop and the app on my iPhone.<p>It&#x27;s great. IRC is not. That&#x27;s my opinion. You don&#x27;t even give any good reasons why it doesn&#x27;t work for open source projects.

IRC sucks from a usability standpoint. Huge opportunity to make it better, but also a huge risk due to the legacy of IRC.

The positives listed in &quot;Problems with IRC that Slack solves&quot; are significantly stronger than the negatives listed in &quot;Problems with Slack&quot;. By a lot. No wonder FOSS projects are choosing Slack!<p>I also like how the &quot;IRC is better for your company&quot; section doesn&#x27;t actually give reasons as to why it&#x27;s better. It instead lists multiple services you can employ to achieve the features Slack provides out the gate.

This whole article and discussion is silly. Use whatever you damn well please for your projects communication!

Slack client and web-app both are really heavy consuming ridiculous amounts of memory and cpu time.

&gt;irccloud: Is really cool and solves all of the problems. irccloud.com<p>Is IRCCloud not closed source also?

I plan to write a blog post on this at some point, but as a tentative short and rough draft:<p>IRC&#x27;s biggest problem is what I would loosely term &#x27;Grunginess&#x27;. Every single thing I&#x27;ve seen associated with IRC has this kind of Unix&#x2F;Linux-y grunginess to it where nothing is easy and everybody rolls their own solution.<p>If you would like to experience this first hand, try setting up eir (<a href="https:&#x2F;&#x2F;freenode.net&#x2F;eir.shtml" rel="nofollow">https:&#x2F;&#x2F;freenode.net&#x2F;eir.shtml</a>) which is written in an unholy mixture of C++ and Perl. (The moment I see this combination I usually know I&#x27;m in for a ride.) Or try the python IRC library (<a href="https:&#x2F;&#x2F;pypi.python.org&#x2F;pypi&#x2F;irc" rel="nofollow">https:&#x2F;&#x2F;pypi.python.org&#x2F;pypi&#x2F;irc</a>) which has almost no documentation besides docstrings and needs to be puzzled out and examined and source-read before you can use it.<p>You want to be able to see messages in an IRC channel when you&#x27;re not on? Don&#x27;t worry, ZNC (<a href="http:&#x2F;&#x2F;wiki.znc.in&#x2F;ZNC" rel="nofollow">http:&#x2F;&#x2F;wiki.znc.in&#x2F;ZNC</a>) is here to help, with powerful command line configuration action! Honestly IRC bouncers are kind of a red herring. Even if <i>you</i> can see what is typed in a room when you&#x27;re not on using a bouncer, the real benefit of slack&#x27;s message history is being able to see what&#x27;s typed in a room before you <i></i>joined<i></i>, and being able to assume that this is a feature which is available to every slack user.<p>Slack&#x27;s multithreading is beautiful. One of the biggest problems with running an IRC channel is that IRC is fundamentally broken. And when I say that I don&#x27;t mean it in the shallow way most people do, I mean actually literally fundamentally broken. Here&#x27;s why: The average human reads somewhere between 150-300wpm. A decent typist types at 60wpm. If we take 300wpm as an optimistic estimate of average reading speed, the moment you&#x27;re having a lively discussion the channel is swamped at seven participants or so. Slack makes multithreading easy by associating multiple topic &#x27;channels&#x27; together for a single group so that you can talk about one topic in this channel and another topic in that channel and it&#x27;s not confusing or unwieldy, people who want to hear about certain topics can subscribe to a channel and people who don&#x27;t can just not subscribe or leave. You don&#x27;t have this &#x27;stepping on each others toes&#x27; problem where three people want to talk about this and three people want to talk about that and they all use the same channel to do it.<p>Avatars, emoticons, that stuff is all a bit tacky but the core fundamentals of the design are a sound improvement over IRC, and IRC needs to respond to that.

People who are maintaining the FOSS projects should decide what they use, not you.

Ideally, Slack can consider:<p>- doubling as an IRC client<p>- providing open source projects pro level services similar to github.

My vote goes to Gitter

Uh, no. So much no.<p>So many things are better than IRC. Even Jabbr.net is better.

Kauan

I like the present-day Slack vs. IRC argument. It&#x27;s an ongoing manifestation of the blatant lack of appreciation of user experience and great design.<p>Developers need to get their heads out of their rear-ends. If IRC is so great, why doesn&#x27;t everyone use it?<p>This endless argument has been fought in multiple other products and fields as well.

All open source projects should offer an IRC channel, mailing lists and a forum!<p>And almost all do. Even newer ones like Elixir that started with Slack have now a mailing list and an IRC channel.

He lists the stuff that Slack does better than IRC, but then ignores it. Kinda like he&#x27;s just waving it off as not being important. So what&#x27;s the solution for getting the benefits that Slack has, without using Slack?

You were whining about this a couple of months ago already. Slack is simply much more user friendly and doesn&#x27;t look as dated as 99% of IRC clients.

IRC sucks.

Is this gonna be one of those &quot;every day until you like it&quot; things?