Why you should use Discourse internally for your company/team instead of Slack (4 years use case)

praise
1

We have been using Discourse as the main tool for communication, record keeping, research documenting, lab journaling tool for over 4 years.

I will argue that most companies would greatly benefit from having Discourse as their main communication tool rather than Slack & email chains & WhatsApp.

It boils down to this: If you believe there is any value in the conversations between employees for future reflection then you need Discourse.
The simple reason is that channel based instant messaging apps (Slack, etc.) are good for just that - instant conversations that no one would want to go back and review unless looking for something very specific. They tend to intertwine multiple conversations into one long channel with thousands of lines and hundreds of sub-conversations.
Conversely, Discourse inherently breaks down conversations into categories, topics and tags which makes it very powerful for team members to get onboarded on specific topics, areas of research and related conversations simply by reading the Discourse topics as a journal and not trying to pry out what happened from a channel that had 6 other topics of conversation including everyone’s lunch order fused into one text stream.
If your Company/Team/Lab engages in any sort of R&D, I believe Discourse is a must.

Chat - The missing link

Not all conversations are information goldmines… in fact, many conversations are day-to-day things like: consultations, questions, quick brainstorming sessions that don’t necessarily amount to it’s own topic. Not to mention statements like “I got this bug and error log, who knows what it means?” or “What are we having for lunch today?”. So Slack really had to stay there for everyone to communicate quickly and efficiently. With the introduction of Chat into Discourse, all forms of conversation and discussion could be integrated into one great platform!

Our setup - Fast & Secure

We installed Discourse on AWS EC2, in the first couple years we were a small team of ~5 people so t3.small was more than enough. Today we are bigger and richer so we can afford an m5.xlarge
Since we are running and AWS server, we can give it permissions to S3 bucket, therefore easily enable S3 object storage for uploads so all attached files, images, excels, csv, pdfs are backed up safely.
We enable Secure Uploads which protects our data (We set Discourse to invitation only mode and deny access to the forum or the files for any non-logged-in visitor).
Note: We of course ignore the recommendation to use CDN as it would defy the purpose of secure uploads.

Plugins for productivity

  • Assign → assigning topics to people is a good way to have a team member own a ticket/issue/project
  • Math → If you do research, you need Latex and equations support
  • Reactions → This is just modern communication. Should be built in Discourse imho.
  • Shared Edits → Very nice for teams to share and edit some wikis or other knowledge/information pages.
  • Whos Online → In a team it is a must to know who’s online
  • Footnote → companies need legalities… this is the place to write a confidentiality clause.
  • Arguably Calendar is useful but the way it is implemented and functions is not a good fit for us. Topic Voting is another potentially useful one.

Theme components:

  • Custom Header Links → Put the company/team important links on the header. We have vacations board, “my tasks” (for the assign plugin), link to our Jira board…

  • PDF previews + iframe Lightboxes → installing both of them together, and setting the iframe origin domains to include your own domain, make all PDF files uploaded to the forum appear open inline with the threads and have a button to expand to full view. PDFs are very very useful and this way make it easy to share them.

  • Discourse Chat Sidebar → Bring the chat to the front, we all use 24" to 27" screens and We want to move all the Slack/WhatsApp action into Discourse.

  • Honorable mentions:
    ** discourse gifs which should be built in to Discourse imho.
    ** Discourse Kanban that doesn’t replace Jira but it helps with high level tasks and works well with “assign plugin”. It just needs to be configured correctly and it wasn’t trivial to do.
    ** Sidebar Theme Toggle we only use the default dark/light theme so let the user easily choose their preference

Conclusion

First of all thank you to the amazing and inspiring Discourse team :clap:
Discourse is a no-compromise rock-solid, fast, secure communication platform and I hope more teams will be inspired to use it for Companies, University lab teams, Start-ups and more!

81 Likes
3

Loving your insights about how you use Discourse. Here’s a convenient call to other readers :loudspeaker: that we’d love to hear more about you might be using Discourse internally. This really helps us learn about what’s working out, and prioritise fixing what isn’t working out.

We ourselves use Discourse internally, so it’s kind of fun hearing about our similarities and differences (not much!).

:writing_hand:t2: taking notes – We’ll think about these, thanks!

22 Likes
4

Thanks for the insights. You got me thinking about the traditional combo of chat - e.g. Slack, Mattermost, Rocketchat plus knowledge sharing- e.g. Confluence versus Discourse as a platform to handle all of that.

Since you are self hosting your own Discourse instance, how do you handle notifications on the phone? My understanding may be a bit outdated, but on the web, we can ask users to enable their browsers to send notifications from the site. On mobile, I don’t believe notifications are sent to the phone lock screen unless the Discourse instance is hosted by Discourse itself. How do you handle notifications of chat responses / topic replies when there is frequently time sensitivity associated with them?

9 Likes
5

I must admit that push notifications are a pain point at this time.
The built in push notifications work (sort of…) for Android and Desktop users, not for iPhone users.

The issue with push notifications in my opinion is that there are too many obstacles for them to get through to users. You have to enable it on Discourse personal preferences, you have to allow it on the browser, you have to allow it on the android/windows system. If any of the three is blocking notifications, then users don’t get them. Personally, even though I actively want push notifications, I always find that they stop after a random period of time. Maybe because of browser updates? no idea. So even within Android I can’t say that it really works as I would have liked.

Yesterday I tried Pushover notifications that solution functionally works on Android/Apple/Windows, however, it has two major faults (which is why I didn’t end up using it):

  1. it requires every user to install a third party app on their phone and manually copy their user_id to the Discourse preferences page :grimacing:
  2. The notification pops up and instead of directly taking you to the Discourse Chat/Topic, it takes you to the Pushover app, from there you can have a second tap to the URL of the Chat/Topic. It might sound a little petty, but as far as direct messaging notifications go, to add a gateway app between your push notification message and the actual place you want to go is debilitating the experience.

Discourse is always improving, with dozens of commits per day so i remain optimistic that the push notifications would improve. My ideal scenario would be an open source native Android/iOS app that can be customized and submitted to Play/App store by the admin. But perhaps working through third party like OneSignal and the likes could be simpler and achieve the same purpose.

9 Likes
6

Thanks for testing the push notification options. That’s my impression as well, which is that there are too much friction no matter what the options are. Its not a Discourse specific problem, but a problem that holds Discourse and similar platform back from becoming more widely adopted- that notification and user stickiness from the notifications.

4 Likes
7

We are absolutely thinking about push notifications, the tricky thing is that we simply do not want to handle data for forums not hosted by us.

There are technical workarounds, we could say “Hey phone, site X wants you to refresh” this may work around the major limitation here. Maybe there is a way to encrypt payloads as well which can solve this.

These days PWA on iPhone (as long as you are not in Europe) and PWA on Android work quite well. But the Europe curveball makes us think a lot more about the app.

17 Likes
8

I’ll just second the part below

I find PWA notifications work well on Android when it is working but this tends to be the minority of the time because of how long it takes me to notice when it stops working.

2 Likes
9

We made a bunch of fixes recently, my PWA pushes on my phone have been solid for months now. Not saying this is solved by any means, but if the data point is “I had issues last year” then I would strongly recommend trying again.

That said… Apple killing PWA in Europe means we got to grapple with this problem and we will.

9 Likes
10

If by last year you mean December 2023, then maybe that aligns with the timing. It’s hard to know when it stops working because the lack of notifications is not an obvious signal. The last time it stopped for me was sometime between December and January.

In my experience so far it’s been a cycle of ~1 month of notifications and ~2 months of me not noticing they are off. Then turning them on to restart the cycle. I’ll try again, and hopefully it won’t happen again. A bigger worry is that I’m the biggest poweruser on my site by far. The average user is not paying attention to these things like I am. I bet at this point only a small fraction of them have visited the notification settings more than once.

I just checked with the data explorer now, and I have 30 active users with a push_subscriptions record on a site with 450-500 users visiting daily. That’s about a 6% usage rate. A third of those have updated since 2024.

I appreciate all the work done on this front and I understand a lot of it is dependent on external factors (ie. Apple, Google). But I just want to voice my opinion that “working quite well” neither aligns with my experience nor the OP.

6 Likes
11

Which as we know is now no longer the case.

Still want to see Discourse a standard bearer for PWA deployment and push notification hegemony bashing!

9 Likes
12

There is also a Tickets plugin that may help to get closer to jira.

There is also a plugin version of inline pdf previews that if I recall works also with mobile.

1 Like
13

We use Discourse send PDF inline without complaints.

5 Likes
14

Indeed as I recall your plugin also allows this to work on mobile. Still need to install it myself. Awesome plugin addition.

15

@Alon1 It’s great to see some discussion about internal communities as it comes with its own unique challenges. In particular moderation can be a very different beast. NSFW and spam posts are pretty much out of scope, but replacing them is the importance of topic fidelity, clarity and adherance to confidentiality requirements.

I’m curious, what kind of things have you done to ensure the quality of topic is high? What does your moderation team look like, and how hard was it to get management to understand this necessity?

5 Likes
16

Thank you for this most interesting and useful report.

My path is similar with using Discourse for building my personal and organizational virtual infrastructures.

I am mostly a solo entrepreneur with a few core projects ongoing for decades. So I need the tools to spin up new paths and sub-projects (and sub-sub-projects) and tasks on-the-fly.

These are writings and collections of related research.

I use and test lots of diverse open source (as well as paid - I don’t discriminate) tools and platforms, for efficiency and simplicity.

For the last few years I’ve found Discourse and Ghost the most often at the center of my various workflows.

4 Likes
17

You’re raising an important point!
Every forum has a culture that builds around it and a status quo that is formed over time.
When I started using Discourse as a means to communicate between team members, preserve research insights, track conversations better than email chains, etc. in the beginning of COVID19, I wanted to make sure that this tool is used correctly, well at least according to my vision of what “correctly” was.
In my case it was not so difficult because we were a team of 7 people in total and I could literally guide every single person in the team to create topics that are well separated in their subject matter, yet not duplicating the same subject over multiple topics. That replies are written with future value in mind (e.g. you did an experiment? describe it, give context, show what and how you did, use graphs with axis labels… so that when you read this post in a few months, it will have value to you), put stuff in the right category, be efficient - write the most amount of information with the minimal amount of words, be kind, and so on.
Once you have a good core culture, every new employee that joins the company naturally embraces it with minimal guidance.
I still do the occasional conversation with specific people about how their topics and replies could be better. This helps to maintain good culture.
Bottom line, I believe if you work on your core culture when you are small, it scales nicely when you grow.

8 Likes
18

How do you handle it if you have cross department discussions, but you don’t want to make all users a member of the other departments group. Or maybe you have all discussions available to everyone? In my case, some department level discussions should be hidden from everyone else

1 Like
19

Everyone belongs to one or more groups, and i managed permissions of specific to access specific categories.
While there are two categories that are open to all groups, some department specific categories are only available to the relevant groups.

The ability to have a person in more than one group solves this issue. You can design a group for cross-deparment employees, while keeping their main group relative to their original department.

4 Likes
20

IMO this is one of the the most important decisions to make for internal communities and shouldn’t be rushed. We’re mostly an internal Developer community, so I opted for a tools-based approach. This decision alone has broken down silos whilst also satisfying the information security office in terms of information restriciton. We went the same way as @Alon1, having users in multiple groups- just join the group for the tool you have interest in.

We also have a platform wide policy that confidential and project specific information is prohibited – almost all problems can be described without mentioning the client.

How did you get management to understand this? Even presenting them with examples of failed communities, they really can’t comprehend how serious of an issue this and see it as pedantic. We’ve had a decent culture until now, but management are obssessed with scaling no matter what. It’s nice that they value the platform, but it’s problematic that they don’t understand its value has come from the culture we have built – something which is currently under threat by scaling too fast.

Another issue we’ve faced is that everyone wants their own Category. For anyone considering an internal community, just know that it’s a very fatiguing part of the job saying no to managers who are used to hearing yes all the time :sweat_smile:

4 Likes
21

Indeed Category Permissions are very valuable.

A department could have 2 groups for example. 1 that houses leadership(ones who might in some categories be allowed to create topics). Though Can also do this with tag groups restricted to specific group.

1 Like