Please don't use Slack for FOSS projects (2015)
drewdevault.com
drewdevault.com
One of the biggest problems with IRC is that there is no immediately obvious way to jump into a channel and browse or search the history.
Also, because there are so many IRC clients, and so many servers out there, one person's IRC experience can vastly differ from another's.
IRC also doesn't have any of the modern amenities like emoji reactions or reaction gifs, comment threads, code snippets, plug-and-play third party integrations and web hooks, profile pictures, voice/video chat, screen sharing, or any number of a plethora of other features that BOTH Slack and Discord have.
If you want people to use an open source alternative to Slack or Discord, then people need to build that alternative. IRC, unfortunately, is not it (at least not in its current aged state).
There's literally web-clients available where all you gotta do is click a link and write a name that hasn't been taken by anyone yet, and you're in. No email address, no password.
History is even more straightforward — anonymous access to all IRC history is frequently provided by most projects. How do you get history for Slack without having an account?
Most projects? Really? I'd say at most 20% of IRC channels for open source projects I've been on have published history.
Shopping around for a log bot and figuring out a publishing channel is not straightforward. In fact nothing is more straightforward than builtin. While I'm not a big fan of using Slack for open source collaboration, saying IRC history is straightforward and provided by most projects is indeed delusional.
https://drewdevault.com/2019/07/01/Absence-of-features-in-IR...
The author doesn't equate them - they even list many critical things that Slack has that IRC doesn't. Which makes their conclusion even more silly.
After reading the article I feel you're misrepresenting what the author actually said.
The author lists a number of problems with Slack that in his opinion renders it "not a tool built for open source projects to use for communication with their userbase", and instead Slack is "a tool built for teams".
The author stresses that communicating with a community leads to entirely different usecases, and that "Slack has gone on record as saying that it cannot support this sort of use-case".
Afterwards, the author proposes IRC as a technology that mitigates some of the design problems that render Slack ill-suited for communicating with the userbase of open source projects.
The author enumerates arguments (technical and not so technical) to support his thesis. You've ignored them all.
There's literally a section called 'Problems with IRC that Slack solves'. And there's no 'but...' at the end of that section. It's just a list of things Slack solves. Maybe that's why people want to use it? It solves their problems?
> The author enumerates arguments (technical and not so technical) to support his thesis. You've ignored them all.
I think you've misread my comment or the thread. I wasn't providing a critique of their points... I was responding to the idea that they were equating them. They weren't - as you said, they have a list of ways they thinks IRC is better, and a list of ways they think Slack is better. So they weren't equating them.
Free slack is on par with IRC here -- you need someone nerdy enough to run a chat history bot to get a full searchable history.
EDIT:
Answered my own question: up to 85% discount, which is very nice, but still might be infeasible for many projects/communities.
Isn't Slack's cheapest plan around 8$ per user per month?
The thesis defended in the article is that Slack is not suited to communicate with the userbase of open source projects.
Capping a basic feature such as collecting message history at 250 users is a limitation that supports the author's thesis, as clearly it demonstrate that Slack is unable to handle the communication needs of a moderately popular open source project.
And I don’t even think it’s applicable - in the community I’m in we decided we didn’t want an eternal log of everyone’s discussions. More formal discussions in PRs and emails are recorded, but we rather let conversations fade away after some time.
How the fuck did people come to think of this as a negative? One of the stupidest things about "modern" IT services is that the public interface is a user interface instead of a machine readable iterface, so you can't build a user interface that fits your needs or preferences, you can't innovate features independently, and you can't use software to process the data, you have to interface everything with a human (or go to great length to scrape stuff 'n shit ... just the point of using information technology!).
Hu? Because they won't take my contribution that rips out all of the web interface and replaces it with EMACS?
I mean, what does this even have to do with FOSS? Developing stuff as protocols instead of as user interfaces does not in any way prevent FOSS, very much to the contrary. There are FOSS IRC clients in all shapes and forms: Web interfaces, X GUIs, Windows GUIs, mobile clients, terminal UIs, EMACS modes, XMPP bridges, Matrix bridges ... how is any of that "reinventing the wheel", and how would we be better off if all those clients had to be part of one "IRC FOSS project" rather than independent projects with standards-based interoperability?
Having many IRC clients is a good thing because I can have the experience I want, not the experience someone else wants me to have.
That's also the case with open protocols like IRC. Sure you can write an IRC client with reaction emoji support, and it will look great in your client, and anyone using a different client will just see garbage metadata. You can only innovate by getting "everyone" to agree on a new standard, and that's hard.
No, it's not.
> Sure you can write an IRC client with reaction emoji support, and it will look great in your client, and anyone using a different client will just see garbage metadata.
Then you are bad at protocol design.
> You can only innovate by getting "everyone" to agree on a new standard, and that's hard.
No, you innovate by being backwards compatible with established standards.
Now, maybe IRC has reached the limits of its flexibility and should be replaced, I dunno, but the idea that it is somehow impossible to evolve protocols incrementally with partial adoption of new features is just bullshit.
I don't really think so, but I don't really know, I haven't every tried to do anything in that direction.
> It has certainly had a lot of time to try.
Except that people have to do it? As far as I am concerned, IRC is good enough, so I don't feel like putting any effort into "improving" anything, and it seems like a lot of people using IRC feel this way. Those who feel it's not good enough, though, seem to prefer building non-interoperable systems or just using proprietary lock-in vendors. Obviously, that's not gonna result in anything new in IRC.
There are many solutions available to do this. Many channels publish chat logs publicly, which can be downloaded and searched using grep or your tool of choice. And there are web clients that can do this.
> Also, because there are so many IRC clients, and so many servers out there, one person's IRC experience can vastly differ from another's.
That’s rather the point of a protocol, no? IRC isn’t a platform, it’s a standardized way in which various clients and servers can communicate. Much like email, different clients support features useful for different users.
> IRC also doesn't have any of the modern amenities like emoji reactions or reaction gifs, comment threads, code snippets, plug-and-play third party integrations and web hooks, profile pictures, voice/video chat, screen sharing, or any number of a plethora of other features that BOTH Slack and Discord have.
I consider this a feature. I expect many others would. Constant reaction gifs / emojis / etc seem to be a distraction. I don’t believe I’ve seen these used in a way that had a positive impact on productivity, or effectiveness of communication.
> If you want people to use an open source alternative to Slack or Discord, then people need to build that alternative. IRC, unfortunately, is not it (at least not in its current aged state).
matrix.org / riot.im is what you want. The matrix protocol supports all of these features. Riot is an open source web client for it. I use it regularly and would recommend.
grep is not a sufficient replacement for indexed search with fields. Just try to use Discord's search feature, you can specify constraints extremely easily. The equivalent in grep (if you even have logs going back that far) would be some gnarly regex that you have to reference what characters you need to specify unless you're very familiar with regex.
IRC isn't hard, but it has real shortcoming and real problems. The user experience hasn't meaningfully changed in 20+ years, but people's expectations and how they interact with chat platforms has. This is coming from someone who uses IRC every day, both at work and at home.
What we really need is most of the features of Slack without it's terrible threading mechanism and no GIFs.
Good search can be done with chat, it just tends to be hard.
Quite a few of us here work in software, of course we can just jerry-rig a lot of solutions based on existing tools, it doesn't mean it is sufficient to be a product or useful for a broader set of users...
+1. But the solution is not to succumb to Slack. Matrix and https://about.riot.im/ is what we should be looking at.
Personally, I’m a big fan of MatterMost[0] as its also open source but provides a much more Slack-like experience which new users will be immediately familiar with. You can host it yourself and it works with lots of existing integrations.
[0] - https://mattermost.com/
If by that you mean that it doesn't require a machine with 32GB of RAM to run smoothly, then I'm all for such 90s chat tools!
Sharing files is trivial with Gist; and you get a fully proper history, ability to fork, plus works much faster than the clumsiness and memory waste that comes with Slack.
It looked like hot dog vomit, but it worked wonderfully.
Apparently not all files that need to be shared are text files. Developers have a million ways to share text files, thank you.
(I know how to use gists to share images and other files. It's not pretty.)
I have no dog in this fight as I do not use slack nor do I use irc anymore ...
However, reading this comment thread makes me think that what you all really need is neither a slack alternative nor an irc alternative ... what you all really need is a very well written irc bot.
The only useful software to get any sorts of real-time support from the community is Matrix. Nobody uses Slack in open-source simply because you can’t allow unregistered users to ask questions on public channels.
When I started using IRC in the 1990s it was full of college freshmen flirting. Most of them were not CS majors or otherwise technically adept. I really don't think it's "intimidating, complex, and nonobvious" in a way that makes people not use it. It just doesn't have images or history, that's all.
There are aspects of IRC that are nonobvious, but that's true of any software, including Slack (and, I assume, Discord), and you don't have to know them to start using it.
No IRC gateway.
Developers are extremely hostile to 3rd party clients.
Centralized control.
Ownership of your data.
Example? As someone who has written a library to facilitate creating 3rd party bots, I've never seen anything to suggest this.
Even browser CSS modifications are apparently frowned upon.
IRC is commonly quoted to support the asynchronous mode of chatting but it is somewhat misleading: asynchronocity is embedded to the IRC community and not the protocol. If IRC the protocol were actually asynchronous we would have, for example, a better story for mobile clients by now. Probably Zulip is better at the asynchronous mode, I'm yet to try out.
Now it is another story when you consider your clueless end users, who see proprietary platforms as a norm and actively seek the synchronocity ("anybody out there?"). I think you should be in (some of) those platforms in that case, because it is practically more important to help your users. Or maybe not, if you know your users don't like synchronous chat or proprietary platforms anyway. Throughout my history of using IRC, it was most useful as a synchronous Q&A channel and an asynchronous community bookkeeper, both irrelevant to the IRC protocol itself. I don't see why we should pursue IRC further. (Now it is funny that I still operate my own IRC network!)
Which doesn't exist anymore: https://news.ycombinator.com/item?id=16539857. As far as I'm aware, there is no way to connect to Slack anymore without their official client, unless you use something that is either their website in an app wrapper or probably violating their ToS.
As for myself, I use Weechat-Android (for about 6 years now) and am very happy with that on my Android phone. It uses a websocket with SSL, so I get notifications and it uses very little battery (or data).
Are you using weechat as a relay for the Android client or is it a standalone irc client? Cause to receive notifications a websocket will still have to be always connected.
That is correct, although there is a free tier, which my wife used for a while. The only major downside to the free tier is that IRC Cloud disconnects after two hours of idle activity.
> Are you using weechat as a relay for the Android client or is it a standalone irc client? Cause to receive notifications a websocket will still have to be always connected.
The former. I have a weechat instance (it is a terminal IRC client) on a VPS (the same one also running my wife's instance of thelounge) that I normally use when I'm on my laptop. On my phone, I use Weechat-Android as a relay client to the weechat instance. So the websocket connection on my phone talks to my weechat relay. Fortunately, Weechat-Android handles connecting and disconnecting seemlessly, and I don't have a problem with notifications.
The fragmentation pretty much excludes me from switching away. It's completely impractical to maintain notifications / check new messages / reasonably understand the interface of 5+ different clients (on multiple machines too!), so the theoretical benefit of using a new platform doesn't exist.
There's what - Gitter, Slack, Discord, Mattermost, Matrix? I'm sure there are more.
How do people actually manage this? Do people really have 5 of these clients open, or do they just arbitrarily pick one? Slack, when I've used it, has been a 'per organization' thing, can you have multiple orgs open at once or do you need a tab for each of those?
I just find the whole thing bonkers. IRC wasn't an arbitrary choice ten years ago, it was a defacto standard.
You can definitely have multiple orgs/communities/whatever open in slack. But you still have to make an account for each one, so it's no where near "/join #someproject". It's more like "Go to invite.someprojectthatusesslack.tld, put in an e-mail for slack to send you an invite, go find the e-mail, register for a new slack user using that e-mail, login to the project's slack and find channels to join"
Sure, there are some issues once in a while. Like with everything.
We use IRC at work, but I think when you setup an open source project community, you have to think carefully. IRC is for instant communication. If parts of your community are located in a timezone that is only online when you (the maintainer of the project) are not, that will create frustration, unless you start setting up all kind of bouncers or tools to let you be online at all time. In the end, I tend to prefer forums or mailing lists, because people writing can elaborate a bit more, and receive more meaningful feedback later on... but I guess I'm old school :)
Also external monitors work ootb, like basically everything nowadays.
gitter.im's frontend/SPA client has a bunch of glitches, but the backend seems solid.
Note that it's often been an excuse that Slack has an IRC and XMPP gateways, but, per the article, they've been shutdown in 2018.
I really hate Slack for how much memory it requires, and how many bugs it has. The Android app, for example, logs me out of every community if I'm removed from one of them; really "nice" when someone cleans up the resources of an old hackathon to be logged out of all the dozens of various teams you're part of. (Noone even knows how to call each of these individual teams or communities, either; requiring a separate login for all of them is pretty annoying, given that it's all maintained by Slack anyways.)
Or when they remove you from an existing hackathon team to make up space for new members, and now you lost all your contacts, and/or have to be re-invited again if you're still participating in the next-year-edition. It's basically a mess.
Even for employee communication — from a contractor's perspective — it makes you a non-owner of your own communication, unlike IRC, so, if you so happily accept it, you're basically working against yourself again.
I'm looking at you, Kubernetes.
Solves all of your points... It's open-source, has file sharing, code snippets, and proposed to help FOSS.
The big killer for me is not being able to see/ get notifications
A big part of the value of IRC-replacements are accounts that are tied enough to a person's identity (For example, by requiring sms confirmation) to deter most spam. IRC hasn't been able to do that.
If there's a channel mode that can stop that, while still keeping the channel useful for people who need support, I couldn't find it.
I'm not really a fan of channel mode 'r' for support channels. Someone might join the channel for a simple question or two, they get the answers and never return. Having to register a nickname and check email can be a bit annoying for some people.
The network also has user mode 'R' that blocks messages from unidentified users.
They added a spam filter into the IRCd over a year ago.
https://freenode.net/kb/answer/channelmodes
Individual IRC server implementations might, but each implementation seems to be unique in how they handle it (maybe through a website, maybe through NickServ, maybe through AuthServ, maybe through yet another bot name, and login may or may not use the PASS command, etc.), and those implementations frequently have you jumping through brittle hoops to auth that break when you attempt to automate them due to timing issues etc. leaving you manually logging in every time.
Which is probably part of the reason why the IRC servers I can think of generally all allowed messaging without any kind of registration other than connecting and auto-choosing a unique-for-now nickname. IRC moderation then becomes an uncoordinated, individualized, constant game of whack-a-proxy, RBLs, etc.