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.
Funny to see this reposted today, as just today I encountered an open source project which primarily uses Discord for chat - a terrible idea for all the same reasons. I had planned on writing a similar follow-up article reminding people that Discord is a bad communication medium for open source projects, too. I think that this is something the community ought to be occasionally reminded of, lest we lapse.
All of the same things that are wrong with Slack, discussed in the OP. Don't use nonfree platforms to collaborate on free-as-in-freedom software. They also appropriate "server" terminology to dilute stuff which actually puts the users in control - unlike typical "servers", a Discord server is anything but - they run on Discord infrastructure and the user has little to no influence over their adminsitration.
What do you mean by ownership of your data?
1) They own the storage by which the data resides and can dictate how the data is accessed
2) They own your IP
Slack has no public API for 3rd party clients; it's strictly for bots. The EULA says they can ban you if you use a 3rd party client. The clients I've seen require you to open browser web dev tools in the browser and copy your API key from the browser session.
Even browser CSS modifications are apparently frowned upon.
I think this is a bit radical claim, but I would avoid any synchronous chatting platform for F/OSS development including IRC, it is simply not worth its cost.
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!)
There have been months where the spam on freenode was unbearable, and fundamentally IRC is, like SMTP, a protocol where spammers have the advantage, and only heuristics stop spam.
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.
I don't believe that it does. For a week or two about a year ago, freenode had a problem where accounts would join channel, spam links to sites accusing prominent people of child porn, and be kicked a moment later.
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.
Freenode channels can require users to be registered and identified in order to join. This solves the spam problem. Given that I am on Freenode 24/7 and have been for years, on 40+ channels, and spam has never been an issue I stand by my original comment.
The spammers were using unidentified nicks. The network has channel mode 'r', that is used for only allowing identified nicks into the channel.
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.
In my experience of operating an IRC network, some channels hate to set +s because it hampers the channel's discoverability. Unlike +n, +s shouldn't be a norm.
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.
Acting like IRC is equal in functionality to Slack or Discord is straight up delusional.
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).
> 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.
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?
> History is even more straightforward — anonymous access to all IRC history is frequently provided by most projects.
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.
The linked post explicitly mentions that code fences are downgraded to a "long message" link. Note that I've used a word "downgrade", because I don't think it is a good solution. Anything unable to tie additional data for a message to the message itself is not good, in my opinion.
> 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.
> I feel you're misrepresenting what the author actually said
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.
On the free slack plan, you don't get history beyond its 10k message limit (or whatever the number is), unless you start paying per head. Even on small teams, that limit is hit surprisingly quickly. For the medium-to-large sized open source project slacks -- the history is basically completely useless.
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.
That's not necessarily true. If you're a certified non-profit, you can get free Slack with unlimited message history for up to 250 users (https://slack.com/help/articles/204368833).
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.
I think it’s a bit snide and snarky to just post a link like that.
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.
It's pretty tone-deaf of you, though, and suggests limited connection to FLOSS communities. Freenode, for example, has a policy that channels disclose in their /topic if there are public logs. Many mailing lists have the property of being viewable forever, and contributors understand that property, building discussions that last for decades and taking matters off-list when privacy is needed. This is not a new problem, and FLOSS communities tackle it already.
> 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.
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!).
Instead of re-inventing the wheel building your own interface, why not just spend that time working on the FOSS project in question? FOSS dogma seems to frequently get in the way of FOSS development. If you aren’t pure and blessed, somehow you are less worthy.
> Instead of re-inventing the wheel building your own interface, why not just spend that time working on the FOSS project in question?
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?
Agreed. The worst thing about all these * as a service things it that you're locked in to a single client for that service and many of them have awful and annoying UI's. The netflix UI isn't great, the audible one is abominable, the google music one is very bare bones and they don't care because they have a monopoly on the content. There is no incentive to improve, they have to be just good enough.
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.
> That's also the case with open protocols like IRC.
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 think you read too much into my post. I didn't claim anything about protocols in general. You yourself admit that it might not be flexible enough to evolve. It has certainly had a lot of time to try.
> You yourself admit that it might not be flexible enough to evolve.
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.
I use OSX and Linux machines all day at work, and typically use Windows 10 at home (where I do more gaming, but also occasional software development). I'm comfortable on all the major operating systems. Why do you ask?
some of what you're complaining about the lack off do work, znc as a proxy allows playback, emoji's do work on some clients, figured you wouldnt be aware of this if you were on mac.
> 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.
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.
All of the things you listed are true, and you and I and most other people on HN can respect why (at least to us) these reasons stand out from slack. But a middle manager who doesn't even know what IRC stands for isn't going to want to learn the syntax for grep. They're not even going to know why they have to write \" instead of ". They want something where you can scroll up, and then your messages from two months ago are there. And that's what slack is.
Don't let knowledge of old * nix tools be effectively gatekeeping people from joining a FOSS project.
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.
Well, my experience with Slack (never tried discord really) is that it's pretty hard to find anything that is more than a week old. Slack (and IRC) is designed to exchange the information quickly and forget about it. If we need traceability then e-mail is much superior to both.
I have linked to that post quite a few times here in HN along the years, it is surprising for me how many times this same kind of answer pops up and I don't understand if it's lack of vision or empathy that there are people out there that want tools with better ergonomics and are willing to pay for that.
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...
it's getting better all the time IMHO. The problem is that the reference back-end is in Python which isn't scaling well enough for the matrix.org instance / its rooms-- which is the only instance many people try. There's a project to implement that back-end in Golang which I expect to be a real turning point if it can get off the ground.
I disagree on reaction emojis. The alternative is to leave a reaction as a new message or not react in any way. They are filling a gap between responding and ignoring. Like a head nod but with more flavors.
My only issue with IRC as the alternative to Slack is that its really user hostile. Clients largely look like some 90s programmer’s idea of a chat tool, and as discussed, persistence and sharing files and things are extensions or hacks on top of the protocol. Without addressing these, IRC is going to remain the ‘underground’ tool it is at the moment, with little support from enterprise tools and other integration providers.
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.
> Clients largely look like some 90s programmer’s idea of a chat tool,
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.
I have a warm place in my heart for Pidgin. For a long, long time I had to deal with IM clients that wouldn't let you sign in more than one account per instance, and some of them used mutexes to prevent running multiple instances.
It looked like hot dog vomit, but it worked wonderfully.
"There are several richer IRC clients; the author of this article suggests https://thelounge.chat/ in a later article about IRC."
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 downside to that is that even with a well written bot, there is no source of truth for history, as the bot can become disconnected from the server, which implies we should move history logging and archival to the server, which is a bridge to far for many people; in particular Drew (the author of TFA) believes chat should be ephemeral rather than persistent and he is not alone in this camp.
The lack of threading and image support is a pretty big issue to open source projects though. The lack of threading has always been annoying in IRC, and posting screenshots is very convenient and useful in Slack.
For all of the points made towards Slack here, let’s remind everyone here that none of the open source projects actually use Slack.
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.
Do you have a like for a more detailed/specific reasoning against mattermost in particular? I might want to throw it at some grassroots instance in an attempt to get rid of it/user's acceptance of it.
As much as I dislike using a proprietary chat app, Discord is well designed and easy to use. Reliving the early internet is great and all but my time is limited, and I'm sick of sacrificing my time and sanity faffing around with bouncers and garbage IRC clients. It's the same reason I use macOS instead of Linux. I don't just want a Unix environment, I want a polished Unix environment where apps don't have Linux UI syndrome and plugging in an external monitor doesn't require me to pull up the man page for xrandr. That's a sacrifice I'm willing to make.
Discords design is horrible, there's huge gaps everywhere, it won't obey any themes and it limits options severely compared to other clients while disallowing third party client developement. It also eliminated the possibility to host your own server while for malicious marketing reasons using the same term for their hosted channels. It's one of the best examples how companies exploit the technological illiterate and it's a shame some of literate people don't care.
Also external monitors work ootb, like basically everything nowadays.
The biggest problem for me in IRC is lack of good mobile clients. You can't get push notifications and if you want to stay persistently online then you need to keep a perpetual battery-draining socket open.
You could setup a relay on your server ,but it's cumbersome and too technical for most people.
The best solution I have found is to use Riot/Matrix and connect to the channel via an irc bridge. That way you get a modern app/protocol which works on mobile. A better solution again would be to an actual matrix room for your foss projects.
My wife uses thelounge (self-hosted instance) as a progressive web application on her Android phone. It supports push notifications and file uploads. Before this, she used IRC Cloud, which also has a convenient mobile application with those features.
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).
IRC cloud is paid with a monthly subscription right?
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.
> IRC cloud is paid with a monthly subscription right?
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.
I use ZNC with the znc-push module. It supports a ton of different services, but I use it with Pushover. Notifications come in on time even when my phone is deep sleep.
I totally disagree with this article. IRC is incredibly user hostile and for even a technical user is intimidating, complex, and nonobvious. Everyone uses Slack or Discord, and everyone knows how they work, and the UI is easy. All the features that ddevault says are bad are things that almost everyone else cares about. I, for one, am thankful that more communities are moving off IRC.
> IRC is incredibly user hostile and for even a technical user is intimidating, complex, and nonobvious.
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.
I agree that IRC doesn't hit the needs and wants of many contributors these days. But I've really found the limits of the Slack free plan a bit rough in the Elixir Slack. And I'd say concerns about being on a proprietary system are valid. It ends up being a mess of pragmatic trade-offs, rather than clear-cut. Slack and friends is overall more approachable.
I do like IRCCloud, and use it often. But it's not Slack. Slack is one of those things that seems sortof dumb and simple but it just isn't. They've built a very compelling set of features that many of us now just take for granted.
Mattermost is the closest 'freemium' alternative to Slack I've seen.
> Slack provides an IRC bridge that lets you connect to Slack with an IRC client.
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.
Gitter is very much tied to gitlab/github/twitter. I for one would prefer if open source projects didn't force to accept terms of service of those services. There is a gitter bridge for matrix, but open source projects should probably just use matrix.
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 :)
As someone who heavily used IRC in his childhood I disagree. IRC is pretty much dead. If you want opensource instant messaging then go with Rocketchat or Matrix with Riot.
The FreeNode IRC network is alive and well for opensource support. Lots of devs for many, many projects, and users for many Linux distros, for instance, hang out there all the time.
I totally understand that IRC has issues, but there's really nothing that beats just being able to hit '/j #channel' on freenode and it's probably there and my client works how I expect it to.
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.
> 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?
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"
135 comments
[ 2.8 ms ] story [ 210 ms ] thread2015: https://news.ycombinator.com/item?id=10486541
2016: https://news.ycombinator.com/item?id=11013136
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.
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.
[1]: https://www.mumble.info/
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!)
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
https://freenode.net/kb/answer/usermodes
https://freenode.net/news/spamfilter
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.
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.
Sure, there are some issues once in a while. Like with everything.
Also external monitors work ootb, like basically everything nowadays.
https://about.riot.im/
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.
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.
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.
gitter.im's frontend/SPA client has a bunch of glitches, but the backend seems solid.
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 :)
The big killer for me is not being able to see/ get notifications
Solves all of your points... It's open-source, has file sharing, code snippets, and proposed to help FOSS.
I'm looking at you, Kubernetes.
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"