At core conversation session by @kgoel at DrupalCon LA , 2015 on "Pain points of learning and contributing in the Drupal community" , several people mentioned that they don't like IRC and they don't get on IRC.

During core mentoring at PHPWorld and people from other Open Source community said that they don't use IRC and its 1990's chat client which is way too old to use in the Drupal community and why Drupal still lives on IRC.

Problems with chat, regardless of technology used

  • Too much overhead to add new channels for ongoing projects.
  • Many channels don’t have ownership or moderation
  • No integration with our projects. Channels are made independently from the project
  • Cognitive load each time you return to a channel to see what's changed
  • Chat isn't necessarily the most effective way of communicating (versus issue queues, audio/video or face to face)
  • It risks being a significant time sink / distraction
  • Drupal is a global project and some contributors will always be in a difficult timezone compared to others
  • People's ability to participate in chat is affected by whether English is their first language

Concerns people have voiced about IRC

  • There is no scroll back/history/asynchronous conversation native to the platform (requires a proxy such as bip or znc or using a 3rd party service like IRCCloud). Issue applies to channels and private conversations.
  • Few high quality apps, especially for mobile devices (IRCCloud app is not entirely free)
  • The lack of a “user is typing” indicator slows down conversations (counter-argument: indicators not always reliable, may become a distraction / put people off writing a reply of their own)
  • Many contributors haven't used irc before, and new tools can be a struggle for even technical users (counter-argument: IRC webapps make IRC easier to use, but it is still more of a challenge than modern alternatives.)
  • Although possible, it is difficult to create hooks into third party services.
  • Usage is dropping on IT circles for maybe a decade now (IRC protocol is on decline)
  • Doesn't do voice, video calls or conferences
  • Lack of modernization for sharing files (Services like Dropbox, Google Drive are not preferable because it fragments the community and if any of these services die, the files are gone forever. The files are not either instantaneously available in the client)
  • Can't show media, like photos, maps, etc. (Support of media is dependent on IRC client)
  • Can't share stuff permanently. (ie, can't host shared media forever)
  • Doesn't support login by email address or phone or external credentials
  • Can't login from multiple clients and share username without magic like nickname aliases

Proposed resolution

Requirements for chat system:

  • Open source
  • Backscroll/offline History
  • User typing indicator
  • RTC (audio/video)
  • Bot integration
  • Mobile support
  • Future integration with d.o/projects

Possible solutions:

1. Create/switch to Matrix

Matrix is an open standard for decentralised communication, providing simple HTTP APIs and open source reference implementations for securely distributing and persisting JSON over an open federation of servers.

  • Pros
    • Open standard/API
    • WebRTC compliant/superset
    • Various ways to connect or integrate
    • Has all the current "features" of IRC + more
    • Integrates with existing IRC servers + channels to facilitate migration or keep usability parity (i.e. support stubborn people who still want to only use IRC).
    • Standardizes user identifiers/authentication (e.g. which would allow for easier discoverability and the ability to initiate chats with other users.
    • Allows for future d.o integration (i.e. web based RTC) and possible per project/issue chat "rooms"
    • No need for "user creation" as this could be tied directly into simply using their current d.o account/authentication.
    • Read their FAQ for more info.
  • Cons
    • Not "IRC"
    • Newer technology?
    • Requires a little bit of setup to create our own "homeserver", but this is rather trivial and well documented. A "homeserver" really only helps to facilitate the storage of data, provide authentication and RTC discoverability; most of which is automatically handled. It's really just a matter of setting up the proper config.

2. Keep existing IRC

  • Pros
    • We currently use it
    • Open standard/protocol
    • Multiple GUI applications
    • Many other FOSS projects use IRC, so contributors to those projects can easily join the Drupal channels
    • Optional user creation, no register user required for use
  • Cons
    • Old - lacks modern features needed
    • No API/automated integration (bots must be manually constructed and hosted somewhere)
    • No history/offline history built-in
    • GUI applications - inconsistent implementations (i.e. what "features" are provided)
    • Optional user creation, required if you want to keep a "consistent" user identifier

3. Do #1 and #2.

Other solutions mentioned - Free/paid services:

  • is another Open Source chat service, locally hosted slack clone / free SASS. Currently has dozens of FOSS servers, clients (most popular client is and integrations, including IRC, GitHub, and much more!
  • Github/Gitlab integration makes this a place for FOSS chat. Has been bought by GitLab and will turn FOSS during summer, to allow people to use it as a locally hosted slack clone. Free service.
  •, SAAS. Meets most of the features requirements listed, but does not meet goals related to FOSS/privacy philosophy. May require paid service.
  •, SASS. It meets most of the features requirements listed. 3rd party integration, but does not meet goals related to FOSS/privacy philosophy. May require paid service.
  • is a WhatsApp clone, with Open Source clients and a proprietary server. Supports channels, groups and private conversations and has many bridges/bots, including for IRC. Since recently, also supports voice calls. Still, it's less feature full than the others. Completely free service.

Other solutions mentioned - Self hosted software:

  • is another Open Source chat service, locally hosted slack clone / free SASS. Currently has dozens of FOSS servers, clients (most popular client is and integrations, including IRC, GitHub, and much more!
  • Rocket.Chat is another chat service, locally hosted slack clone, the most popular of the FOSS kind for big companies and organizations.
  • Mattermost is another Open Source chat service, locally hosted slack clone.
  • Github/Gitlab integration makes this a place for FOSS chat. Has been bought by GitLab and will turn FOSS during summer, to allow people to use it as a locally hosted slack clone.
  • Zulip is another Open Source chat service, locally hosted slack clone.
  • Lets chat, F/OSS. Node+Mongo, meets many of the requirements listed, but not as integrated or used as slack. Also needs to be hosted locally.

Other solutions mentioned - IRC magic:

  • Waartaa is an open-source solution with a responsive web interface based on the MeteorJS library for browser-to-server communication and syncing. It connects to IRC on the back-end, giving users the choice of using the web interface or a traditional IRC client
  • Convos works on top of IRC. F/OSS, has backlog, desktop notifications, content previews.
  • IRCCloud Has a desktop, android and ios app, has all the features above and there are several people using it already.

The why and why not

  • Pros
    • Some developers already have Slack app running
    • Has many of the above requirements
    • @todo
  • Cons
    • Closed source/proprietary
    • In it for the money:
    • "Free" plan is intended for small to medium sized business/teams (Drupal is anything but)
    • Requires users to register
    • Architecturally has several types of limitations since their service is based on "small to medium" sized teams:
    • Prohibitively expensive to get backsroll
    • Does not have all of the above requirements
    • Does not and will not support Open Source Communities
    • @todo

Remaining tasks

  • improve issue summary summarizing what has occurred in conversation.


xjm’s picture

Title: Replace IRC with Slack or Open Source version » Evaluate whether to replace drupal IRC channels with another communication medium
kgoel’s picture

Issue summary: View changes
kgoel’s picture

Issue summary: View changes
Antti J. Salminen’s picture

Personally I really do not want to see this happen. Thank you for the well-thought summary as it already has many of my objections covered. I'd add that IRC being an open protocol with huge amount of open source support means it's extremely flexible.

Making chat participation easy can be achieved building on top of IRC. It's possible to set up all kinds of web-accessible interfaces and even gateway bots between different services so I'd argue things can be improved without a migration to something else.

There are also ways in which these tools like Slack/Hipchat raise the barrier of entry rather than lower it. Most of them, like Slack, require registration. Everyone stays on their own little island that you have to separately register to. With IRC there is no registration and with so many open source projects on Freenode you may well already be set up to just join another channel.

I wasn't convinced by the arguments put forth by the WordPress team at all. The only one that I do think is a good point is about the maintenance overhead.

Regarding the WordPress participation: I think it's too early to assess the impact fully. The claims I've seen about increased participation were also made a pretty short time after the move so I'd like to know what's the latest on that.

YesCT’s picture

Issue summary: View changes

a little bit more issue summary detail. more to be added later tonight.

jaredsmith’s picture

Issue summary: View changes
ricardoamaro’s picture

Issue summary: View changes
YesCT’s picture

Issue summary: View changes

adding some stats, and things to keep in mind about stats.

japerry’s picture

Issue summary: View changes
japerry’s picture

Issue summary: View changes
Antti J. Salminen’s picture

Issue summary: View changes
Antti J. Salminen’s picture

The only source I've been able to find that has claims about WordPress seeing any sort of increase in participation after switching to Slack are these tweets.

Later on in the thread it's said that it's just a guess, but maybe we could get some actual numbers as they were offered.

Antti J. Salminen’s picture

Issue summary: View changes
mfer’s picture

One thing to consider for the tools is that with IRC you can have channels open for numerous projects while tools suck as Slack are focused on a single project. This affects cross project interaction.

Crell’s picture

I find Slack useful for in-group communication. Private groups, company internals, etc.

For a public group that we want to make easy to wander through, IRC all the way.

davidhernandez’s picture

I mostly agree with Crell. I'm not a slack user, so I'm taking a look now. It appears to be invite only. How would we handle that?

Would we make one slack team and then mimic the same channels in it that we have in IRC?

japerry’s picture

Even though I think slack solves most of the issues, personally I don't think we should be specifically using slack. The invite only thing is, well, uninviting. However, there are some open source solutions which we could investigate. (Like lets chat) What would be really cool is having chat tied to the account.

Hipchat is another option mentioned, and if Drupal infrastructure is moving towards crowd, we could use that and get user integration for free. While in principle I like the idea of an entirely F/OSS option, it also requires our own infrastructure, which has its own costs. Using something like Hipchat (especially if its free for us) would keep in line with our chat budget, which I think is currently $0 ;)

davidhernandez’s picture

Does anyone know who controls or

I created and Feel free to try to join them and play around.

joshuami’s picture

I'm checking into who created It was not Association staff, but I have reached out to Slack to see if we can transfer that ownership.

I'll do the same for HipChat. Even if we do not go that route, it would be nice if we understood how those channels were being used.

davidhernandez’s picture

One thing we noticed is that slack requires an invite and displays your email address to everyone. So if you want to join it will display it to others. I haven't seen a setting to hide them. We assume there is a better way to handle that since wordpress has direct integration.

Also, Cottser was very upset that his username had to be all lowercase. :P but I imagine spaces would be a problem too.

Tezcatlipoca’s picture

Hi guys... this is a thoughtful discussion. I can see you all are putting a sufficient amount of consideration into the concept of moving on from IRC. Being rigorous is important. But I have to tell you: I think it's a no-brainer. And more I think every day we practice relatively insufficient communications, we fall behind emerging web technologies and also put our community at risk to poaching by other evolving communities and technologies (and let's be honest the only thing that makes us truly special and relevant is the community we have here and through it the work we all put in).

I have a few things to say on this subject. Slack in a uniquely innovative piece of software (to my mind) that satisfies the goals of text-centric communication in a number of elegant ways. And say you don't always want to limit it to text--no one will argue that text is always best method of comm: integration of Google Hangouts for instance, allows for a quick and easy switch to more personal communications--considered all together it's the type of communications system we were promised in sci-fi.

Beyond that it's many other integrations official and community contributed make it ideally suited for so many of the things we do here. We could let each other know what we are currently working on. We could integrate our issue creation and tracking. Github integration could allow us to work and talk together seamlessly--offering an unprecedented ease that would allow us to jump over all the cruft and time sinks and just get more done together! And we wouldn't have to give up the freedom of our self-hosted git repo. Say we just allow pulls and merges to a mirror on github--perhaps the existing one that exists for other reasons (an example demonstrating that people will not sit idly by and allow modern conveniences that make life easier to go unutilized). Then we just merge in the changes. This is typical of the kind of trade-off (or lack of that we would be making in going to Slack).

IRC is a clunky 27-year old protocol having changed little in that time with a stagnating software ecosystem; it can really evolve no further to utilize it on that foundation. #drupal and the sister channels are really great. Now, I hate IRC and describe it overall as "a generally bad place where dreams go and die." That's clear hyperbole, but we all know it's less than ideal and its faults restrict both the people that use it and the communication that goes on there. The reason #drupal is great is for the same reason Drupal is great. We happen to have very many good and invested people. And they are for the most part just bearing IRC, tolerating it. Just because that's how it works, because that is how it has worked.

We have a chance to really grow as a community in quickly moving to a modern communications platform. Slack is fun! My experience is people love to use it--all kinds of different kind of people. It would open us up to a whole new world. None of that can be said with IRC. But with slack, again we don't have to give up the passable solution that's now in use. "slack-irc" a community contributed module/integration could allow us to communicate between the two, the existing IRC channels and the new Slack. And more if people are attached to their clients or dislike Slack as software, Slack provides easy and free access to the Slack and channels through the existing IRC client of choice.

I understand there is a concern that Slack is not open source or decentralized. That is significant. But it is very open in many other ways--in addition to being free. It is highly configurable with a strong API that allows us to build into it nearly any functionality we could want. Even just in the core it's built from the ground up to allow configuration and programmatic improvement allowing us to tailor it to our needs and goals. If you haven't give Slack a fair shot, just try it, because I can talk all day but none of this and much more I am leaving for lengths sake won't be apparent until you've done so. Which is a great segue...

Tezcatlipoca’s picture

This is how I came to find this discussion: I've recently become involved in a number of webdev slacks that are quickly changing a lot in how I work and spend my time. Naturally I sought to find a Drupal specific Slack--official or unofficial. I could not find it. I was so very surprised.

This afternoon, I decided "no longer." I created one called "DruPals" a light-hearted and quickly made up name for something I hoped would be similarly lighthearted community around the Drupal that I love. A few hours and one Drupal site later. I have created the Slack and a site to facilitate and automate invites/registration.

I went to the IRC channels to recruit people late on a Friday evening (not the best time to do so) and I was directed here to read this conversation and make these posts.

So to keep this from getting any longer. I very much hope you'll join me. This doesn't ever have to move further toward the goal of being an official solution. I would be happy if simply I had some Drupal folks to talk to in a fun environment like Slack. But also, if you want to try on Slack as a possible solution to move to, here is an opportunity. Thanks for reading. Hope to hear back from you... maybe in the Slack!

davidhernandez’s picture

One point in favor of Slack is it has built-in IRC integration, which I enabled on So far Cottser is the only one who tried to connect over IRC, but it did seem to work. I also added josuami as an owner so he can investigate integrations and other such things. The immediate concerns that are all show stoppers are the invite-only aspect and email addresses being visible to other users. (both may have solutions through integration.)

The other thing that would greatly concern me about trying to use Slack for our community is scalability. Just looking at the interface, I see how this can work well for a team, but I don't see how it doesn't become unmanageable with hundreds/thousands of team members.

joshuami’s picture

Issue summary: View changes

Hi all, I had a conversation with Slack support today. They are excited to help us in whatever level of demo or integration is appropriate. To that end, the account has been changed over to so that we at least hold the namespace.

I've also talked with Slack about what scalability and privacy would look like. They do have some sort of public rooms and or community teams planned in their roadmap, but they are still working through those requirements. If we want to provide them with requirements that would make sense for the Drupal community, I'm happy to act as a conduit.

While I'm not convinced just yet that we *should* move to Slack for the community, I do think it provides a lot of great functionality.

I have been quite impressed with its use by Drupal Association staff for internal collaboration and for external collaboration with the community members that are part of the DrupalCon planning. They have been using Slack for planning the DrupalCon programs starting with LA. Drupal Association staff have been using slack since November. Given that we have a good mix of technical and nontechnical employees, Slack has been incredibly easy to implement within our organization. (Far easier than setting non-technical users up with IRC for instance.) That same ease of implementing Slack is not likely to be the case for a community roll out. I share David's concerns about scaling that administrative interface to hundreds of users.

Does anyone have a good sense of how many unique Drupal IRC users exist? I'm curious just for the sake of knowing how big we need to think in considering alternatives to IRC.

In the meantime, at least we own the namespace for testing possible integrations.

Mixologic’s picture

Issue summary: View changes

Here's another open source slack clone:

kattekrab’s picture


"Does anyone have a good sense of how many unique Drupal IRC users exist? I'm curious just for the sake of knowing how big we need to think in considering alternatives to IRC."

This might be something we could ask the freenode ops to find out for us?
The biggest channels, #Drupal, #Drupal-Support and #Drupal-Contrib - but there are hundreds of smaller channels, and I know many people aren't on the big channels for various reasons.

japerry’s picture is another suggested chat medium.
Gitter works from github.

geerlingguy’s picture

One good point of reference—a reason why you can pry IRC from my cold, dead hands—LimeChat (on 8 different IRC channels with two networks, been running for a few hours today) is using about 30 MB RAM. Slack, with about 10 channels across two 'teams', is using 490 MB RAM.

Lightweight, many of these other solutions are not... that's one major concern as I look at my Dock and now see Adium, LimeChat, Skype, Slack, and HipChat clients all required for different projects. I hate the idea of requiring terabytes of wasted RAM across the Drupal community just so we can get a few more likely-inactive-users signed up for official chat channels.

The sell has to be a lot more compelling than inflating numbers of logged-in users. #ansible generally has 1,000+ users in the room, but only a couple hundred have ever posted much, and far fewer actually use the room for more than 'StackOverflow Instant Q&A' (more like the #drupal-support channel than #drupal or #drupal-contribute, both of which are more community-oriented).

Cottser’s picture

Slack is one alternative that we've been testing off and on it has an IRC gateway.

geerlingguy’s picture

@Cottser - If the IRC gateway is enabled (and works well under load), then that would negate some of my earlier arguments, since I (and others) could continue using IRC clients with Slack.

Cottser’s picture

It's enabled, I tested it, not sure on the load part.

cferthorney’s picture

As a potential work around for the whole invite system that Slack integrates, the Laravel people have created an auto invite system of sorts over at, it would suggest that some sort of integration can be rigged together even if someone within the community had to write something from scratch from an integration side of things? (I've not even begun to look at that so don't even know what is or isn't possible with their API's)

Kind regards

realityloop’s picture

Issue summary: View changes
realityloop’s picture

Issue summary: View changes
lsmith77’s picture

what about talking to about a special deal for drupal related channels to be part of the free package?

fuzzy76’s picture

While I personally love Slack, I really don't feel comfortable with Drupal going all in for it as a recommended communication channel. Do we want to become dependent on a proprietary commercial system?

Pol’s picture


I'm also willing to test slack, could you invite me please ?
Here's my email address:

Thanks a lot !

kgoel’s picture

I have added "Technical Working Group" tag so someone from the group or group can evaluate if it's possible to replace IRC or not.

Pol’s picture

Issue summary: View changes
rteijeiro’s picture

I think it's a terrible mistake to switch from IRC to a non-FLOSS solution just to "make chatting easier"?. I don't think we are going to solve a problem (if there is a problem) just switching or adding more tools to our daily basis.

I think it's just about culture. There are people that like synchronous communication like chats and there are other people that like asynchronous communications like email.

That's all.

I think we don't need more tools.

fuzzy76’s picture

FWIW, I think Mattermost and "Lets chat" looks like better candidates. Most of the advantages of Slack, running on an open implementation.

chx’s picture

Suppose They Gave A War and Nobody Came.

Sure, somebody (who?) claims X is the new schnizzit and then the community shrugs and continues to use IRC. As mentioned on Drupal SE meta "Drupal communities are a bit balkanized, so often top-tier Drupal contributors are most active in their own local channel, or the project specific channel which interests them most—the maintainers of Drupal Commerce hang out in #drupal-commerce for instance" so you'd need to fight that down one by one. Good luck.

This issue should be won't fixed as it's impossible.

wizonesolutions’s picture

Perhaps Sameroom is worth checking out?

You can open "tubes" to bridge chat platforms. So, in theory, people who like IRC wouldn't have to switch. Haven't tried that combo, but might be worth testing?

wizonesolutions’s picture

Re. @davidhernandez's concern about email, WordPress has set up a cloaked email. That's similar to what we did for Git. So many our auto-inviter can do something similar. This would require setting up an email relay, but if WordPress can handle that, we probably can do. They should probably be distinct from the Git addresses and ONLY work for people who've actually signed up for Slack. And, like WordPress's, it would only actually accept email from Slack's servers (so no one can use them to email people against their will).

Seems like a good solution to that issue. Maybe we can ask them how they did it.

chx’s picture

> This might be something we could ask the freenode ops to find out for us?

I can try asking freenode staff to query how many users are on #drupal* but it might not be something they can (easily) do. Note this is not something the Drupal group contacts can do -- we have very few powers the users don't. Mostly just enough to kick and keep trolls out.

kgoel’s picture

Issue summary: View changes

I have removed "request to join Drupal Slack channel" from the issue summary because it doesn't say contact who. I have received requests for joining slack and I don't have any control over that and I don't know who is moderator/admin for that. Users are mistaking me as moderator since I created this issue. I don't want to be rude to them by not replying and I can't reply to all the emails :)

basic’s picture

Another option, just to throw it out there:

Telegram has channels now, and clients on almost every platform.

heddn’s picture is open source and has clients for many platforms.

Crell’s picture

lsmith's suggestion of contacting seems like the best one yet; still IRC under the hood, but a nice client since that seems to be the biggest gripe people have with IRC. (Other than it not being hipster enough, which I ignore as a criteria.) That's nice and low-effort. Anyone want to give that a shot?

Pol’s picture

+1 crell. I discovered irccloud last week (@drupol on irc).
I bought the subscription right away.
The android client is very good too.
Cant live without it now.

Pol’s picture

That said, Telegram and channels are super good too.

fuzzy76’s picture

Atleast half of the concerns in the issue summary are still valid on irccloud though.

realityloop’s picture

@heddn I tried Zulip today on one of my servers, the desktop client on OSX at least has no way to connect to a private server, also the UX is very confusing (I'd almost say worse than IRC).

It also allows anyone to create private streams which I don't think is a good idea personally.

tim.plunkett’s picture

An article on the React community moving away from Slack:

tim.plunkett’s picture

Ooh, even better, they posted the research they used to make the decision:

Antti J. Salminen’s picture

The concern listed in the summary about IRC lacking scrollback/history doesn't seem like a very strong argument when it's a feature that's easy to have even without bouncers. It would even already be possible via druplicon but has not been enabled for the drupal contribution channels by choice.

Based on the Reactiflux and freeCodeCamp experiences described in the link in #55 Slack seems like it's probably a non-starter...

Solutions that don't get rid of IRC but help with the concerns about the barrier of entry seem like the best to me. Working towards just getting a better Freenode webchat would be ideal in that all the open source projects on the network would benefit but that's probably a pretty challenging way to do this.

elwayman02’s picture

Tim, I'm happy to answer questions about the research I did...thanks for linking it here! I'm pretty happy with Discord right now...the onboarding experience is great and barrier to entry is low.

webchick’s picture

Also there's like barbarians and shit:

Scenic gamer background

I played around with this for a bit and it's very interesting. The fact that you can jump to voice at any time IMO is hugely beneficial, esp. for gnarly technical discussions and/or highly aggressive convos that are going off the rails.

One immediate question I'd have, knowing about various incidents involving gamers on Twitter, is how private is a given Discord server? Are we going to get numbskulls barging in and using l33t sp34k and threatening to beat up women? (IRC is definitely not immune from this problem at all but for whatever reason—probably a crap ton of work on Freenode's side—we've been really lucky with this.) Another one would be, are we impacted if one Halo clan and another Halo clan decide to smack each other around? (We have gone down too when neighbours have been DDOSed on Freenode, OSL, etc. in the past.)

markie’s picture

FWIW: Here's the link to the WP intro page.

wizonesolutions’s picture

I predict WordPress is going to hit the same limitation as React did pretty soon.

Discord's probably worth looking at. It's not Slack, but IRC isn't Slack either. The throwaway joins are a pretty cool feature. Much less of a barrier than Slack.

Does Discord keep email addresses private? That would mean we wouldn't have to run a purpose-built relay to mask them like WordPress does for Slack.

realityloop’s picture


Yes with Discord email is hidden, even to the server owner..

marcvangend’s picture

I just came across this post which lists a couple of reasons why you should not use Slack for FOSS projects, and names irccloud as the best alternative.

Derimagia’s picture

Another benefit of slack is that they bought Screenhero a few months back and are working to integrate it in. I think this would be a big plus for cooperation.

Edit: I didn't see the article about React moving away from slack. That's a real shame. My point is moot.

japerry’s picture

I just came across this post which lists a couple of reasons why you should not use Slack for FOSS projects, and names irccloud as the best alternative.

IRCcloud costs money. Its a non-starter for 'removing the barriers' to entry. Contributors shouldn't (and won't) be expected to pay money just to communicate.

heddn’s picture

IRC Cloud has a free option. And for most people, that is fine. They don't need to stay online 24/7. Which, from what I can tell, is the only benefit from paying 5/month.

Cottser’s picture

But then we lose the asynchronous benefit right?

fuzzy76’s picture

@heddn That solution won't satisfy even half of the concerns mentioned in the issue summary.

heddn’s picture

Status: Active » Reviewed & tested by the community

Here's the thing, IRC Cloud by itself isn't the solution. I think that IRC is the solution. Because it is open source and has multiple clients. Not all of which are terrible. If the barrier to entry into IRC is its complexities, solutions are being developed to overcome it. IRC Cloud is the best example I know of. If you want a proprietary solution i.e. Slack, then you can, if you want connect it to IRC. Flexibility for our diverse community is critical. The biggest knock against IRC has been its high entry-bar. And for the past 7 months, we've not found any better solution than IRC.

So, if the entry-bar is lowered via solutions like IRC Cloud, what are feasible/reasonable solutions?

I'm not convinced we have consensus yet, or ever will have consensus. So, unless we want this issue to just be a breeding ground for rants, I'm going to take the tentative step and mark this RTBC. IRC works. It isn't ideal. But another solution doesn't exist. We can (and probably will) revisit this decision again in another 6 or 18 months. But until then, let's move on with other things.

Or maybe I'm wrong and I haven't summarized the rhetoric. Maybe there is a solution that has surfaced above or will surface by someone else in the next few days. In that case, feel free to move this back to "needs review".

Cottser’s picture

I don't think this is accurate:

If you want a proprietary solution i.e. Slack, then you can, if you want connect it to IRC.

Slack provides an IRC gateway but I don't think you can connect Slack to Freenode. But maybe I misinterpreted this :)

fuzzy76’s picture

@heddn This issue is still about the concerns people have voiced with IRC, as listed in the summary on top. Adding IRC Cloud on top as a "preferred" client still won't change the list of issues much (15% of them maybe).

And @cottser is right, Slack can't connect to IRC but IRC-clients can connect to Slack. Most of the third-party solutions suggested here (including Slack) has a lot of features that IRC-servers doesn't support.

webchick’s picture

Status: Reviewed & tested by the community » Needs review
ztl8702’s picture

@cottser You can "connect" Slack to Freenode by using a bot to forward messages between those two systems.

Antti J. Salminen’s picture

Wanted to expand on some of the concerns I see with moving to one of the mentioned services. The Hacker news discussion of the article that @marcvangend mentioned in #62 has more on some of these.

Concerns with choosing one of these services

Here are some concerns I'd like to raise about going with any system that is hosted, closed source and a walled garden - be it Slack, Discord or something else. These services are completely under the control of the company that provides them. An example of this biting someone that just happened is that while Slack does list unlimited team size as a feature, it turned out there actually were limits for the Reactiflux community at least. The Bitkeeper episode in the history of Linux kernel development is another cautionary tale of what can happen when you don't consider these risks.

These companies can pivot, they can go out of business or they can come up with disruptive ways to monetize their product only after building a gigantic userbase. Possibly even worse, they can also fail to do so (see PlugDJ). Discord for example is a free-for-all service that seems to only have very vague idea of how they're ever going to make money. It would be wise to assume the pricing won't stay fixed and something like Slack deciding to charge everyone per-user would be problematic for Drupal to put it mildly.

Things like IRC/XMPP bridges can also go away later on in the life of these products. Once again the examples are many but just a few are Twitter getting rid of RSS, Tapatalk closing their API and Google Talk disabling federation with other Jabber servers.

The services often lack any support for Linux (let alone BSD). I think in an open source community some thought should be given to that. It's likely that more people than on average are on those platforms. Things like IRC bridges and web interfaces become the only option then and the user experience they offer is often second class. The option to use a pastebin looks very nice compared to the prospect of not seeing the pasted code in a clean way over a the bridge.

Issues with Slack

Besides the huge issue that Slack apparently doesn't support communities of this size as Reactiflux found out the hard way, I've seen some other limitations being mentioned for it:

  • The IRC bridge does not render many of the features correctly
  • Free Slack has a backlog limit of 10,000 messages which is hit pretty fast with a big community

Issues with Discord

It doesn't sound like they have a real plan for how they'll make money yet and their target audience is gamers, not software developers. This could mean they end up prioritizing features that are of no use to Drupal or even doing something that doesn't work for Drupal at all.

Some features they're lacking:

  • No IRC bridge
  • No search

Would switching from IRC actually hurt participation?

The Freenode network has 90,000-100,000 active users. Most of these are very likely to be interested in open source software. Making it harder to join for this substantial pool of people with relevant interests sounds like raising the barriers of contributing instead of lowering them. They are now just a /join away but won't probably start using 3 different services if WP is on Slack, Drupal is on Discord and PHP stays on IRC.

fuzzy76’s picture

Issue summary: View changes

I totally agree with the concerns about commercial services. We should not be tied to the survival of companies with changing priorities and business plans.

But this is not an issue with the self-hosted open-source solutions. After a brief research round, the only one of them that seem to support an open protocol for third party clients is Let's chat which has XMPP support. That would let people use any client that support XMPP (quite a few IRC clients do), and bitlbee if people really want a bridge.

I also wanted to add that lack of Linux support is a pretty moot argument for something that's primarily a webchat. If your browser can run it, you are supported. The apps aren't much more than a webview any way.

marcvangend’s picture

Issue summary: View changes

Thanks Antti.
+1 for mentioning that moving away from IRC may raise the barrier for people from other FOSS communities who are already on IRC. I'm adding a list of arguments in favour of IRC to the issue summary, feel free to expand it.

realityloop’s picture

@fuzzy76 Main potential issue I see with Let's Chat is that they say its for "Small Teams", it seems like mattermost may be the best long term option, but it's still not perfect.

mlhess’s picture

This comment is in full HTML and has some IRC cloud embeds in it.

I talked to irccloud folks today. They are willing to work something out for us.

By default, they have buttons that we could add to our IRC page.

They have an inline javascript embed, which I have not put here, but we could use if we wanted to as well.

That will require a email and email confirmation before allowing a user in. However, they are open to doing an SSO with Drupal.

So the workflow would be something like
Non logged in users:
1) go to the IRC page on d.o see warning message that D.O will share your email address with IRC cloud
2) see listing of all channels
3) choose which ones you want to join
4) on IRC cloud, provide email address
5) check your email account and confirm.
6) Your on IRC in those channels

Authenticated users
1) Go to IRC page on D.O
2) See listing of all channels
3) choose the ones you want to join
4) You're on IRC in those channels

fuzzy76’s picture

  • Asynchronous conversation isn’t realistic short of setting up your own proxy.
  • Writing and maintaining tools are painful.
  • Mobile and native apps are mostly terrible.
  • The lack of “user is typing” slows down conversations.
  • Too much overhead to add new channels for ongoing projects.
  • Many channels don’t have ownership or moderation
  • Many contributors aren’t technical, and IRC can be a struggle for even technical users.
  • Although possible, it is difficult to create hooks into third party services. IE: creating a hangout in slack: /hangout.
  • No integration with our projects. Channels are made independently from the project
  • IRC is old
  • there is no scroll back/history
  • to get history, some people set up bouncers (such as bip or znc) or use a service (but that increases the barrier) like IRCCloud
  • IRC is difficult to use, for example
  • Setting up an IRC client is complicated
  • Depending on the client, doing common tasks such as getting a list of channels is complicated
  • Limited choices for some operating systems

That fixes 6 out of 16 problems listed in the issue. What about the rest?

If we do decide there is no better option than staying on IRC for now, I guess the IRCCloud integration is better than nothing. But we still need to acknowledge that it means leaving the rest of the problems hanging around.

mlhess’s picture

Too much overhead to add new channels for ongoing projects.

It is REALLY easy to add an IRC channel.

Many channels don’t have ownership or moderation

This would be true in any service. It takes people to own a channel.

Many contributors aren’t technical, and IRC can be a struggle for even technical users

This would be resolved by irccloud.

IRC is old

What does this mean?

Depending on the client, doing common tasks such as getting a list of channels is complicated

I think this is solved.

Many of the other items up there are not solved by any solution but rather work on top of a solution. I am also not saying that IRC cloud should or is the solution, but it solves many of the issues above, and could be implemented without many changes or much work.

Maybe that we need a solution for folks getting help that includes realtime, forums, and communities.

joelpittet’s picture

Issue summary: View changes

Removing 'IRC is old', it's not a valid reason for anything. Also may be a benefit because it is also fairly stable, tried tested and true;)’s picture

I don't know if anybody cares but I won't use software that's a) run as SASS by a potentially unreliable 3rd party or b) not Open Source within the context of communication of an Open Source project. That feels just wrong to me.

IRC just works fine for me.

But then: the only channel I really use nowadays is #drupal-security. Assuming that stays on IRC, the rest can move to #drupal-hipster elsewhere.

heddn’s picture

re #81: that's fine. Using something like irccloud gives folks like you that flexibility. But it is still IRC, so it also gives folks who want to use Adium, LimeChat, HexChat, Pidgen, etc their choice of options too. But the positive to using irccloud is that for folks who do not have your qualms and just want to connect to the larger community, we can lower the entry bar. It would give another entry into our community. And more entries is usually a good thing.’s picture

I don't share the belief that lowering the barrier to entry is a good idea. probably is one of those "potentially unreliable 3rd party providers".

You of course are free to use it.

joelpittet’s picture I tried to join #drupal-hipster yesterday, I was the only one there... I'm guess it worked? :P

greggles’s picture

Issue summary: View changes

I've update the issue summary a bit.

I restated a few things and separated out some items that seem like general problems that are not specific to irc.

I removed "irc is difficult to use, for example". That seems vague and redundant with some of the others and rather subjective. I find irc quite easy to use compared to slack, especially for the number of rooms that I join. When I've tried slack and had more than ~5 conversations open it became hard for me to understand which conversations had unread messages.

I added a note asking for other examples of third-party integrations that are useful other than "/hangout" ? The ability to quickly generate a hangout url feels like a pretty weak feature of these kinds of tools.

I reordered the list to group together similar issues. A lot of these feel like the same problem said in a different way which makes irc seem worse than it is. I didn't delete all of the duplicates just yet, but I think a few more could be deleted/consolidated.

I also added to the subjective part about proposed solutions to indicate that while some of the SAAS solutions like Slack solve many of the feature-requirements they do not solve some of the privacy requirements and philosophy goals. is an example of a privacy concern related to slack, for example. I'm not sure that specific change would be relevant for our organization, but the fact that they can make that kind of change in the manner a typical corporation does (without user feedback until after that event) makes me rather wary.

I think that irccloud is pretty awesome for some use cases (I've used it a bit and didn't pay for it).

I use a mix of hipchat, slack, and irc for work. I do not think that a solution like hipchat or slack would be a good solution for the Drupal project in general. They are focused on solving different problems for different communities. irc, and freenode specifically, is directly focused on serving communities like ours so they are more likely to have philosophies and ideals that match ours.

fuzzy76’s picture

First of all, I just need to congratulate @joelpittet for being able to say that he hang out in #drupal-hipster before it was cool. :)

On a more productive note, there is also which is a sort of "open source, selfhosted IRCCloud". I have no idea if it is scalable enough for Drupal to host it, but it seemed relevant here. It does have multiple user support.

japerry’s picture

Issue summary: View changes

Added Zulip, another self-hosted option. Also added that the DA, in our discussions so far, has been to not want to host chat internally.

greggles’s picture

I'm not sure what "self hosted" means in this context. Is our current irc self-hosted? Can you expand on that a bit?

fuzzy76’s picture

I guess you asked jasperry, but I think both he and I mean chat clients that uses a backend running on d.o infrastructure in order to provide a persistent connection and a unified user experience. In that regard, the current IRC is not "hosted" at all (it leaves the client and connection maintenance up to each user, which I guess is part of the problem).

greggles’s picture

So maybe another way to say that is that it shouldn't increase the burden on the Drupal project (DA, infra team, etc.)?

fuzzy76’s picture

In that case, a lot of the proposed solutions are off the table. As far as I can tell our main choices would then be:

  • A commercial / proprietary solution like Slack or Discord. The downside is that it would leave us at the peril of a company.
  • IRC with a commercial / proprietary frontend to make it easier for beginners. The downside is that it's still IRC with all its shortcomings (detailed in the summary).
  • Switch to another open protocol (I guess Jabber is the only real candidate?). Just realized this hasn't been mentioned. I guess it's just... not very sexy.
kattekrab’s picture

personally... I kind of don't understand why folk find IRC so much harder to use than Slack. But I'm willing to accept that's my shortcoming.

What I do find odd - is that there doesn't seem to be an IRC client that has stepped up to the challenge posed by Slack. Or have I just not looked hard enough? I think Slack is definitely innovating in the real time chat space. It's slick and user friendly, and has some nice features not found in IRC.

But I share all the concerns raised about it being non-foss and in-appropriate for an open source project.

@greggles - awesome work on synthesising and refining. Thank you!

greggles’s picture

Issue summary: View changes

Thanks Kattekrab :)

As promised in #85 I went through again and consolidated items that were redundant.

basic’s picture

I'm writing this with my own personal biases in mind:

My irc/znc bouncer box died over the weekend and prompted me to set up irccloud in the interim so I could get back to #drupal-infrastructure and my other IRC channels. After using it for the last few days, I don't think I will be switching back to znc any time soon.

What I do find odd - is that there doesn't seem to be an IRC client that has stepped up to the challenge posed by Slack. Or have I just not looked hard enough? I think Slack is definitely innovating in the real time chat space. It's slick and user friendly, and has some nice features not found in IRC.

@kattekrab -- irccloud is nearly there, the only thing missing is an officially supported desktop application. There is an unofficial electron app that is decent enough.

The irccloud interface is nice, and implements many of the "hip" features (inline images, :emoticons:, automatic pastebin, etc.), and usability improvements (async communication, web/ios/android/(unofficial desktop) apps, etc.). It also changes nothing about the underlying irc channels and configuration for those already happy with znc/irssi/textual/etc.

Third party services integration is something we rely on heavily in #drupal-infrastructure and is solved by running irc bots. Druplicon, drupalmon, jenkins, manatee, etc. There likely exists an irc bot for the integration(s) we are lacking.

The only remaining issues (#77 addressed my primary concern) with using irccloud as the solution are the lack of "user is typing..." functionality, and lack of built in search functionality. That said, with all of the discussion and potential solutions discussed this far, it seems like irccloud provides the most benefits while leaving the legacy intact.

heddn’s picture

+1 #94. That's what I've found since my computer died and I had to quickly replace it with another. IRC Cloud was just easy. And it still gives us IRC; so folks that want to use their client choice can. That is the beauty of IRC. It meets the most people where they are at currently, while still giving folks the chance to get some of the benefits of other softwares. I'm specifically thinking of all those capabilities you outlined in #94 that are similar to Slack. In the open world of FOSS, you are going to find it hard to find something so liberating as IRC. And the comments that it is so it is "old school" and "too hard" and "it is blocked at my place of work", do have options. And IRC Cloud isn't the only option. It is just the one I'm most familiar.

So, enough of that. What is next for this issue? Looking over the issue summary again, what are the outstanding items and next steps?

I'd propose as a next step that we just stick with IRC, because nothing better has offered itself up to us. I suggested that also in #68, so I'll let someone else take the bold step and decide where we go from here.

theamoeba’s picture

Issue summary: View changes
Gabriel Engel’s picture

Hi there, I am Gabriel Engel, the founder of Rocket.Chat

We'd love to to host a Rocket.Chat server for you for free.

I believe this would be the best possible option here. You'd support another free open source project and remain free to export your data move anywhere, either to host
Rocket.Chat yourself where ever you like, or move to another solution completely.

If you like to give it a goal with our cloud, please just complete the form at

You will have your server running in a few seconds, and you can get the links to our iOS, Android, OS X, Linux and Windows clients from our website. They are all open source projects too.

Please ping me if you have any questions!

realityloop’s picture

I know that Gitlab's roadmap is to deprecate mattermost in favor of Rocket Chat

greggles’s picture

@Gabriel Engel - thanks for the offer. One thing that I wonder about is Can the Drupal community rely that Rocket.Chat will still exist? It would also be good to know how Rocket.Chat might handle some of our existing needs like being able to have private rooms and moderate (i.e. kick) people.

fuzzy76’s picture

Just want to mention that seems to be a really promising open protocol / network which solves a lot of problems in one go (HTTP-based, federated and allows bridging to other protocols - Freenode is already available there). I don't really think it's mature enough for Drupal to consider yet, but personally I'm putting it on the top of my list of technologies to try out.

heddn’s picture

Status: Needs review » Reviewed & tested by the community

I'm going to mark this RTBC and suggest that the next steps are:

  1. For now, we are sticking with IRC.
  2. Create a new handbook page for suggested IRC Clients. This list should include web, fat client and mobile apps. Link to this new page from the various IRC pages.
heddn’s picture

Marko B’s picture

Lets not play this game again and again. Like drupal 7 and drupal 8 and then we moved to full OOP anyway, just waist of time and resources slowing us down.
Do you need more data then this?
Do you want to attract new people, young people who never heard of IRC and will run away from it when they see it, finding drupal just old tech.
We will again be late because some people don't want to change and we will be on loss because of it.

mr.ashishjain’s picture

What a fantastic conversation I came across while trying to get my hands on IRC [after procrastinating it for almost a year]. Thats the beauty of community, its exactly like "Democracy" where everybody is heard and interests are protected/respected.

I must admit oldage tech IRC is a push away for new joinees. Laravel using Slack too. That shows the evolving tech world is embracing new technological advancements on how they communicate rather than sticking to the age old tech. If we've options, why not?

We use Slack in our organization, but talking about the community, I think we do not need a commercial entity here, but open source, so 2 options seem best to me: Mattersmost and Letschat.

How about starting a voting?

larowlan’s picture

kevinquillen’s picture

Slack is the new hot, but there is no guarantee it will still be running 3-5 years from now. IRC will likely always be around.

Also, consider from that article:

"A few weeks ago, Reactiflux reached 7,500 members on Slack. Shortly after, Slack decided we were too big and disabled invites. There was no way for new users to join. Many of us were sad and upset. We loved Slack. Our community was built around it."

So yeah, there is no guarantee some suit at Slack wouldn't ever be like "hey, there's 45,000+++ Drupal users in the community channels! Cut it off and make them pay $7 a month per person".

Ryver, Mattermost and other Slack clones will have a life half as long as Slack.

Despite my hangups with IRC, its the best fit for anyone, anywhere, on any machine. Doesn't look as nice as the other options, but it doesn't need to, either.

mpdonadio’s picture

This is likely something that we will never have true consensus on, but I am with the crowd that despite its shortcomings, IRC is ubiquitous and works well for the community.

Perhaps, the best followup to this is an issue to explore if there are additions to Druplicon ( and that could improve the IRC experience for people?

andypost’s picture

+1 to stay on IRC

japerry’s picture

japerry’s picture

Status: Reviewed & tested by the community » Active

Similar to the github, forums, or other services, slack is already becoming pervasive within the drupal community. ( )

Let me elaborate a little on the 'self-hosted' problem: Chat is not an easy infrastructure item, especially when it comes to scale (over 100 simultaneous users). We've been lucky in that freenode hosts our IRC channels, meaning the Association doesn't have to spend any money on chat.

If its a requirement that we cannot self-host chat, it means we're relying on a third party to not only be able to host us now, but also scale as we grow adoption of the platform. My main worry with slack is that its been proven not to scale, with many large communities regretting the decision to switch.

However, open source may not be the solution here either. Can Rocket chat serve 30,000 users? If we're using a SaaS solution, the open vs closed debate is less important IMHO.

kevinquillen’s picture

slack is already becoming pervasive within the drupal community.

Was pretty dead when I was in earlier in the week; and as you said, Slack does not scale.

What is the main motivation to making the community shift chat protocol/platform? User engagement won't be solved by the software. Is the perception that IRC is scary or hard to use? I'm playing devils advocate.

Crell’s picture

Kevin: Honestly I think it's mostly "IRC is scary and hard to use". "Newbies don't know what IRC is, they use WhatsApp". Or whatever. Secondarily, it doesn't have emoji. (Whether that's a bug or a feature is rather subjective; I consider it a feature.)

Personally I see no significant issue with IRC that isn't solved by

1) sticking an IRC web client on a web page somewhere
2) Pointing people at IRCCloud

(At least none that don't exist in any semi-real-time text medium by definition.)

Honestly, we don't even have to tell people that they're using IRC. They're using "Drupal chat", at Which just so happens to be one of a hundred web clients for IRC that is setup to talk to Freenode. (Or something similarly smoothed over.) Yeah, telling people to go get mIRC or Colloquy isn't nice, but that's not an issue of IRC itself.

Gábor Hojtsy’s picture

I am a happy customer of irccloud. The reason I started paying after years using IRC with various clients is my internet was bad for a while. It kept throwing me off the channels and it was very hard to hold a conversation. I needed a bot for me so I can read things from the time I was offline. Instead of spending time on trying to set it up myself (which we cannot ask people to do), I started paying for my own good (which we cannot ask people to do either). It was an extra benefit that irccloud comes with a mobile client as well that works relatively well. One definitely great thing about chats other than IRC is that you have a scrollback by default and your presence is much less connection-bound.

Pol’s picture

+1 to stay on IRC but as Crell said, pointing people to IRCCloud or something user friendly would be great.

fuzzy76’s picture even has a nice embed option (even though it lacks the persistent connections of IRCCloud).

diqidoq’s picture

Let me keep out the IRC pro/con part because, IMHO, I think it is too early to let this pro/con decide here on a much broader asked question to discuss, in a long term. This awesome article and carefully written questionaire is about thinking outside the box, so to simply vote for staying with IRC is contra productive. First, we should take a deeper look into ALL alternatives. Don't get me wrong, I am an officially IRC and terminal chat (irssi) advocate for the most and if it finally comes to the conclusion that IRC is still THE SHIT, I am the first applauding. But that should not be the point here yet, first things first. Not without discussing all opportunities and newer developments carefully. What if we look around and find a combination of both? Who knows? Today all is possible. When SASS came nobody thought of LESS and when LESS was there, nobody thought of that SASS would come back so fast. Today is different then the time when IRC was born. If it would be possible to combine mattermost users and IRC users in the same channel, e.g., well ... I would immediately sign it!

BTW: for the Slack vs mattermost supporters, here is an interesting read:

And BTW (2): What did I sad some lines above about IRC combined in ... Mattermost v1.1: Now connects to IRC, as well as your in-house applications

Apart from that I certainly would underline the last paragraph from here #107 which isn't against a combination of anything ...

Last but not least: It is actually no *decision* needed, it is just a question of how to improve the experience without leaving IRC, since there are already options to get best of both worlds.

fuzzy76’s picture

Sorry to say, but bridging through a single bot connected to IRC is close to useless for doing actual discussions across networks. The absolute minimum for a bridge should be that everyone sees all users as a user, not seeing half the channel hidden behind a bot. If not, you're ruining nick lists, presence notifications, autocompletion, private messages etc.

Matrix already bridges the entire Freenode network with real clients, and is actually the only one I've seen that accomplishes this. I guess this is because their bridge is linked into the Freenode network the same way a regular IRC server is.

I use this daily. There is also an option for doing it the other way around, allowing IRC clients to connect to a Matrix server using

freelock’s picture

+1 for -- it's an excellent system, far more open than Slack, can be set up with guest access and public history, is already bridged to Freenode (I'm in #drupal and #drupal-migrate right now via Matrix), the bridge shows actual users on both sides, it meets/exceeds all the other desired improvements over IRC. There are great mobile clients and a fast-growing ecosystem.

We also use it heavily as the backbone for DevOps on our Drupal sites. It can be entirely self-hosted, people from multiple servers can interact seamlessly across any number of rooms, etc.

To check it out, you can join the #drupal Freenode room by going here:, and creating an account (Freenode-bridged rooms are not configured to allow guest access or history by default).

Best thing about this is that people can continue using IRC if they prefer, and won't miss out!

diqidoq’s picture

Well, maybe you both misread my post, but that was actually exactly what I was after by mentioning other options. Maybe you misunderstood that I had no preference here persé, but simply took some fast picked examples out of the web only to point to the same issue behind like you: that both combined is possible and no decision against IRC is needed. But maybe you both are referring to other posts before me, then please use #Nr. references to declare that. Otherwise the reader assumes you reply to your predecessor in the queue.

YesCT’s picture

Issue tags: +IRC, +slack
lpalgarvio’s picture

Telegram -
Centralized, clients opensource, server closed
Can create channels and groups, with join link and supports bots.
Has webclient and mobile apps.

Bridge IRC to Telegram:

Mattermost also supports bots, has mobile apps, server and webclient, integrates with Redmine, Kanboard, Jenkins, GitLab, GitHub (service) and more.

Bridge IRC to Mattermost:

Rocket also supports bots, has mobile apps, server and webclient, integrates with GitLab, GitHub (service), Telegram and more.

Bridge IRC to Rocket?:

lpalgarvio’s picture


For our Portuguese Community ("Drupal Portugal"), we are currently using with great success a bridge between IRC and Telegram with the opensource project FruitieX/teleirc deployed in a VM.
We have a bot and a channel on IRC and on Telegram.
Online for about 10 days now.

IRC: #drupal-pt
The bot is named Druplbot and can map as many IRC channels <-> Telegram groups as needed.

We are looking into additional synchronizations to Hangouts and/or other protocols and considering additional tools.

lpalgarvio’s picture

Issue tags: +Telegram
lpalgarvio’s picture

Slack doesn't seem to support per Channel admins.

With that in mind, I think you can cross out entirely the Slack solution as communities need some independence.

freelock’s picture

-1 for Slack... a closed-source SaaS is not a good fit for an open source project.

There's not really any decision needed to use Matrix -- I'm using it now, in several #drupal rooms. They just launched the main web app under a shiny new brand --, and it has most of what Slack does, but is already integrated to any Freenode IRC room you want to join.

While the bridge is hosted, the code running the integration is fully open source and published on github, and anyone can run their own copy of the bridge. I run my own Matrix server, and in other chat rooms where a substantial number of participants had switched over to Matrix, we were largely unaffected by the recent Freenode DDoS netsplit issues...

Compared to Slack, aside from the ability to easily self-host and federate transparently, there is no limit to the history that may be kept (Slack has a 10,000 message limit before you have to upgrade to a paid plan), we can open rooms to guest access, and the bridge is far more transparent/less intrusive on the IRC side. The main current downsides is lack of IRC presence (this is available if you run your own bridge, but caused too big a performance hit on so it's disabled -- the issue is that on the Matrix side you can't see whether an IRC user is in the room or not), and a few missing shiny widgets that Slack has (such as reactions, and more bot integrations already written).

See,, for some examples (you do need to log into Matrix somewhere to be able to join Freenode-bridged rooms).

Plus decent Android/IOS clients... And a Weechat plugin if shell apps are your thing. Not to mention, the web app has shiny new e2e encryption now getting a security audit...

I encourage everyone to try out -- it makes IRC modern, useful, and fun again, and it doesn't move the conversation into a closed silo.

freelock’s picture

P.S. Oh yes, does have emoji...

But using them breaks Druplicon!

willwh’s picture

Thanks freelock, I hadn't seen before :)

I've been using this for a while as my self-hosted IRC:, although I couldn't live without database logging, so I made a PR; I really can't say good bye to IRC completely, it has been a part of my life for such a long time!

freelock’s picture

willwh: I just checked out the Lounge demo, and I think you'd really like Matrix/Riot... the web client has a similar layout, but adds rich text/markdown, drag-and-drop images, a files tab, automatic pastebin across the IRC bridge, searchable history, all of your visible history available on any device, and even voice/video calling. All without disrupting the existing IRC channel. And you can join any channel on Freenode, Mozilla, OFTC, Snoonet, with more networks getting bridged regularly...

Antti J. Salminen’s picture

Another feature that Slack is missing which might be important to some people when we're talking about freely accessible chat channels is being able to ignore users.

Unfortunately there seems to be some fragmentation occurring now even with no decision made to officially move as some Drupal Slack teams have popped up:

NWOM’s picture

+1 for Discord. Even though this thread has concluded with IRC being the chosen option to stick with, I hope that the decision is re-evaluated due to the fact that it will inevitably cause fragmentation.

Programs like Discord and Slack provide much more than IRC offers these days. It also allows potential collaboration, and even job opportunities.

The best example is #drupal-support. A person that has a drupal site would be able click an invite link, have it open in his browser, ask his support question, and then get invited to a call to discuss his problem. It would also allow a tighter integration of different rooms (drupal support, drupal development, etc).

I hope the decision is re-evaluated, at least as far as #drupal-support is concerned.

kevinquillen’s picture

Slack can and will change its business model to suit its needs eventually. I wouldn't expect the free tier to be so lax on "unlimited users" forever. That's my opinion on jumping to a platform no one can control. The pricing models are not cheap either. The issue is if you offloaded the entire community to Slack, and 2-3 years later Slack yanks the free tier or restricts it further, or even, Slack closes up shop. Now everyone is orphaned and has to migrate back to IRC.

webchick’s picture

Well... then we get superior communication channels for 2-3 years, until which time we move to the same platform that everyone else adopts as the alternative. Oh well. :)

Antti J. Salminen’s picture

It seems like Slack is not a great option unless some kind of special treatment is arranged anyway. As previously mentioned here, even right now the free tier of Slack has some serious limitations when considering it for a community the size of Drupal such as the 10,000 message limit for history. You might even get kicked out if they deem your usage too heavy duty as happened to the Reactiflux people for example. I understand their plans for nonprofits also have some issues even for communities much smaller than Drupal's.

kevinquillen’s picture

Yep, that's what I was alluding to. "Unlimited free users" isn't really unlimited, just look at Reactiflux.

"A few weeks ago, Reactiflux reached 7,500 members on Slack. Shortly after, Slack decided we were too big and disabled invites. There was no way for new users to join. Many of us were sad and upset. We loved Slack. Our community was built around it.

We reached out to Slack several times, but their decision was firm. Our large community caused performance issues. Slack wants to focus on building a great product for teams, not necessarily large open communities. Losing focus and building for too many use cases always leads to product bloat, and eventually a decrease in quality."

klukacin’s picture

I've just checked all above and more chat-like solutions found currently on web. One of priorities I have in my company is use open source where possible use saas open source solutions if available and that's because our main priority is Drupal development and if I lose resources to maintain my own servers for anything that's not Drupal and even more for anything that's not in like PHP world it's just waste of resources for me. And also we like and use feature/customisation right tools like JIRA (I still havent found alternative for that where I don't have to compromise and have all needed features).

Also I do like altruism like telegram has or, hm, if I remember correctly google has/had also ... but I had to dismiss google photos as they changed important feature like the way share works. So sometimes I have to use proprietary hardware and software (did you know there is almost no open source CPUs! that we can build community upon).

So I vote for!

  • open source server
  • open source client
  • they offer saas hosting for us
  • looks like it has most (very) advanced apps for all platforms
  • looks nice
  • have many features

One feature in development we need to add or support is IRC connector, but that shouldn't be a problem if community decides to go this route. Also testing/beta are advisable ;)

freelock’s picture

@klukacin all your reasons apply to Matrix/Riot, as well. But the best part is, there's no migration work necessary, you can just go to, use the Riot link, create an account and log in, and you're in #drupal. You can also join any other existing IRC chat on Freenode this way.

- open source server (Synapse)
- open source client (Riot Web, Riot Android, Riot IOS, Weechat, nachat, Quaternion, others)
- they offer saas hosting for us (free accounts on server)
- looks like it has most (very) advanced apps for all platforms (markdown support, drag-and-drop file transfer, inline images, animated gifs, end-to-end encryption available, emoji picker, rich text editor, built-in duck-duck-go searching, unlimited history, history search, notification settings, email notifications, invite by email)
- looks nice
- have many features

For Matrix/Riot, there's a lot more:

- hosts the Freenode bridge for us, but that is open source too and anyone can run their own
- 100% compatible with current IRC rooms, automatically shortens long text and provides a link for IRC, automatically embeds links to uploaded files/images on IRC -- if you use Riot you get a much better UX but can work very well with users who choose to stay on IRC
- Servers are federated, meaning those who want to run their own can, and those who just want an account on can do that, and everybody can participate in the same room
- Matrix can also bridge to Slack rooms, and join conversations happening on different chat platforms

Rocketchat seems like a decent solution, but it's no comparison to Matrix for getting started. The best part is, you can use it today, nobody needs to make any decisions here -- just create an account and chat with everyone who is happy where they are!

ekes’s picture

For Matrix rooms - and they are now being made, and used, for Drupal. It makes sense to create them as Native Matrix rooms and then bridge them to IRC or/and where ever else it might be desired. You do then need the permission of someone with Ops for this however (unlike direct #freenode_#room channels).

This way you can add Matrix room administrators, unlike straight bridges to IRC. This means you can decide about how public they are, and how much logs people see and so forth.

So you can make a room accessible even for users who have not registered an account. Much more newbie friendly (more newbie friendly than all the Slack invite requirements). I believe the Portuguese channel (also world readable) ; and the Dutch language channel are both example that are native and you can just click to join. [There is also a general test channel world readable and non-registered public if you want to look.]

markcarver’s picture

I've been following this for a while, but haven't yet commented.

Sadly, there are already several different ways this can happen and, quite frankly, it's starting to get really.... really annoying.

Do I use IRC, Slack, twitter, d.o contact form/email, issue comment... now something new discussed here???

Do we move to another 3rd party solution that may not have all the features we need/want?


I do think moving to a 3rd party solution is a bad idea, even if it's open source; primarily for the fact of reliance (and for the other various reasons stated above).

Not to mention that it will never fully encompass our community's needs, wants or unique use cases.

This is very similar to the "Abandon issue queues and move to GitHub" discussion that we've had before.


Yes IRC is ancient. No one is disputing that fact.

It is, however, just a protocol.

I think people are forgetting that how users connect to it and what client the user decides to use is, entirely up to them.

That being said, I think moving to any platform that forces a user to use their "client" is a very bad idea.


Ever since I took over Dreditor, I had a radical idea that I never quite made public: providing per issue chat "rooms".

Originally, I had looked into somehow connecting to the IRC channels and even dynamically creating Drupal specific "rooms", that could be used.

However, that would really put a load on any server and could be considered "spam".

So I started looking into other solutions, mainly WebRTC (which I believe is IRC's successor).

It's already implemented in over half of all major browsers and it's success is quickly growing.


The reality is that we often work on issues where it would be nice to collaborate in realtime on specific issues.

What if we didn't actually have to "host" a chat server and instead utilize PTP (browser to browser)?

What if we could integrate it with and on the site all of use on a daily basis?

What if we could know when people are viewing the same issue just by seeing who's in the issue's chat "room"?

What if we didn't have to "onboard" new people into using new ways of communicating by downloading apps or signing up for 3rd party services?

What if it was just there, on, when users logged in?

Wouldn't it be nice?


I know this is a different approach and still a relatively new concept, however I really think it's worth considering.

And I'd even be willing to help spearhead the initiative.

freelock’s picture


I do think moving to a 3rd party solution is a bad idea, even if it's open source; primarily for the fact of reliance (and for the other various reasons stated above).

This is a big reason I'm a proponent of Matrix -- we're not reliant on a 3rd party. I host my own Matrix server, and am using it to participate in #drupal, #drupal-commerce, #drupal-migrate, and others. I am using the bridge, but if that goes away another can be set up. Anybody else can join there via, or their own Matrix server. could run a Matrix server, too.

That being said, I think moving to any platform that forces a user to use their "client" is a very bad idea.

Completely agree! While I'm evangelizing for Matrix here, I'm communicating with people on IRC using it today -- and they're on their usual IRC clients. There are several different Matrix clients to choose from, but with bridges, Matrix connects the silos and lets people use whatever they want. Matrix does bridge to Slack and Gitter as well as IRC, and there are experimental bridges to Telegram, XMPP, Facebook Messenger, and others.

Please don't go bottle up conversations in Slack. Riot (a Matrix client) is not far behind Slack in terms of usability and features, but far more open and not reliant on a single host.

Originally, I had looked into somehow connecting to the IRC channels and even dynamically creating Drupal specific "rooms", that could be used.

However, that would really put a load on any server and could be considered "spam".

So I started looking into other solutions, mainly WebRTC (which I believe is IRC's successor).

Now this is interesting... I don't think WebRTC by itself is a solution -- as far as I'm aware it's a transport for media. Matrix uses it for voice, video, and screensharing already -- but primarily peer-to-peer only works between two peers. For multiple peers, you need a server to "mix" the channels together so that everybody can participate.

But embedding a chat room per issue would be a very interesting solution. And (yet another) benefit of Matrix is that is can preserve history, make the entire chat visible to participants, as well as provide guest access. A chat room per issue could certainly be done -- embeddable Matrix chat rooms are on the roadmap for the matrix-react-sdk, possibly even as a GSOC project. And I've already started a Matrix API module...

markcarver’s picture

I don't think WebRTC by itself is a solution -- as far as I'm aware it's a transport for media.

WebRTC has RTCDataChannel, which allows for textual communication (i.e. chat).

For multiple peers, you need a server to "mix" the channels together so that everybody can participate.

A server isn't really needed for "mixing channels", no. The only server that is needed is STUN/TURN to setup the initial P2P signaling. Once a user has established a P2P connection with someone, the messages are broadcast by the person sending them. The "mixing" would happen (relatively) seamlessly in JS on the client side.

As far as "chat history" goes, I was imagining that we'd have a button or something that just posts to the issue itself (could even be automated at some point). No need to setup a whole new database and continue the discussion fragmentation we already have around issues.


However, the more I read up on Matrix, the more it sounds like it's just a superset of WebRTC with some extra flavor (which I'm fine with... same principle really).

Considering that there are native client SDKs for nearly everything, including JavaScript, I'm definitely inclined to perhaps pursue this route more.

First and foremost, I was imagining creating a d.o specific implementation.

People shouldn't have to worry about downloading, installing, signing up or paying for another service.

After that, another exciting prospect that can be accomplished with the above JS SDK is the ability to create a dedicated/native desktop application using Electron (supports all three major OS: Windows, Mac and Linux) and is actually what Slack uses to build its desktop app.

This would, essentially, allow us to just reuse the code already deployed on d.o but just wrapped in a "native" app.

Using a module/drupal interface for this kind of UI will be really challenging. I think our best bet would be a Node.js/react app that can be browserified/rendered on the site, kind of like what I'm doing with #1673278: Implement User Enhancements on and port Dreditor features.

freelock’s picture

@markcarver Yes, it's a pretty great platform... we use a Matrix chat bot we've written to handle deployment of all our Drupal sites, among other things...

Node.js/react is definitely the approach I'm taking -- node.js for bots, and React for embedding a chat component on the page. I think the main challenge of implementing something like this in Drupal is getting anything from the chat back into Drupal -- given that long-running PHP processes is not typical of most hosting. But there is another alternative -- the "application service" API for Matrix is capable of sending notices to an external API. So we could set up an app-service and have it receive messages from Matrix to handle as it sees fit. That's not something I've done yet, but there are a growing number of bridges that use this API, and aside from needing a Matrix homeserver that gives permission to the application server (Drupal) -- I don't think it's particularly difficult to use.

So... I would think the main thing to do is design what the UX might look like, and that might suggest whether it's better to have a simple node.js bot to send updates to Drupal, or create a Drupal/Matrix app service that's more direct... or keep the actual "integration" much simpler, with nothing sent back to Drupal, just a standardized room creation mechanism using React... (if we don't need to get data back into, I don't even think we'd need a Node.js component, aside from bot-type behavior).


markcarver’s picture

I think the main challenge of implementing something like this in Drupal is getting anything from the chat back into Drupal...

Which is why this related issue is so important. If we could open up d.o's API, it would allow us to more easily integrate via a simple JS AJAX call to a specific/dedicated endpoint.

I would think the main thing to do is design what the UX might look like...

I think before any "design" happens, we need to identify our community's use case (i.e. needs and wants). We can design something absolutely awesome but miss the mark entirely.

that might suggest whether it's better to have a simple node.js bot to send updates to Drupal, or create a Drupal/Matrix app service that's more direct

I think any "bot" would be a secondary goal and entirely separate issue. The primary purpose of this issue is to evaluate an alternative to IRC (i.e. real time community communication). Thus, I believe any MVP would need to focus around that first.

if we don't need to get data back into, I don't even think we'd need a Node.js component

The biggest misconception about Node.js is that it's only meant for "tools" or "automation". It's just a programming language. One that allows for easier portability between server and client side implementations.

realityloop’s picture

Gitlab just acquired Gitter and plan to open source it by middle of the year, seem like it might be a good fit.

diqidoq’s picture

A maybe noteworthy hard debate about Matrix (much critics), just to bookmark it here for further reading. Mainly about Matrix's own view against XMPP in the beginning. Note: my intension is not to take down Matrix in this discussion here with this, nor to push it. I just read and investigate, so also about Matrix's ups and downs, and have no fixed opinion yet about it (lack of time).

freelock’s picture

The Matrix devs came from the SIP world, and had a lot of XMPP dev experience before getting frustrated by the lack of any consistent set of XEPs that could be relied upon to be implemented. And... in my experience, it's a vast improvement.

We ran XMPP servers for years for internal chat. We had a Jenkins integration, and always wanted to do more -- but we never federated, and there was enough of a learning curve we never got much more integrated with it.

More importantly, a crappy UX killed XMPP for us. Matrix, being much more like Slack, makes it really easy to have a room per project, invite whoever should be associated with that project, and easily find everything. Having synchronized history across devices, comprehensive search within a room (for its entire history, unlike the 10K limit of Slack) and IRC support as well clinched it for us. Having a bot available the first weekend that would provide a login link to every Drupal site we manage on demand made it instantly adopted by our entire team.

For us, Matrix is like an IRC bouncer that makes IRC much more like Slack... except completely free and open. No open source project should tie its main communications to a closed, proprietary silo... especially one that seems to be hostile to open source...

diqidoq’s picture

Thanks for your infos and insides about this, freelock. Much appreciated here.

lpalgarvio’s picture

Currently I have a working experiment that bridges the following services:
- Slack
- /
- Gitter
- Telegram

I'm doing experiments with some drupal and docker channels and private servers that I won't mention here, reasoning privacy and security issues.

The workflow is currently this:
Slack <-> via Slack's ingoing and outgoing webhooks apps <-> via Riot's Gitter integration
IRC <-> via Riot's IRC integration
IRC <-> Telegram via FruitieX/teleirc bot at a personal private server

I'm hoping to improve this process with additional software, and also provide support for RocketChat. Currently it's a very manual process and requires admin intervention, channel by channel.

Let me know how I can assist.
PS: we have implemented a IRC <-> Telegram bridge for #drupaldevdays that had mixed reactions (technical vs attendee chat) and has been turned off. A proper implementation has to consider the channel audience/target.

geerlingguy’s picture

It's interesting (since nothing has been officially changed) to note that the IRC channels seem to be shedding many, if not most, conversations outside of support-related things. I've noticed the trend for the past few months, but the more recent drama in the community (which also resulted in our long time bot, the Druplicon, being banned—see #2863181: Druplicon's purpose changed - block it as we consider purpose/use of irc bot in the future) seems to be accelerating the shift to the Slack usage.

Ideally, I'd like to use IRC or some other more open protocol. But I'm also a pragmatist, and it seems like a lot of the relevant conversation and community members are either both in IRC and Slack, or exclusively in Slack now :/

ekes’s picture

I'll note it's certainly not all. I'm in 3 Drupal irc channels that are active. Two of which don't yet have one of the close alternatives yet.

I've experimented with bridging some of the channels slack<->matrix<->irc. The cultures between slack and irc and can vary and jar - not necessarily but expectations about messages are different. The difference between matrix and slack however is minor.

So as matrix can offer an open source (and open click-url and see chat, through to full registration and invite) option even for the slack channels. I'd say we could start bridging some of those slack channels to matrix. Who's the admin of drupal.slack? (bridging channels requires adding api hooks). Some of these could even be bridged back into irc, but I take that step a little more carefully.

fuzzy76’s picture

A proprietary network run by a company *known* to throw out open source projects if they become too large? That's a terrible idea if I ever heard one. :-/ Not to mention their terrible UX involving signing separately into each Slack you want to participate in.

ricardoamaro’s picture

I've been watching this thread for a while and it seems to me that what people are requesting from IRC is that it should have more automation, a common UI and still be able to accomplish what it has been doing for us all these years.
It seems to me that what we need is:
- to apply a better integration using an opensource chat solution on top of IRC . Freenode already has one
- have our Infra folks bring in a modernized and opensource version of our bot
There are several choices out there already mentioned in this thread, but for sure we need to keep ourselves Independently using FreeSoftware and not using some closed solution leaving ourselves out of options in case we are "thrown out".

Using FreeSoftware solutions everyone can still contribute to improve a bot, a webui or an integration, leaving the job of administrating these to the D.A. and volunteers.

geerlingguy’s picture

So, thinking further on Slack... based on some things I learned from discussions there

  • Slack might cut off the account if we reach 15,000 users (apparently there are that many across all the #drupal-* IRC channels this stat may be incorrect)
  • Slack charges ($5.00 * .15 (85% discount)) = $0.75/user for non-profits—that would be ~$2,000/month at the current number of users(!)
  • Slack hides any messages beyond 10,000 messages for the entire account—with recent drama, that means most less-popular channels have zero visible chat history. Not fun.

This doesn't sound sustainable to me, for so many reasons.

NWOM’s picture

Discord doesn't have any of those three downsides (no user cut off, no charge, no message cut off). If we're potentially looking into closed source solutions (like slack), then maybe further investigation into Discord would be beneficial in the interim. There are plenty of groups that I idle in that have over 50,000 users, and also others that have IRC bot integration (from and to).

frob’s picture

Let's not forget that slack is not, and has no plans to, start supporting open source communities. In order to lower the barrier to entry we would have to use some equivalent to the heroku app for user registration.

Can the idea of switching to slack please be put to bed? It is only more convenient if you work at an organization that uses it for internal communication. If not, then it is one more thing to keep open.

kevinquillen’s picture

Slack can also change the rules at any time - and as mentioned before, they did to other communities. Plus, for better security, logging, and policy enforcement, you have to go above the normal price tier and look at higher options. It is costly.

Don't get me wrong, I like Slack, it works for our company, but I don't see it working at scale or by cost.

freelock’s picture

Everybody in the past few posts seems to be arguing for Matrix over Slack, at least by their arguments for open source, non-restrictive alternatives. Why are people continuing to use it?

Regardless, I agree with @eke above, let's get whoever is an admin on the current Slack groups to assist setting up Matrix bridges. Then people can continue to use Slack if they really insist -- but the rest of us can participate via Matrix.

ivaat’s picture


I do think that IRC is 1# one good place for people to come and ask questions. It will never go out. All other platvorms are not independent. Did check slack out. More for team work and free one seems to process data as well. Don't know about that privacy at end.

Perhaps solution is simple:

For crossposting minimalation link #drupal-support to #drupal + make #drupal-social active (add topic). for #drupal-social can be slack linked as well. There several softwares out ther what enable slack to irc. for #drupal-social that could be solution in terms of getting more people involved

lpalgarvio’s picture

About Drupal Slack
#2864161: Change Drupal Slack allowed/installed apps

That said, like many people here and in other technology circles, I'm feeling much more confident with and RocketChat, both open source, than with Slack.
open source, multiple official and contributed clients and servers
self-hosted and available as free unlimited service

open source, official client and server
self-hosted and available as free service upon request

shrop’s picture

Is it possible to consider sticking with IRC and hosting a web IRC solution like The web IRC solution could be setup to make it easy to drop into #drupal-support. I experimented with Slack for a Drupal distro over the past year and we moved back to IRC. We found that many novice users had issues with Slack if they didn't use Slack elsewhere. Our team decided we would be ready to assist novices get going with IRC.

Thanks for your patience if that has already been recommended. This is quite a long thread.

heddn’s picture

Why can't we decide that we stick with IRC and let any and everyone bridge it to any and every technology on the planet? If you want to setup a bridge Slack. Good, go for it. If you prefer carrier pigeon, have fun. Has anyone else said anything about actually *replacing* IRC with something else, or just supplementing IRC with bridges for the past 159 comments?

RE: #159 there are already solutions that do that. See consensus around #50-#68.

Right now, this issue is essentially a venting board or bragging place for 1) why they hate IRC or 2) what technologies they were able to bridge into IRC.

Let's just accept it. IRC is here to stay. Long live IRC.

shrop’s picture

@heddn: Good deal! Thanks for the details. I am for keeping IRC and addressing specific improvements. May be time to break out specific improvements into separate issues.

frob’s picture

I am also for keeping IRC. If we want to spend some of our precious infrastructure time (not sarcastic, infrastructure time is precious) we should do it on either an upgraded alternative to the web IRC client, with another cheaper option would be to just promote the freenode webchat client more.

ricardoamaro’s picture

Since i'm the Drupal group contact with freenode I would love to see some comments on the 2 proposals above at #151 in order to move ahead with some real outcomes from this thread, since people are a bit dispersed right now.

shrop’s picture

@ricardoamaro, I am supportive of both ideas on #151. Think starting two issues for these is the next step?

Antti J. Salminen’s picture

I think building upon IRC would be a good idea but I have some concerns about the split just staying in place when lots of people seem to already have migrated off freenode to the Drupal Slack.

ricardoamaro’s picture

@shrop yes, i think creating action items based on this discussion would be a good starting point. Today i went to slack and there is a huge crowd over there. Would be great to have everyone's constructive ideas and contributions based on IRC, since that's the general take of this thread.
Reading again the above i think #77 is a good solution for the first point.
And they have apps available for mobile


fuzzy76’s picture

I think a lot of the comments the last couple of days come from people that haven't read this entire thread yet, as most of these aspects have been discussed already. One major pain point with IRC is that you can't read previous history unless you are a) connected 24/7 or b) run a bouncer (proxy) on your own server. This is not ideal, and is a problem solved on every other possibility out there (Slack, Matrix, XMPP, Discord, Mattermost, Gitter, etc.).

ricardoamaro’s picture

Issue summary: View changes
ricardoamaro’s picture

Created: - "Modernize the IRC Drupalbot"

geerlingguy’s picture

@fuzzy76 - note that unless we pay vast sums of money, Slack only allows access to the past 10k messages. With the flurry of activity this week, that means most of the channels on Slack have zero history anymore because other more popular channels have pushed past the 10k limit and do so on a daily basis.

Antti J. Salminen’s picture

@fuzzy76: That one's not that difficult to solve with an IRC bot though. Admittedly the interface isn't quite as nice but it definitely works. In fact the Drupal IRC channels could have had that with Druplicon but a deliberate decision had been made to turn the logs off for most channels.

kevinquillen’s picture

@geerlingguy plus, I think if it were the new 'official' chat channel for, people would want SSO so there is solidarity between their Slack account and account. You don't get that unless you pay $12.50 per user per month instead of $6.67.

fuzzy76’s picture

@geerlingguy As I stated earlier, there are a lot of things wrong with Slack. My comment was not an endorsement for that particular service.

@antti that is not solving the problem, that is duct-taping a hack. Sort of like mirroring two mediums (or channels) through a bot also is. (Or using a cvs-era patch-based workflow on top of git, but let's not digress too far).

frob’s picture

@fuzzy76, no it is not a hack or duct-tape solution. IRC is a chat protocol that we can build our own clients around. Every chat system is based on very similar protocols.

While I would be lying if I said that I read every word of every comment. I did skim through it all and I read anything that was replied or mentioned. The general consensus is that there is no consensus. The is no perfect solution and thus in order to get this issue marked as fixed. It seems like the best solution is what was most recently suggested.

- updated or better promoted IRC web client
- opt in logging
- modernization of chatbot #2864658

frob’s picture

Issue summary: View changes

I did some organizing of the is, alphabetized (somewhat) the irc foss users. Assed wordpress to the irc users because they have not stopped using irc for support and are only using slack for wordpress contribution.

Antti J. Salminen’s picture

@fuzzy76: I wouldn't go as far as calling it duct-taping a hack but I admit it's far from the ideal UI for such a thing. Some kind of a multi-user bouncer setup for everyone would be the better solution to build just on top of IRC but also much more difficult to implement.

@frob: How would opt-in logging work? everyone can set if their comments appear in the public logs and for those that don't want to the logs will just have lines that indicate someone said something? If so, interesting idea... has it been used somewhere previously? currently lists 8 different Slack teams. I'd love it if things could be at least slightly less fragmented and for that I think there would need to be something more appealing than just an improved bot and promotion of the webchat. Whether the best choice would be one of the fully free/open source solutions or something like IRCCloud I don't know. IRCCloud does have the advantage of probably being the easiest to get up and running and even if it's not an entirely open-source self-hostable solution, it's just an addon.

Antti J. Salminen’s picture

Issue summary: View changes

Convos is Another potentially interesting option that works in a way similar to IRCCloud in that it's just added on top of IRC but is F/OSS and has to be self-hosted. Looks like it's in active development. Added it to the list.

frob’s picture

@antti I haven't thought too far into opt-in chat logs, but what you said is the basic idea. I just thought of it while I was typing, and I should have brought it up in a comment first. Now that the DA is managing the bot this kind of thing is technically possible.

I expect there is more than 8 drupal channels on slack. It seems like we are hemorrhaging users from IRC to slack. This is a very bad thing and one of the reasons I want to get this issue resolved. Slack is not designed for harboring open source communities. This is why they have such a steep pay-scale. Everything about slack is designed around corporate team communication. I am not saying that we need to stay on IRC because IRC is the way we have always done it. But all the benefits (listed below) of IRC vs the two benefits of Slack for open source really makes the decision (to me) an obvious one.

Arguments in favour of IRC

  • IRC is an open standard
  • Users can choose their own client
  • Many other FOSS projects use IRC, so contributors to those projects can easily join the Drupal channels
  • Optional user creation, no register user required for use

Other open source projects still using IRC besides Drupal

  • Ansible
  • Asterisk
  • bash
  • drush
  • docker
  • debian
  • Fedora Project
  • git
  • grav
  • GNOME Desktop
  • linux
  • python
  • puppet
  • Mozilla
  • mysql
  • nginx
  • OpenStack
  • postgresql
  • php
  • Ruby On Rails
  • sensu
  • ubuntu
  • vim
  • wordpress

Arguments in favour of Slack

  • Users are already migrating
  • I use it at work so I already have it open

Even wordpress which uses Slack for core development, doesn't endorse the use of slack for general support.

I am attacking the idea of using slack because it is where people are going, not because it is the proposed solution. Many of the other open source solutions also have merit.

I have not seen Convos before, looks interesting. I expect running anything like Convos would have to also get approval from freenode.

I apologize for the rant.

realityloop’s picture

I think the biggest risk, which we are already seeing is fragmentation.

I vote for something open source (looks like Matrix is the frontrunner here to me).

Anyone using multiples of different messaging systems should also check out:
And the plugin repository:

Seems like it wouldn't be too difficult to make a plugin for one of the web based Matrix clients.

frob’s picture

Issue summary: View changes

@realityloop, I dunno. From everything that I read about Matrix in this thread, Matrix doesn't sound like an IRC replacement. From what I have seen in this thread there is no IRC replacement. All talk has been of using Matrix as an IRC bridge, which plenty of people seem to be doing. Using IRCCloud isn't replacing IRC either.

I'm going to put my neck out there and mark this as RTBC Needs work (I have updated the IS with things to do). We stick with IRC. Though a plan needs to be made to stop the migration of users out of the official support channels, or better define official support channels, I think this discussion is resolved.

frob’s picture

Status: Active » Needs work
markcarver’s picture

From what I have seen in this thread there is no IRC replacement. All talk has been of using Matrix as an IRC bridge, which plenty of people seem to be doing.

No, that's just one way to use Matrix. Matrix is an open protocol, just like IRC, but built with newer technology, concepts and features.

It semi-mirrors what WebRTC is attempting to accomplish.

There are many different ways to use Matrix:

We stick with IRC.

Obviously IRC cannot support the features we need.

That is why this issue exists and why people are trying find other mediums that do.

I think this discussion is resolved.

No it's not.

marcvangend’s picture

Status: Needs work » Active

Matrix doesn't sound like an IRC replacement. From what I have seen in this thread there is no IRC replacement.

That sounds like saying "email cannot replace snail mail". Of course it's different, but given how many people are switching to slack already, I can only conclude that tools like Slack/Matrix are seen as replacement, and probably even an improvement.

This issue will only become "needs work" once we agree on a plan and start implementing it.

Antti J. Salminen’s picture

Seems like what there's agreement about is that we can't stick with just IRC and that while features that Slack offers are desirable, it isn't really an option.

Also seems like there's support for having IRC still be around as more than just a gateway you can connect through (so not Slack-style). That makes sense to me also because it would mean not asking the existing userbase to move to yet another platform. Many would also prefer a solution based on free/open source software.

Matrix and Convos look to be options that would tick all these boxes. IRCCloud gets close, but if there is a fully free/open source software solution that would be preferable.

Matrix being even able to bridge Slack in addition to IRC would certainly help adoption and it could be offered as the official solution. If it has the major pain points covered and works reliably I support choosing it too.

larsdesigns’s picture

I second the statements and opinions of @greggles.

I can add that IRC is the most inclusive chat system for our community and when provided by freenode it supports the nature, culture and values of Drupal as an open source software community.

An area we can work on is to create easier access to IRC. Perhaps providing recommendations for IRC client software, and improving the instructions for getting started.

frob’s picture

Issue summary: View changes

This issue is confused and will go nowhere if we do not focus. Lets get a list of requirements since this has primarily been a scatter shot of suggestions thus far. These are the requirements thus far:

Requirements for chat system

  • bot integration,
  • Being able to get messages even if not connected to it,
  • Probably not self-hosted
  • @todo add more requirements

Seems like what there's agreement about is that we can't stick with just IRC

This isn't an agreement, this is an argument. There is just as much of an agreement that IRC is the best solution at this time. There is nothing wrong with IRC as a protocol and it can do all the things that we have listed as requirements. In fact, it does them all right now.

We have a list of "problems with IRC", but we need to update the Issue Summary to convert this into a useful issue where we can actually gather options and evaluate them without becoming a pro/anti-IRC/SLACK/CHATSERVICE issue. If it isn't done by the time I circle back here then I will attempt to rewrite/focus the IS by the end of the week. In the mean time I will add two requirements.

  • Open source
  • Not an island for Drupal

Open source

Drupal is an open source project and it should be important that we embrace open standards and open source. It can be argued, and I would agree, that this might be more of a nice to have than a requirement, except that with the mass of open source chat systems out there I believe we can find one that is best-in-class.

Not an island for Drupal

I am thankful that we have not seen a "lets just roll our own" solution for this mentioned, but I still think we need to be clear about this. If we move somewhere it shouldn't be a place that only Drupal exists. A self-hosted web client isn't a bad idea, but those of us who are involved in more than a single open source project shouldn't be required to keep an app running just for "Drupal Chat."

Antti J. Salminen’s picture

@larsdesigns I mostly agree but there are two things that lead me to believe that better documentation would not be enough. First, I think it is a good observation that there is an issue with the usability of IRC compared to Slack caused by the lack of a nice web-based interface and the barrier of entry having to install a (better) native client creates. Freenode webchat exists but it feels very dated and not something even I would like to keep using as the way to get to IRC while Slack's web interface is good enough for someone to do that. Secondly, at this point we also have to consider that a good number of people that have previously been perfectly capable of using IRC have already made the choice of moving their discussions to Slack so they seem to prefer something that it offers.

You're right, I misspoke about there being agreement about just IRC being enough. What I was getting at and I'm hoping nobody would object to is adding optional functionality on top of IRC with Matrix or one of the other mentioned solutions that are able to do that.

markcarver’s picture

Issue summary: View changes

This isn't an agreement, this is an argument. There is just as much of an agreement that IRC is the best solution at this time.

No. That's your opinion. It doesn't change the fact that IRC is severely outdated and lacks much needed features.

There is nothing wrong with IRC as a protocol and it can do all the things that we have listed as requirements. In fact, it does them all right now.

Um... no it doesn't. Which is why we have severely fragmented our community's communication in regards to which mediums/platforms are used.

In the mean time I will add two requirements. Open source Not an island for Drupal

I agree with with the open source, not so much the "Not an island" part. Yes, we'd have to create a "homeserver" for Matrix (see IS), but that's rather trivial.


@frob, I don't think you understand that Matrix allows us to "keep" aspects of IRC and would even allow us to bridge with IRC. Just because you are fine with IRC, doesn't mean the rest of us are. Please stop saying "that it's fine as is". It's clearly not.


I've updated the issue summary to be a little more concise with what has been discussed above.

markcarver’s picture

Issue summary: View changes

Minor formatting

frob’s picture

Issue summary: View changes

@Antti: sorry, I misunderstood what you wrote as to mean that we need to replace IRC with some other solution. I am all in favor of attaching more tech to our freenode hosted IRC.

No. That's your opinion. It doesn't change the fact that IRC is severely outdated and lacks much needed features.

IRC is old and that is a bonus, not a failure. It has been around for along time and it has continued to evolve to suite its use-case. We are talking about chat protocols and it is important to not throw the baby out with the bathwater just because chat protocols have seen a resurgence in recent years. The abundunce of options doesn't make our current choice any more or less useful.

We need to focus on features and not get bogged down on implementation. That has been a real confusing part of this issue. Everyone is looking to solve the problem and everyone is moving in a different directions. We need to know what direction to move before we begin working on an implementation. We have a list of IRC complaints, that part is done. Now we need an absolute list of required features. The list has been started in the IS.

@markcarver, thank you for focusing the IS.

I added gitter as a proposed option, and moved webrtc and "user is typing" indicator out of requirements and I doubt either is deal breaking.

frob’s picture

During core mentoring at PHPWorld and people from other Open Source community said that they don't use IRC and its 1990's chat client which is way too old to use in the Drupal community and why Drupal still lives on IRC.

Does anyone know where this paragraph came from. It doesn't really make a whole lot of sense but it sounds like a quote. We need this paragraph cut or fixed. I don't know what it is supposed to say.

heddn’s picture

I think that was a quote from the Drupalcon core conversation that launched this issue.

markcarver’s picture

Issue summary: View changes

@frob, typing indicator and RTC (audio/video) aren't "nice to haves". They are a requirement. These are features that don't exist and force people go to other mediums that do have them. These are probably the biggest reasons for our current community communication fragmentation.

I think you're confusing what some people won't use or don't care about vs. what some people need (and why this issue exists).

Please stop trying to belittle this issue.

I also took out the verbiage about the Druplicon. Current implementations doesn't change the fact that bots aren't really a native part of IRC and require a manual and separate persistent instance/connection to be maintained.

pwaterz’s picture

I think it's time to just pick one and go with it, and adjust our approach when it's needed. So much time is being wasted on arguing one chat client for another. I think HipChat and Slack have been vetted by the tech community as being good choices in this space. The company I work for went through this same process about two years ago, and we chose HipChat because it was more robust than Slack at the time. I think they both offer similar features, and someone with authority in the Drupal community needs to just pull the trigger. The longer it takes to make the decision the more productivity is lost in entire Drupal eco system. Does anyone think it would be a good idea to create a survey monkey survey to allow us all to cast our vote?

markcarver’s picture

Issue summary: View changes

I think HipChat and Slack have been vetted by the tech community as being good choices in this space

Yes, for small to medium sized business/teams. Not for a full blown community like Drupal.

I've updated more of the cons in the Slack category.

lpalgarvio’s picture

  • IRC usage is dropping on IT circles for maybe a decade now
  • IRC sucks on mobile
  • IRC doesn't keep track of channel logs or your private conversation logs. You need applications for that, external synchronizations, per user, costs money, many aren't FOSS
  • IRC doesn't do voice calls.
  • IRC doesn't do video calls or conferences.
  • IRC is a pain to share files.
  • IRC does not show media, such as pictures and maps.
  • IRC can't share stuff permanently.
  • IRC doesn't support login by email address or phone or external credentials.
  • IRC services is probably lacking in integrations (web hooks, notifications, etc).

Can we quit arguing that IRC is outdated or not? It is. It's a fact.

However it does well a lot of things. And a lot of people like it and use it. And it's another drama if it ends.
Can we revise the topic description and title to something more friendly, like

Evaluate other communicate mediums to be officially supported and synchronized with IRC?

Major tasks:
# - Add additional supported protocols
# - Improve IRC with a better bot
# - Connect it and synchronize channels to other protocols

This way it suits everyone (I think).

It's also been overwhelmingly repeated and discussed that Slack isn't what we need, for many reasons.
Some solutions are standing out for ease of use and no costs, other than the ones associated with bots:

  • Telegram (has recently added voice calls)
lpalgarvio’s picture

Issue summary: View changes
lpalgarvio’s picture

Issue summary: View changes
lpalgarvio’s picture

Issue summary: View changes
lpalgarvio’s picture

Issue summary: View changes
frob’s picture

Issue summary: View changes
Related issues: +#2864658: Modernize the IRC Drupalbot
lpalgarvio’s picture

Issue summary: View changes

recover lost edition

lpalgarvio’s picture

Issue summary: View changes
ivaat’s picture


don't know how irc sucks on mobile phone. depends what client is used. people who chat via irc have questions and it's more chat not tweets with short messages...


this topic seems to be old and actually not a issue.

for #drupal, #drupal-support IRC using
for #drupal-social made suggestion to link for experiment slack with irc (software avaliable).

+ webchat and freenode has that already.

All other solutions seems to have purpose for this topic.

Perhaps summarise this by op?

lpalgarvio’s picture


What I mean by sucking on mobile is the experience you get with each connection that is interrupted.
It's highly disruptive, distracting and annoying to get spammed with jargon when using regular IRC clients.

Which can happen multiple times a day, considering things like, switching between WiFi and 4G, going in the metro, passing through a tunnel, going downstairs on a steel reinforced concrete part of the building, weather issues, and so on.

freelock’s picture

Nice changes to the issue summary!

I would think that #3 should satisfy just about everybody (other than those who can't get over their Slack addiction...). There's no need for anybody to stop using IRC. We can just bridge all the IRC rooms into Matrix -- and this is already available/done as "portal rooms" -- anybody on Matrix can simply "/join" to get into the main #drupal channel, and use the same pattern to join any other IRC room on Freenode. So there's not even any action necessary to have #3.

However, there are a couple improvements to suggest: with support from an Op in each channel, we can set up an official "plumbed" room, which would allow us to make the history available to anyone (if desired), and not just users since they joined the room.

And the other improvement? Add links/instructions to the appropriate community pages, send new people to the Matrix rooms (as well as IRC) and remove the Slack link. Encourage people to use Matrix or IRC, and not Slack.

Some other thoughts for longer term improvements:

If the DA would like more control over the channel names, I would recommend setting up a Synapse server on a domain, which would allow for better aliases. If you use to create the bridged plumbed rooms, you end up with room aliases like "" or with portal rooms, "". Better would be ""

With a "homeserver", we might also be able to auto-login Drupal users using their credentials. There's already an LDAP authentication system for Synapse -- I'm wondering how hard it might be to use Bakery or Saml to auto-provision/auto-login Matrix accounts based on DO accounts. Created #2867466: Provide Matrix provisioning/authentication system to track this feature request, at least on the Drupal side.


hestenet’s picture

Chiming in from the Drupal Association point of view:

I just wanted to say that we're following this conversation closely, and we do want to support the community in finding a good solution here.

We don't want to step in while consensus is still being built, but we do see several ideas coallescing:

  • We want a technology with modern UX/features
  • We want to address fragmentation, which can really only be done by standardizing on an official option, or by offering an option with bridging capabilities
    • Any bridging solution is likely to require more ongoing maintenance and support.
  • Whatever we reach consensus on, it is likely that it will need official support from the Association, whether that is:
    • to establish a relationship with a service like IRCcloud to provide licenses for the community
    • to provide a Matrix/Synapse server to ensure the cleanest bridging experience
    • or something else

    And on the subject of 'something else' I do want to raise the point that there is an ongoing developer tools evaluation underway. And another update is likely to be posted to the community soon, laying out the short list of options:

    • We should bear in mind that GitLab is likely to be one of the toolsets on that shortlist, and it is already tightly integrated with Mattermost, and the soon-to-be-open-sourced - so there might be a natural opportunity there.

    All this is to say:

    • The DA would like to offer our support for a consensus solution. There is the caveat that we may not be able to prioritize that work for 6+ months, but that may not be such a bad thing:
      • It would allow us to see if natural options evolve out of the developer tools evaluation
      • It would give Matrix a chance to further mature, helping to address our concerns about maintaining that sort of alternative.
    lpalgarvio’s picture

    +++1 for the excellent plan detailed in #206 by @freelock.
    more than anything I had given some thought before

    Question remains, public server (free) vs server (has infrastructure costs but more control).

    fantastic! vs Rocket.Chat to GitLab... and GitLab integration: and Hubot integration:

    Rocket.Chat and GitLab integration:

    Rocket.Chat and Hubot integration: to Rocket.Chat:

    Hubot can talk via 3rd party plugins/scripting to:
    - GitLab
    - Gitter
    - IRC
    - Mattermost
    - Rocket.Chat
    - Slack
    - Telegram

    There seems to exist more and more complete integrations for, however this needs to be tested.

    Some stats from free server:
    - 7 drupal channels
    - #debian channel bridged to #debian on with 500 users
    - docker/docker channel bridged to gitter with 480 users
    - linode channel bridged to irc with 280 users

    The free server currently provides working integration with:
    - GitHub
    - IRC
    - Gitter
    - RSS
    - Slack
    I've tried all these out in the portuguese drupal and the portuguese docker communities.

    Twitter integration is broken on the free service and although there are integrations for GitLab and Telegram, they haven't included them yet in it.

    ekes’s picture

    Question remains, public server (free) vs server (has infrastructure costs but more control).

    I can't see why the DA would set up a matrix server. They've not set up an IRC server.

    As Matrix automatically federates a room when someone from another server joins it, this is this not so important? is also

    If desired in the future you could have a that hosts an instance, but the chats could still be federated onto whichever other server.

    In practical terms at the moment. Slack continues to grow. IRC continues to be used and be 'officially' supported. There is a real and existing disconnect between chat tools, and rooms. People are also starting to use Matrix.

    I, and others, are already in Freenode IRC channels from different matrix servers. There are instances of native matrix channels too: #drupal-nl channel is native and then bridged into irc (and a slack channel).¹ I assume the Portuguese one is similar, and there may be others. These can be on one matrix instance, but you can join from your preferred one.

    While some regional slack instances have been bridged to Matrix. The one hasn't yet. To bridge slack channels does require the operators to set two webhooks. The DA didn't - so far as I know - promote the; there was certainly no consensus for it. There's really no reason to wait on such things before making it accessible without invites and with open source tools.

    * So there is nothing stopping publicising matrix rooms, bridged to irc, now.
    * The only thing stopping people use open source software to chat to people in slack is they aren't bridged yet.

    ¹ The difference for those interested is: in the first instance (IRC joined via Matrix) you don't end up with Ops on the room, the server sets everything. The second you get Ops, control permissions, but you need to get permission from the Op of the IRC channel to bridge.
    Why might you want to do this? Well you could make the channel truly public for example. Like you can see the channel anonymously, just on a web page, without logging in! It's not the default, people need to know that people not in the room can see what's happening (a bit like the public bot logs, but even more integrated and obvious).

    fuzzy76’s picture

    I can't see why the DA would set up a matrix server. They've not set up an IRC server.

    Because Matrix does integrations, while IRC doesn't. You could connect user accounts to directly, you could auto-generate rooms for projects, you could push commit-messages to said rooms, etc.

    frob’s picture

    I can't see why the DA would set up a matrix server. They've not set up an IRC server.

    There is also no need to setup an IRC server, freenode is the place for that. There is no benefit to setting up and self hosting an IRC server for an open source project.

    I am really glad to see the refinement in the IS. We now have a list of requirements and some suitable options for reaching those goals.

    @markcarver I am not trying to belittle this issue, I think that stopping further fragmentation of the drupal community is one of the most important things that needs to be done. That is one of the reasons I was trying to get people to stop complaining about IRC or Slack and stop bragging about their home-grown IRC bridge solutions and come up with some requirements. We have now done that.

    I still consider the "someone is typing" indicator a nice-to-have feature, because in a room with 100+ people it can just cause noise or stop someone from typing at all while they wait for their chance to be heard.

    I still consider RTC a nice to have because I have only once in near 10 years of doing Drupal needed to get on a call with someone and that was for a local dug meetup and not for community support. It would be nice to have it supported by whatever we use, but I can just as easily use any dozen video chat services for that.

    It will be interesting to see the outcome of and if it causes anything in our list to change. One thing to note about gitter:

    No integration with our projects. Channels are made independently from the project

    This is no longer true with gitter. The whole system seems to be built around rooms per project. I would also add, minimal required maintenance and minimal custom development required as requirements to switching as well. Of course, this begs the question what "minimal" means, but that is up to the DA that will be maintaining this new chat system.

    wturrell’s picture

    Issue summary: View changes

    First, please read the additions I've just made to the issue summary (includes a few non platform-specific points)

    My TL;DR would be: whatever we choose, please can we keep things as simple as possible, minimising noise, clutter and cognitive load?

    FWIW I can speak highly of the web and iPhone version of IRCCloud (note I'm on a free account, but sleeping my Mac Mini at night still seems to magically hold the session open and avoid the 2-hour timeout). It's reliable and gets out of the way – with it in a pinned tab, I can go ages without being distracted by it at all, yet I'll still see notifications straight away. For me the biggest feature isn't scrollback, but the ability to turn off "Show nick changes, joins and parts" – people waste huge amounts of time re-reading these every time they check a chat window (even the condensed equivalent on Slack).

    I appreciate IRC for it's plain text feel, especially the lack of Emoji - I think simple emoticons like :) and :( communicate a range of feelings (also useful: words). I honestly find icons, avatars, animations, etc. a huge distraction when reading through a transcript because they appear more important than the surrounding text. Similarly, my gripe with auto-embeds, such as those in Slack, is that they take up a large amount of real-estate disproportionate to their importance in the conversation (and the excerpt that's embedded isn't necessarily the bit you want to read). I'd want the ability to disable or compact them. Note a benefit of Drupalbot's node summaries is they are all on a single line.

    I'm not sure how important integrated audio/video chat should be - I'd suspect most of the time people prefer to take time to think about what they say and then type it.... When we do have meetings, is there any real problem with using Google Hangout etc? I wouldn't want people forced into using video chat, it's important all participants still have an audio option. Also: make it easy to mute microphone, see yours/others connection quality to help diagnose problems.

    Clearly a single chat system is preferable (I have sympathy for anyone who is currently has to straddle both IRC and Slack) - but I'm unconvinced what we choose it is will make any significant difference to the number of people who use/contribute to Drupal - people won't be put off just because we're using Chat Foo or Chat Bar.

    Most activity takes place elsewhere (as @webchick once said: "issue queue or it didn't happen"). It's important for people not to feel out of the loop because they weren't participating in text chat/RTC, and it shouldn't be seen as a requirement to contributing to the project.

    So I'd disagree with the premise that Drupal currently "lives" on IRC, where it really lives (and must) is

    lpalgarvio’s picture

    Issue summary: View changes

    Slack and Riot ( do support voice and video calls with webRTC.
    I've tested these in the past and these functionalities are documented.

    Speaking of voice and video chat, in Slack voice and video calls are for pay in channels.
    For chat between two people they are provided for free.

    I'm finding very difficult to accept the arguments you've made, so I've made new corrections to the issue summary.

    frob’s picture

    Issue summary: View changes

    Please lets not argue and post counter-points inline in the IS. I combed through it and removed some duplication and extra information.

    Currently I think our issue summary shows clearly what the problems are and what we would like in an IRC replacement. Lets see what happens from the news in comment #207 and maybe adjust our expectations accordingly.

    wturrell’s picture

    (written pre #214)

    I primarily want to make the case for prioritising simplicity over feature set, and consider how what we choose could impact people's productivity (also, the fewer built-in features we insist on, the quicker we can implement something that does most of what we need).

    I took care not to directly back any individual solution. It is, however, perfectly legitimate to include some positive views about IRC in the issue summary to provide balance - leaving a one-side section misleads those unfamiliar with the subject and annoys those who are. This list of "Concerns people have voiced about IRC" has evolved into a list of features (or lack of them) - I went back and listened to the 2015 discussion that sparked this issue; while technical stuff was mentioned, I interpreted it as being as much about the group of people who simply don't have enough time to be on any form of live chat or chose not to because they believe the stream of information is too overwhelming. Additionally, there were those who thought they might be missing out on important discussions, but still felt it wasn't worth the effort. Whatever we do we'll struggle to solve that.

    I had written some longer replies to @lpalgarvio's comments but ultimately I also have spent too many hours on this issue today and would rather do something more productive than arguing for or against IRC, so briefly:

    - I'd endorse quite a few of @frob's remarks, including most recently about "someone is typing" not necessarily being a positive thing, and that RTC isn't essential (I'm aware there's no formal Drupal policy on which platform, nor should there be imho, but the DA and the UX group use Hangouts for their regular meetings and the archival to YouTube provides transparency to the rest of the community without costing money).
    - I disagree about integrated file-sharing, that nobody has mentioned it at all in the comments suggests it's demonstrably not a priority. People being in different places fragments a community, people sharing a link from Google Docs doesn't. Also not everyone needs (or wants) the links they share to be permanent (and indeed not everyone wants chat logs to be permanent actually), but those files we need to preserve already have a canonical location on - e.g. screenshots, patches and other work attached to items in the issue queue, policy documents, etc. Also, as I wrote earlier, I would resist the temptation to "embed all the things". Adding inline photos might sound nice, but wait until people start posting "amusing" animated GIFs in response to everything (I seem to remember in HipChat there was no way to turn those off…)
    - I stand by what I said about IRC being simple compared to the Composer, Drush, Git and other CLI skills we expect people to learn (and the learning curve for Drupal itself) and I agree with @crell's comments in #112. All chat systems have a learning curve - as far as the initial setup process is concerned, I don't think there's that actually a huge amount to choose between any of them, given all can now be web-based. And as someone who's unfamiliar to matrix and bridging, that's just as daunting to me as IRC might be to someone else. As far as everyday use, well, I find Slack's UI very cluttered, even when I turn as much of it off/down as I can. Please let's try and consider there will be a subset of users who feel the same way (and that's why many may have stuck with IRC). Also, to start with, we need to try and get all our *existing* users in one place whilst annoying as few of them as possible, then we can figure out ways to encourage others to join.

    lpalgarvio’s picture

    Good comments above,

    I'm not aware of all the possible configurations and customizations on many of the chat platforms.

    Among them, being able or not to turn off "someone is typing" or uploads, possibly can if at all be turned off at server level only, and not per channel, as these options don't exist on Slack or Matrix, at least, with the free hosted services (perhaps different with self-hosted Matrix).

    Animated gifs and all the extras are controlled via integrations/apps in Matrix and Slack at server and channel level, meaning, a server admin can approve / enable a set of integrations/apps, which in turn can be individually enabled per channel basis, by channel admins. I'm unaware if they can be force enabled for all channels.

    Important to note, on Matrix, non-channel admins can't change a channel integrations, and channel admins don't need to be server admins.

    In my view, webRTC is exactly essential, as we need to provide communities with a proper & functional way to communicate with voice and do conferences for the kind of events that require this (including but not limited to meetups, live conferences, public board meetings, etc). The world is dominated by closed source free/non free half-baked solutions that are generally not 100% synchronized or compatible with everybody's devices.

    This is exactly what webRTC tries to fix, with the end goal that all these proprietary chat platforms (skype, hangouts, talk, duo, whatsapp, etc) that failed to adopt XMPP and evolve it in collaboration, which instead did fubar EEE tactics, switch over to this new set of standards. While I understand not everyone will want to use it, there is so much to gain from using it and allowing the communities to use it.

    I can't give a precise indication about file sharing, regarding if files can and should persist forever, if they can be purged automatically after X time, or again, if they can be disabled. But having them creates new possibilities. Sending a file over a channel becomes more accessible than putting it over Google Drive or Dropbox and requiring a jump to another site and requiring (or not) a login in that same site.

    All the complicated stuff about Matrix and Slack rests alone on server admins and channel admins, or on special features like device approval, with not many people will use and is optional. Everything is very much simple until you decide to create channels (Matrix does offer a lot of options on this).

    In comparison with IRC, setting up channels properly (registered) is equally complex, but I find registering and configuring an account on a IRC server more complicated than on any of the other services described in this issue.

    I tried first Matrix (with Riot client) and didn't found it over complicated. I did find Slack and Gitter overly simple, with limited functionality (at least on the free versions).


    MustangGB’s picture

    We use Slack in our offices and it works fine for us, however in such a large community as Drupal is having less than a week worth of message history makes it completely useless.

    diqidoq’s picture

    Sorry that I didn't had and still don't have the time to read all comments here. It feels disrespectful but it isn't. This discussion is cluttered over several discussions actually and spread over a long time so that all the effort of people trying to explain their POV will be lost in the nirvana of this long scroll page. It's sad to see this but unavoidable.

    Tell me if I am wrong, but something what is missing from my flying visits all over the spots was, that somebody with more insights has mentioned to compare what other developer groups have in process of planning and if there are maybe similar discussions going on, which we should link or embrace to take a look over.

    Many of you will remember when the Drupal community got a hard and long discussion going on regarding its sometimes "isolated" position and solitary choices made apart from what's up around, and while I have to admit that I didn't understood every 100% concerns, I see the positive effect on Drupal 8 integrating with Symfony and Twig apart from code regarding community efforts. And while some old school Drupalianers maybe have mumbled against it at first place, many others have joined and communities have started to mix up and to automatically grow on both ends. It was refreshing. With some loss of course. But that's life. Something to watch all over many different situations in life and work. At least for me being long enough in a position to do so.

    As a project and company lead I have spoken last week to some of our employees, the developers in the company, and stated that I more and more see a real issue rising in the huge fragmentation going on in Open Source development (look at Linux Distros and DEs) over the years. And while I am an Open Source advocate, I still look for improvements to consider all the time. And to rise this issue is such one, and important. The unremitting split of man power is a huge issue in Open Source and "libre" community driven development because of developers hubris not willing to merge or to think outside the box. Or even worse: to believe to be the only small group of people to know what is best to do and split/fork/reinvent/seperate from the others.

    And that's why I would love to see more consensus here between large communities like Drupal with Symfony and Twig etc. regarding chat solutions. Like it was consensus with IRC back in the days. And that's what it made so available and improved (and maybe still is? Who knows). Please consider that improvement and availability has a strong relation to the consensus of many communities using it. As more consensus regarding this issue here with other developer communities will rise, the more future proof and less time consuming it will be to maintain.

    That's why one of the most important marks which have been made here, was, that some solutions integrate well with IRC. I saw my eyebrows perking up in that moment. Simple as it is: Integrating is the opposite of separating.

    betz’s picture

    Sorry if I missed it, but who manages the current slack account for the drupal rooms?
    We would just want to create bridges, so everyone can use their favourite app/service and be happy.

    betz’s picture

    Just want to link to another issue at #2885060: Drupal Chat Bridges IRC <-> Matrix <-> Slack
    Made an overview of most channels, on irc and slack side.
    We also started most matrix rooms on (linked from above issue).

    freelock’s picture


    lpalgarvio’s picture

    lpalgarvio’s picture