2 Likes
I use Slack and Discourse, I can say that the way we talk in both services are very different. 
1 Like
My experience is that there is a significant group of people out who:
- Are now very familiar with Slack
- Use Slack on a daily basis
- See how Slack has replaced email in many situations
- Are not as familiar with Discourse
There are many here that believe Discourse is often simply a better solution than Slack. Some of us apparently think this is always the case - others like me think there are real benefits to having both.
If you’re working with a community or organization where Slack adoption is already a success, I think framing the idea of introducing Discourse as a complementary system makes sense pragmatically, technically, and socio-politically. The original post was drafted as a starting point for this discussion. Perhaps Slack eventually goes away in an community like this, but I would be surprised.
If, on the other hand, you are working with a community that has not yet introduced either system, then the question is, should you start with Slack? Discourse? Or both? And in this case, I think “it depends” my answer, but I’ll save you the details for now.
Finally, if you are a community that uses Discourse exclusively, the question of whether to introduce Slack is not-so-obvious, but I think there are good reasons to proceed with caution. The right answer here is probably also “it depends”. Perhaps the original post is a good starting point for this conversation too, but in this case, I could see making a case for starting with Google Chat / Hangouts, or one of the up-and-coming plugins here as a starting point before going all in on Slack.
For what it’s worth, I find myself in the first situation now, which is what originally motivated writing those thoughts down. And when I saw someone on Feverbee was considering replacing Slack with Discourse, I wanted to share this perspective.
8 Likes
I was thinking about filing a class action lawsuit against Slack on the basis of its misleading advertising as a time saver.
Sadly, my imagination fast-forward to the Motion to Dismiss hearing filed by Slack attorneys. The judge’s first question was:
“What’s the name of this thing again?”
…
Motion granted, case dismissed.
8 Likes
Prepare yourselves for some weekend reading!
This is spot-on, and I consider this to be the key differentiator between the two. On the one hand you have the ephemeral content of a chat, and on the other you have varying types of perennial content. (grab your thesaurus and suggest something better if you’d like).
Ephemeral content has greater social impact
A few select forums develop a culture that transcends their common subject matter. Their “Off-topic Discussions” category might be the most active one of them all, with members talking directly to one another, sharing the kinds of things they’d share on a traditional social network.
While this is a rare occurrence on a forum, this is the norm in chat. Give it a little time and I assure you, it’s about to get personal. There’s something about sharing that moment, being together in the now, that lends itself to Getting Real. Getting personal on a forum feels more like broadcasting, made even weirder by metrics (Likes, Replies, View) that can unintentionally imply that my piece of personal news didn’t “perform” as well as someone else’s.
From a data perspective, chat exchanges such as “Holy sh** I just became a dad!”, “where’s our invoice template again?” and “I need fresh eyes on this weird query” are entirely disposable in the long term. But used right (stating the obvious here), the value cannot be understated.
Perennial content has greater historical impact
If you add a new member to a 10-person team, there’s no way you can tell that person:
“Getting caught up is really simple, just look at the chatlogs for the past 30 days!”
Content posted to a forum on the other hand is expected to stand the test of time. Not usually in perpetuity like a static doc page - which is at the very end of the “perennial content” spectrum - but for the foreseeable future. You put in there any type of content that you expect you’ll refer back to at least once.
Here, in the case of adding a new member to your team, you can actually tell that person to check out the last 30 days worth of forum posts. Even at 200 topics, it’s remarkably easy in Discourse to skim through these and quickly figure out which ones pertain to you based on:
- Categories
- Titles
- Participants
- Top rankings
- Strictly linear discussions in the topics you do check out.
Choosing the right communication stack
I think most projects benefit from a combination of ephemeral and perennial discussion platforms – that’s the real e-mail killer right there. However, there’s more diversity across the perennial platform stack, and that’s where I think forums are currently facing a greater challenge than chat. GitHub Issues, Kickstarter Campaign, Meetup, Google Groups, even StackOverflow tags; these are all perfectly viable discussion platforms for a small project.
Let’s take GitHub Issues for example
GitHub Issues might feel a bit awkward for longer discussions, but it gets the job done and it’ll take a lot of these discussions before you start seriously considering adding another piece to your communication stack. Add too many ways for users to open a dialogue with you and many prospective users won’t bother trying to figure out the right place to post.
So while Discourse only comes into play at a larger scale, GitHub Issues is immediately useful with 2 or more people, and it’s very low-commitment since it comes bundled with the Git repository you’re already using. I don’t see any reason nor way for the likes of Discourse to impose on this space.
The pitfalls of chat for discussions at scale
Similar to an issue tracker, chat scales all the way down to 2 people, but becomes somewhat unwieldy when you scale up into the tens of thousands, which is where Discourse excels. Specialised platforms like GitHub Issues fail to support discussions at scale because, well, they’re specialised for other things. The same goes for chat really, but since the distinction here seems more muddled for end users, I’ll elaborate.
- Chat is not good at accommodating global discussions carried across multiple time zones
- Chat only supports one primary topic at a time per channel, as opposed to discussions happening asynchronously
- Chat is non-linear, which is poorly suited for troubleshooting that doesn’t culminate in a solution shortly after the problem is presented.
- Chat discussions are difficult to leave and come back to because you have to time it just right for the discussion to pick up momentum again.
- Chat is not very outward facing. It doesn’t produce link-able content or best-of aggregations. When’s the last time you heard of a chat “going viral”?
Natural growth rate of a distributed team’s communication stack
I think most digital collaborations should and do follow this model:
-
You’ll start off with mostly perennial content, spearheaded by a platform specifically geared towards your line of work & strategy.
- GitHub/GitLab/BitBucket
- ArtStation/DeviantArt
-
If your initial prototype (by words, code, pictures etc) gets traction you’ll need to facilitate more effective coordination with your closest collaborators/users/peers by adding ephemeral discussions to the mix.
- Slack/HipChat/Gitter/Mattermost
- Hangouts/Skype
-
Your project becomes popular to a point where you need to support discussions at scale.
- Discourse / NodeBB / Vanilla
- Mailing lists / Google Groups (I tend to advise against the big G here, because they don’t provide a sane export option)
I don’t see Discourse effectively inserting itself into step 1 or 2, nor should it try to. I’m fine with only being relevant at a certain scale.
edit: We should and will insert ourselves into Step 2! And in doing so we’ll inevitably be creeping into Step 1 a bit as well.
24 Likes
Just to add to this, we found that the paid version of Slack was significantly less useful to us in some regards. Free accounts only provide access to the last 10,000 messages. It forced people to think about the service they use for each communication.
Paid accounts have no such limitation, once that limit went away we would all referring back to Slack for months-old messages.
3 Likes
I enjoyed your post and agree with most of the points. I’ve also always told people to use Slack for ephemeral chat. There are very useful conversations that happen through Slack and improve efficiency of communication for my team.
Where your argument sort of falls apart is in enterprise environments. There are a few points to make here:
- The fewer tools for communication, the better. There’s a huge inertia factor when you’re trying to get an organization to start using a tool. SSO is huge in this regard.
and the really big one…
- I work at a company with ~4000 employees. Enterprise IT groups usually are supposed to find tech solutions that work for the entire company. If we were to pay Slack’s $6.67/month/user for the entire company, it would cost us over $320,000 per year to use Slack for chat. In my case, thankfully, we are a non-profit and get free Slack accounts.
another non-trivial point:
- We work on a lot of USG contracts that requires us to have physical control of the hardware hosting files that we share. We can’t do that with Slack (though we could with HipChat or Mattermost, etc.)
So, from my perspective, the first bullet is the real point/problem here. The third point also comes into play.
Discourse is much closer to also providing the features that make Slack useful than Slack is to providing the features that make Discourse useful.
Let’s say that I went to my IT group with a proposal to use one of these tools.
A) Slack. $320k/yr. No forum for perennial content. Email integration is shit. Files are stored off-site.
B) Discourse. Free (see below). Stores perennial content, Email integration is fantastic. Files are on site. No chat.
IT are wary of free things, so let’s say that you guys agreed to support/manage Discourse on site for 10% of the cost of Slack. The only argument against going with Discourse, then, would be the potential need for another tool to fill the chat gap. The company could provide the best of both worlds and save ~$290k annually.
Figure out some way to fill the chat gap and the choice between these two is extremely clear for enterprise customers.
Probably too late for a ninja edit, but here’s Slack’s forthcoming enterprise solution, which is even more expensive:
If the $32/user/month is correct, it actually would cost a company the size of mine $1,536,000/year to use Slack. Enterprises pay this type of money for garbage like Salesforce. I’m currently battling against Salesforce Chatter as a corporate chat platform. We pay millions/year to use it and it is freaking terrible.
10 Likes
Great insights, thanks for sharing. And before I continue, I should emphasise that these opinions are my own, and do not reflect Discourse’s strategy.
I definitely do not want to see full-blown chat built into Discourse core. It can make sense as a plugin, but even then primarily as a gated sub-community, i.e. for TL3 or moderators only. (Lounge being a chat room would certainly be interesting).
It should remain a plugin because teams that are already heavily invested in a separate, richly featured chat platform will not want to move away from that, so it’s more strategic for us to make chat plug-and-play, be it via a native plugin or tight integrations with other platforms.
This is strictly an issue of cost though. If a Slack-competitor like Mattermost introduces a hosted service based on traffic instead of seats, you’d be fine.
3 Likes
I completely agree that we should not aim to insert ourselves into 1. We are not Kickstarter or GitHub and have no plans to be something like that. Though there is an open question about embedded discussion which I do not think we need to grapple with.
However, I feel there are enormous amounts of parallels between us and Slack and would much prefer an integrated solution to 2 separate solutions.
I agree that chat should not go in core for a while longer, but core should facilitate chat.
Slack’s meteoric rise is a very important lesson. It is important to remember, it was launched when there were an enormous amount of existing solutions for the exact same problem.
Campfire and HipChat predated Slack by a few years, yet failed miserably in comparison. Slack entered a completely saturated market that was not making much money and created an enormously profitable product.
This was done not by using Magic 
s
-
They had the best UI, period.
-
They had the best in class, viral marketing campaign I have seen in many years. When Slack came out people were fatigued by chat solutions, at Discourse we had already left HipChat and were using Kato. In this fatigued market you had hoards of people saying … “I am bored with chat” … “Oh, but have you seen Slack, it is really cool” … people were clamouring to get on the beta.
-
They kept refining the product, correctly and in a fast enough rate. HipChat was stagnant for over a year, Campfire was stagnant for many years. The product managers for both HipChat and Campfire simply “got it wrong”. What the market wanted was a great UI and a product that evolves. We waited a year on HipChat to grant the “privilege” of editing a typo. Emojis… Oneboxes … forget about those.
-
They sold the product … This is kind of obvious, but an interesting thing is that Stack Exchange had a public chat product that was launched more than 2 years prior to Slack and was vastly superior to all the other web chat programs around at the time. 2 years later HipChat was no where near being able to catch up with it. Still today there are quite a few feature Stack Exchange chat has that are missing from Slack. Even today on Slack it is complicated to reply to an old message, for example.
-
They embraced the web, and built a unique and consistent cross platform solutions.
From the early days of Discourse we always kept chat in the back of our minds. We considered “Chat” / “Buying and Selling” / “Questions and Answers” as different flavours of discussion. We have always been a bit reticent to deal with the “Chat” problem cause “Chat” is the Crack Cocaine of web discussion 
. Civilized chat is only doable in very controlled groups. Even in small groups chat tends to bring out the worst in us. It encourages short and raw communication. You don’t have time to refine an argument when you got to keep filling the white box and hitting ENTER
That said, there are just so many parallels between what we do and Chat.
- We support a very rich security model to facilitate proper groupings of people
- We have the message bus that gives us live updates
- We have a very rich Markdown engine
- We have a great system for community flagging
- We have bookmarks, replies, quotes
- We have a pretty good search
The only feature that is missing from core to allow for a clean chat plugin is “presence” aka… “Who is here and who is typing”
Except for that, well, we are chat. To make us behave more like chat we simply need a different UI as the 2 existing chat plugins show.
Personally, I feel quite uneasy that so much of the world is so comfortable moving all their internal communications to a walled garden where you have to pay minimum of $12 a month per user for the right to export your data. This is a huge step back from where we were with Email.
I also notice so many of our smaller trials struggle to seed a community, chat let’s you blaze through the early days, it is perfect for small groups of people engaging in unstructured conversation.
When it comes to “integrating” chat I see a few directions I would like to explore:
-
A richer messaging system. Messages can act like chat a lot of the time, they often involve rapid and somewhat raw conversation that are unfocused. It is a balancing act, cause it could be very onerous to be forced into chat with everyone the messages you. That said, in many cases chat can be perfect.
-
A distinct chat UI that ships as a plugin. I feel a lot of the fear of chat is having it infect a forum with unwanted features. Trying to jam chat into a site can feel very forced. A full screen Slack like chat UI could easily act as a compliment without forcing its way into the forum UI. The big advantage here is that so many of the features are shared and there is lots of value in having a single integrated notification stream. Also, another great thing that can be achieved with this is allowing people to cleanly “break out of chat”, select a few messages and turn them into a proper topic.
I am less enthused about shoutbox like UIs. One may argue that a “shoutbox” is a perfect fit for moderators, I personally think it has little advantage over moderators having another “chat” page open, especially since notifications would easily pull them into the chat UI.
With all of this type of work we have to be very careful about timing and not spreading ourselves too thin. That said, we are thinking about this stuff and how to make some progress this year.
39 Likes
Totally agree with you. 
Chats are potentially dangerous in several terms of civilized discussion integrated into a community system that is focused on helpful, streamlined, well-structured threads.
Maybe a Discourse community shouldn’t be conform with additional Chat functionalities. Eventually there is a different kind of (open source) solution needed.
Over the years there a so many messangers. All of them had their good times. ICQ e.g. was very popular for casual people, IRC for experienced and IT affine user groups (moderated), Facebook Chat (with real time filtering of content / censorship) is good for gated communites (like friends, colleges). And many more.
I guess the answer is in between. The users are pointing their suitable chat solution and not vice versa. You and the whole Discourse team are doing a great job. But I think, Chats with some kind of intelligence and civiled, structured conversations requiring machine learning features. I can’t imagine, this could be possible by any small scale server infrstructure of individuals.
Thanks for your post!
3 Likes
As you said, chat for private messages or group messages up to 10 participants is enough to bridge the gap.
Chat may is great to improve on-by-one relationships with my community members
Like it! It would be nice to have
2 Likes
If you limit it to 10, you’ll immediately find a customer who needs 11.
The point of Slack is that much of the communication is opt-in. If Discourse offered chat or group messages with limited numbers of participants then the feature could go untouched.
I really like this also - great idea. We already have started using messaging to “stage” discussions for community topics, and being able to do this in a more immediate way in chat would be very valuable.
4 Likes
I run a distributed team of developers. We had a Slack account. I shut it down for reasons already mentioned. It can be an unproductive distraction. It can be addictive. It doesn’t retain knowledge. It can be closed and isolating. It can bring out the worst in us.
Basically It’s like a sexy fling that lingers on too long. It starts out being fun and ends up making you feel bad about yourself in the morning.
Initially after I banned it, it felt good. Being single (asynchronous) again was great. I could get stuff done again and focus on what was important. But being single starts to wear on you after a while. You miss that human connection. You start to feel you’re missing out on something that everyone else is enjoying. And perhaps the cycle begins again…
How do you break out of that? Ideally you find someone who you have a connection with, but doesn’t drag you down. A supportive relationship that lasts.
Just like I want to believe that long term relationships can be fruitful, I want to believe it’s possible to combine chat and long form discussion. I think @sam is on the right track. Just like a good long term relationship, perhaps you need:
-
Positive independence. You like each other, but need your own space sometimes to stay sane. The UIs shouldn’t be too intermingled.
-
Complimentary strengths. Being good at different things can be great if handled correctly. The features shouldn’t conflict.
-
Openness. A free flow of communication helps. Shared notifications, easy transport of content.
-
A positive tone. Being negative all the time, even if its shared, can drag you down. The tone the product sets is important.
I think Discourse has a great chance of being ‘the one’. The one that manages to tread the precarious path to long term happiness. In addition to the reasons @sam gave, I would add that Discourse has a head start on that elusive fourth element.
19 Likes
IRC Integration?
I’d like to chime in about IRC. Internet Relay Chat has been around for about the same time as the Web, and is still very, very much used in the free software development community. In other words, IRC users are unlikely to move to a Web-based solution for their chat needs. I know I won’t: a team required me to use Slack, and the first thing I did was to plug into the IRC gateway so I can have it along with my other messaging systems, in my terminal.
I know there’s Mattermost and its IRC gateway, but I’d like to suggest another approach, far lighter than installing a Web-based messaging system that provides full Web fanciness.
Here it goes:
IRC Logs
A Category could maintain IRC logs, one topic per channel, with configurable host and channel.
This feature would automatically capture links and images or video if some are posted, and of course support Markdown if people use it (although it could also use the simpler IRC idiom with a single * for bold, etc.)
Providing IRC logs in Discourse would help make them searchable. Moreover it would allow Discourse users to use shortcut links to relevant IRC channels. These topics would be read-only.
Topic to IRC Channel
This would be the next step, to allow Discourse users to send to a specific IRC channel. Not so difficult using an IRC bot as a trampolineintermediary, but not so elegant. I’d rather not focus on this feature and encourage users to get a proper IRC client, but that could be useful for live support in some specific cases. Honestly I think it’s overkill and would not even try to implement it.
Matching IRC User with Discourse User
Given an IRC network with a NickServ, a Discourse user could indicate their IRC account in their personal profile so that the IRC topics could link to them directly, and so that Discourse would take into account their IRC participation within Discourse participation metrics. This is an interesting feature because more often than not Discourse is not the unique way a community has integrated in its workflow. (And this could be extended to other external services such as a wiki or a gitlab…)
5 Likes
Hi Sam, I saw this pop up on Twitter today… great post.
To comment on this:
When it comes to “integrating” chat I see a few directions I would like to explore:
- A richer messaging system. Messages can act like chat a lot of the time, they often involve rapid and somewhat raw conversation that are unfocused. It is a balancing act, cause it could be very onerous to be forced into chat with everyone the messages you. That said, in many cases chat can be perfect.
I wonder if there are a few other elements for chat:
- No topic. Messages between users are just the message. Even simpler.
- Smaller window for writing. Implies the message will be shorter (vs. paragraph style). This also allows the discussion to remain visible while replying (vs the input box and keyboard taking up the screen when replying) and for the ‘post’ button to be more prominent (when you start typing in WhatsApp, a little arrow appears next to the text you’ve typed).
- Fast notifications. On the app, the caching can mean a significant delay between new post and the app icon badge updating - vs. the sense of ‘instantaneous’ updates for WhatsApp/Slack.
My amateur understanding is that this cluster of UI elements supports the chat experience.
3 Likes
I’d like to see deep integration, perhaps with Zulip,
which is also instance based and fully open source.
1 Like
We already have Zulip integration:
6 Likes