Problem/Motivation

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.

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

Problems with chat, regardless of technology used

Some things are just problems. We can automate solutions around a SAAS or we can automate solutions around irc.

  • 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

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)
  • Few high quality apps, especially for mobile devices
  • The lack of a “user is typing” indicator slows down conversations.
  • Many contributors haven't used irc before, and new tools can be a struggle for even technical users.
  • Although possible, it is difficult to create hooks into third party services. e.g.: creating a hangout in slack: /hangout (todo: are there other examples?).
  • @todo add additional examples

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
  • @todo add additional arguments

Other open source projects still using IRC besides Drupal

  • Fedora Project
  • GNOME Desktop
  • Asterisk
  • linux
  • python
  • debian
  • ubuntu
  • git
  • vim
  • puppet
  • bash
  • docker
  • postgresql
  • nginx
  • php
  • Ansible
  • mysql
  • sensu
  • OpenStack
  • Mozilla
  • Ruby On Rails
  • @todo add additional examples

Open source projects using slack

  • Wordpress increased the number of connected people 4x when switched (doesn't necessarily mean 4x the participation) @todo add a link to source of statistic. Their #wordpress support channel still remains only on IRC.
  • @todo add additional examples

Some of the concerns to consider for choosing chat client

  • be considerate that people may NOT want to have backscroll
  • be considerate that people do want an Open Source solution
  • be considerate that people many not want project administrators to be able to see the content of private messages

Proposed resolution

Possible solutions include:

  • 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
  • Slack, SAAS. Meets most of the features requirements listed, but does not meet goals related to FOSS/privacy philosophy.
  • 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.
  • Hipchat, SASS. It meets most of the features requirements listed. 3rd party integration, but does not meet goals related to FOSS/privacy philosophy.
  • Mattermost
  • Zulip is another chat service, locally hosted.
  • Rocket.Chat is another chat service, locally hosted.
  • @todo add additional proposals here

Remaining tasks

  • improve issue summary documenting more detail that has occurred in conversation. see the @todo's there.

==========================================================

What are the benefits?

Get more people chatting
Lower barriers to entry to new community members
Increase signal-to-noise ratio of communications

What are the risks?

Some people might dislike new chat client, especially if it requires running an application just to communicate with the Drupal community

How can we measure the impact of this idea? (metrics)

Collect the number of people in a few channels at a few different points in time.
Does freenode keep stats on usage? Alternatively we could analyze the logs for active user names. WordPress provides their IRC logs at http://irclogs.wordpress.org/.
We should be aware there is a difference between the number of people in a channel and the number of people active in a channel and the number of people who have ever joined a channel (which in slack may appear to be in a channel)
And...??

  • #drupal Sunday 23:00 UTC - 432 people
  • #core on wordpress.slack.com Sunday 23:00 UTC - 152/4164 people (but we need data from before the switch when core was on freenode)

Who directly benefits from / will use this improvement? (target audiences)

  • People who want to communicate via chat with the Drupal community, but are resistant to installing an IRC client and using IRC.
  • People who are already using IRC to chat with the Drupal community, but are frustrated by IRC particulars, or are wanting new features available in other communication programs.

What additional resources available for discovery/implementation? (volunteer effort, financial backing, etc.)

Files: 

Comments

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 drupal.org 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 drupal.slack.com or drupal.hipchat.com?

I created drupalcore.slack.com and drupalcore.hipchat.com. Feel free to try to join them and play around.

joshuami’s picture

I'm checking into who created drupal.slack.com. 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 drupalcore.slack.com. 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 drupal.org 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 drupalcore.slack.com account has been changed over to drupal.slack.com 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 drupal.slack.com namespace for testing possible integrations.

Mixologic’s picture

Issue summary: View changes

Here's another open source slack clone:
http://www.mattermost.org/

kattekrab’s picture

@joshuami

"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

Telegraph.org 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 larachat.co, 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
Dave

realityloop’s picture

Issue summary: View changes
realityloop’s picture

Issue summary: View changes
lsmith77’s picture

what about talking to irccloud.com 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

Hi,

I'm also willing to test slack, could you invite me please ?
Here's my email address: pol.dellaiera@gmail.com

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? https://sameroom.io/open-a-tube

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 USERNAME@chat.wordpress.org 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: https://telegram.org/blog/channels

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

heddn’s picture

https://zulip.org is open source and has clients for many platforms.

Crell’s picture

lsmith's suggestion of contacting irccloud.com 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: https://facebook.github.io/react/blog/2015/10/19/reactiflux-is-moving-to...

tim.plunkett’s picture

Ooh, even better, they posted the research they used to make the decision: http://www.jordanhawker.com/posts/131477030371

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. https://make.wordpress.org/chat/.

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

@wizonesolutions

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

marcvangend’s picture

I just came across this post https://drewdevault.com/2015/11/01/Please-stop-using-slack.html 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.

https://slack.com/screenhero
http://blog.screenhero.com/post/109337923751/screenhero-joins-slack

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 https://drewdevault.com/2015/11/01/Please-stop-using-slack.html 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;)

killes@www.drop.org’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.

killes@www.drop.org’s picture

I don't share the belief that lowering the barrier to entry is a good idea.

irccloud.com probably is one of those "potentially unreliable 3rd party providers".

You of course are free to use it.

joelpittet’s picture

@killes@www.drop.org 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. http://www.theverge.com/2014/11/24/7255199/slack-alters-privacy-policy-t... 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 http://shout-irc.com/ 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 https://rocket.chat/deploy

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 https://www.quora.com/unanswered/How-does-Rocket-chat-make-money 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 https://matrix.org/ 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? https://www.google.hr/trends/explore#q=irc
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 (http://druplicon.info/ and https://www.drupal.org/project/bot) 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. ( http://drupalslack.herokuapp.com/ )

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 http://www.drupal.org/chat. 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

http://webchat.freenode.net 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: http://www.mattermost.org/what-slack-might-learn-from-its-open-source-al...

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 PTO.im.

freelock’s picture

+1 for Matrix.org -- 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: https://vector.im/beta/#/room/#freenode_#drupal:matrix.org, 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 - https://telegram.org/
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:
https://github.com/FruitieX/teleirc
https://github.com/RITlug/teleirc

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

Bridge IRC to Mattermost:
https://www.mattermost.org/mattermost-v1-1-open-source-slack-compatible-...

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

Bridge IRC to Rocket?:
https://github.com/RocketChat/Rocket.Chat.Federation

lpalgarvio’s picture

Hey,

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
Telegram: https://telegram.me/drupalportugal
The bot is named Druplbot and can map as many IRC channels <-> Telegram groups as needed.

https://github.com/FruitieX/teleirc

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 -- http://riot.im, 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 Matrix.org 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 https://riot.im/app/?#/room/#freenode_#drupal:matrix.org, https://riot.im/app/?#/room/#freenode_#drupal-migrate:matrix.org, https://riot.im/app/?#/room/#freenode_#drupal-commerce:matrix.org 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 riot.im -- 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, Riot.im does have emoji...

But using them breaks Druplicon!

willwh’s picture

Thanks freelock, I hadn't seen riot.im before :)

I've been using this for a while as my self-hosted IRC: https://github.com/thelounge/lounge, although I couldn't live without database logging, so I made a PR; https://github.com/thelounge/lounge/pull/506. 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:
https://www.drupal.org/node/2798167

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."

https://facebook.github.io/react/blog/2015/10/19/reactiflux-is-moving-to...

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 rocket.chat!

  • 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 https://matrix.to/#/#freenode_#drupal:matrix.org, 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 matrix.org 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:

- Matrix.org 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 Matrix.org 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 https://riot.im/app/#/room/#drupalportugal:matrix.org (also world readable) ; and the Dutch language channel https://riot.im/app/#/room/#drupal-nl:matrix.org 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 https://riot.im/app/#/room/#test:matrix.org 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 drupal.org, 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

@markcarver

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 Matrix.org bridge, but if that goes away another can be set up. Anybody else can join there via Matrix.org, or their own Matrix server. Drupal.org 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 Drupal.org 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 Drupal.org, I don't even think we'd need a Node.js component, aside from bot-type behavior).

Cheers,
John

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 Drupal.org, 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.

http://blog.gitter.im/2017/03/15/gitter-gitlab-acquisition/

https://about.gitlab.com/2017/03/15/gitter-acquisition/

https://news.ycombinator.com/item?id=13877156

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
- Riot.im / Matrix.org
- Gitter
- Telegram
- IRC

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 <-> Riot.im/Matrix.org via Slack's ingoing and outgoing webhooks apps
Gitter.im <-> Riot.im/Matrix.org via Riot's Gitter integration
IRC chat.freenode.net <-> Riot.im/Matrix.org via Riot's IRC integration
IRC chat.freenode.net <-> 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 drupal.slack.com 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 :/