Please don't use Slack for FOSS projects(drewdevault.com)
drewdevault.com
Please don't use Slack for FOSS projects
https://drewdevault.com/2015/11/01/Please-stop-using-slack.html
380 comments
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:
- User experience. In 2016, I'm not using the hacker'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.
- Product development. I want products I use to be continually improving. Not yearly but weekly. If something breaks, I don't want to fix it because I'm not here to build a chat program or manage one.
Things I don't care about:
- Closed Source. A dedicated team paid to work on the product full time, financially incentivized to expand the ecosystem is a major plus.
- 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'm not sure it is that closed off.
There is a reason large teams collaborate over Slack as opposed to IRC. If IRC filled people's needs, they would use it. It doesn't.
- User experience. In 2016, I'm not using the hacker'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.
- Product development. I want products I use to be continually improving. Not yearly but weekly. If something breaks, I don't want to fix it because I'm not here to build a chat program or manage one.
Things I don't care about:
- Closed Source. A dedicated team paid to work on the product full time, financially incentivized to expand the ecosystem is a major plus.
- 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'm not sure it is that closed off.
There is a reason large teams collaborate over Slack as opposed to IRC. If IRC filled people's needs, they would use it. It doesn't.
Author here. There's not much to say here that wasn't said last time, but here are some retrospective thoughts on this post:
- Probably would have come across better if I didn't pitch IRC as better than Slack in general, but only that it's better for FOSS projects. This blog post wasn't meant to shame Slack in general, even if it kind of did in the end.
- Importantly, Slack has come out as saying that they don't want big public projects to host themselves on Slack. It's really just not a good use-case for Slack to put a FOSS project on it.
- 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.
It's probably too late to steer the discussion, but please remember that my post addresses the use of Slack for FOSS projects, not in general.
- Probably would have come across better if I didn't pitch IRC as better than Slack in general, but only that it's better for FOSS projects. This blog post wasn't meant to shame Slack in general, even if it kind of did in the end.
- Importantly, Slack has come out as saying that they don't want big public projects to host themselves on Slack. It's really just not a good use-case for Slack to put a FOSS project on it.
- 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.
It's probably too late to steer the discussion, but please remember that my post addresses the use of Slack for FOSS projects, 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've introduced people and small teams to IRC. I'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'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'm almost positive it wouldn't have gone so smoothly. That doesn't even include time to configure a bouncer for persistence. It's just anecdata, sure, but it counts for something, and helps to explain Slack's explosive growth.
Previous thread: https://news.ycombinator.com/item?id=10486541
If you don't want to use Slack for FOSS projects then don'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's 20 year old deficiencies that have never been addressed.
There's a Free and Open Source Alternative to Slack called Mattermost: http://www.mattermost.org/
An additional option which is now available is to host your own Mattermost server. GitLab has integration for it even.
IRC is still my preference, but it takes a fairly technical person to appreciate it and host their own server. If you're catering to more general people, having 1 technical person spin up Mattermost in docker might be a good solution.
IRC is still my preference, but it takes a fairly technical person to appreciate it and host their own server. If you're catering to more general people, having 1 technical person spin up Mattermost in docker might be a good solution.
> 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.
So perhaps I'm hoding it wrong, but I'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't see what they said on my phone or at home. Also I can't scroll up nor search for stuff which were said in the past.
For me that is the biggest drawback with IRC.
A sensible alternative, which I also was able to push at work, is Mattermost http://www.mattermost.org/
Although I would love to see us using http://matrix.org/ but I don't expect our customers to install their own instance so we could federate any time soon.
So perhaps I'm hoding it wrong, but I'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't see what they said on my phone or at home. Also I can't scroll up nor search for stuff which were said in the past.
For me that is the biggest drawback with IRC.
A sensible alternative, which I also was able to push at work, is Mattermost http://www.mattermost.org/
Although I would love to see us using http://matrix.org/ but I don't expect our customers to install their own instance so we could federate any time soon.
Honestly, my group uses Discord (http://discordapp.com) 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.
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. (http://discord.me/servers).
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.
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. (http://discord.me/servers).
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?
http://www.mattermost.org/
http://www.mattermost.org/
If this post were titled "Please don't use OS X for FOSS projects" nobody would take it seriously. I'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's it.
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'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.
It's fine if someone wants to run an ideologically pure (per FSF criteria) FOSS project, or not contribute to projects that don't meet their criteria for ideological purity. Where it gets counterproductive is asserting that one group'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.
Instead of complaining about this or that FOSS project not being "true FOSS", 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.
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.
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'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.
It's fine if someone wants to run an ideologically pure (per FSF criteria) FOSS project, or not contribute to projects that don't meet their criteria for ideological purity. Where it gets counterproductive is asserting that one group'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.
Instead of complaining about this or that FOSS project not being "true FOSS", 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.
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't as nice either in IRC vs. Slack.
I'm not sure what the solution is, but IRC is lacking (and sometimes blocked at workplaces) & 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.
I'm not sure what the solution is, but IRC is lacking (and sometimes blocked at workplaces) & 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'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'm not real keen on the Church of FOSS.
Don'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're that dogmatic about one thing, then what's to say they aren't dogmatic about other things?
Don'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're that dogmatic about one thing, then what's to say they aren't dogmatic about other things?
Projects can use https://hack.chat, 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 "official" hosted versions.
Weechat in tmux/screen with a bouncer is fantastic. Weechat has a ton of scripts like highlight monitoring, filtering of join/part/quit that you can customize for timeouts. Has a great support channel on freenode too.
If you'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.
If you'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:
https://wiki.debian.org/UnifiedCommunications/DebianDevelope...
I'm not a DD, so can't comment on how well it works - but I've had it on my todo-list s while to look at their real-world setup as inspiration.
[1] https://lists.debian.org/debian-devel-announce/2015/11/msg00...
Previously submitted to hn, but didn't gain any traction: https://news.ycombinator.com/item?id=10531061
https://wiki.debian.org/UnifiedCommunications/DebianDevelope...
I'm not a DD, so can't comment on how well it works - but I've had it on my todo-list s while to look at their real-world setup as inspiration.
[1] https://lists.debian.org/debian-devel-announce/2015/11/msg00...
Previously submitted to hn, but didn't gain any traction: https://news.ycombinator.com/item?id=10531061
Those bullet point against slack are really common around here, but I've yet to hear an explanation as to why they're a con.
Example: It's closed source.
Apparently that in itself is intrinsically "bad", and obviously so, because I've yet to see any explanation attached to that argument.
Example: It's closed source.
Apparently that in itself is intrinsically "bad", and obviously so, because I'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 "closed source" 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.
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's dilemma, FOSS edition.
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'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.
I've used it for a small team before but we quickly finished what we were doing and now it's dissolved. So I've been hearing awesome things about it and how people are using it and I haven't really had a chance to try it out. I've applied to join a few communities but I've never received a reply.
That process should be so much easier.
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've used it for a small team before but we quickly finished what we were doing and now it's dissolved. So I've been hearing awesome things about it and how people are using it and I haven't really had a chance to try it out. I've applied to join a few communities but I've never received a reply.
That process should be so much easier.
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've tried and failed many times to keep IRC in my workflow. I always wind up opening it for a few days/weeks then eventually just kinda fizzle out.
My company installed slack and it was just like wildfire - the whole team was on it instantly and never have looked back.
If there was a client + bot setup that would offer the same functionality out of the box over IRC I'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?
My company installed slack and it was just like wildfire - the whole team was on it instantly and never have looked back.
If there was a client + bot setup that would offer the same functionality out of the box over IRC I'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'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't want to discredit the work the author has done, but it'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't been mentioned yet but glowing bear (http://glowing-bear.org/) 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'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.