DEV Community

Cover image for Why I dislike chat-based platforms for OSS communities
Bobby Priambodo
Bobby Priambodo

Posted on • Originally published at Medium

Why I dislike chat-based platforms for OSS communities

This article was first published on Medium.

For the past few years, I’ve been trying to keep myself up-to-date with the latest news in technologies that I’m interested in. I started going through the “Community” pages of many OSS products, from programming languages to tools and libraries. I registered and subscribed to many platforms, mailing lists, IRC channels, subreddits, etc.

Fast-forward to today. Among all the platforms that I tried, I can say with confidence: I dislike chat-based apps. By “chat-based apps”, I am including the most prominent ones on this field, such as Slack, Discord, IRC, and Gitter. By “dislike” I mean that I prefer not to use them if possible, unless the issue is pressing and no other choice is available. Unfortunately, several communities seem to use it as their primary channel of communication.

Note that I’m not saying that Slack et al are bad products. I use Slack at work and it’s been very helpful with its integrations and such. Seeing how most communities have at least one chat-based channel, I also believe that it definitely has value for some–if not most–people.

Now, with that out of the way, let me tell you why I think the way I do.


I dislike chat-based apps because they are synchronously real-time.

What’s so bad about it? Real-time is good! We make everything real-time nowadays! Well, Let’s see how being synchronously real-time can hurt communications and the community as a whole.

1. Great conversations vanish into thin air

At times when I lurk at some Slacks and Discords, I can’t deny that is where many discussions on interesting topics got initiated. It also solves many issues that needs to be solved immediately.

But then that’s that. The discussions and solutions there are not globally searchable. AFAIK there’s still no way a google search could point to a specific point of conversation in a Slack channel, so it’s not really SEO-friendly. Perhaps it helped one user, but it will not help the next person, and they would need to ask the question again.

Unless someone put the result of discussions into a blog or something, there will be no record of the exchanges whatsoever. Of course, there actually can be a record, by using services such as SlackArchive.io. But good luck finding specific conversation there–which brings me to the next issue…

2. It’s unorganized and hard to keep track of conversations

With many people speaking at the same time, there’s a high possibility of race conditions. Two or more questions got asked at the same time and many people tried answering them in the same manner. Who’s replying to who? Has the other person finished writing their answer? There is no logical way to group messages. Even after Slack introduced message threads, I never see anyone actually uses it in OSS Slack channels. They mostly stick with the IRC style of conversation.

As software engineers/developers, we embrace efficiency. We embrace the DRY principle. It should be the same with questions–the same question should not be asked twice, or at least there should be a way to answer the second question by only a reference to the first one. It would save everyone’s time. Stack Overflow does it with duplicate questions. Quora does it with merging questions. You would need to search for a similar question before posting your own. But that is impossible in chat-based apps; you have no choice but to ask the question again–not knowing if it has been asked and answered before.

Seriously, I’ve seen an instance where a question was answered by “please scroll up a few hours”. For longer than a few hours (or less if the channel is really active), the answerer would have no choice but to write their answer again.

3. It’s distracting

It being synchronous means that if I post something, I would need to keep the window open and focused to see whether or not I get responses. It’s good if someone mentions your handle when they answer and you receive notifications, but at times they don’t. I simply can’t do other things; leaving the app would introduce the possibility that the response (if any) is far up already; drowned in other chats.

It’s even more distracting than Facebook and Twitter, which I am able to open only occasionally and not miss out on many things.

4. Language barrier for non-English speakers

It being real-time might introduce problems to non-English speaking users that may not be used to expressing their ideas in English. It might take time for them to write questions, and write the replies to the answers. My English is not perfect, and there are times when I can’t find the vocabulary that I needed to express what I want to know exactly. The real-time aspect of chats can be intimidating.

Of course, me being generally an introvert might have something to do with that, and I’m trying to improve my English over time. However, doing things less real-time-y and asynchronously would certainly help me compose better messages.

5. Timezone issues

This is where chat-based apps being synchronously real-time hits me hard. I live in Indonesia, and the timezone here is UTC+7. The timezone in the US (where most interesting things happen) ranges from UTC-8 to UTC-4, which roughly translates to 12 hours difference from here. That means their noon is my midnight.

I don’t know about you, but I’m not keen on the idea of asking questions in the middle of the night, even when doing so will get more active responses from the folks on the other side of the world.


So what’s the solution?

What platform gives us the capability to record and group discussions, communicate asynchronously, navigate through conversations, and be globally searchable and SEO-friendly?

Reddit or mailing lists come to mind. I’m not exactly a fan of Reddit’s or Hacker News’ threaded discussions as it is not chronological, although navigating to parent post and replies are a breeze. Mailing lists on the other hand, are a bit better, but too linear. There are also no way to “mention” a participant, and it has poor support for code blocks. Subscribing to too many mailing lists might also make your inbox unwieldy, even when it is labeled differently.

I am finding Discourse as the most ideal communication channel that I have experienced so far. There are many communities go down this path: Elixir, Docker, Kotlin, Go, and Rust to name a few, and they are arguably several of the best OSS communities out there. I know there’s one for React, but I’m not sure how active it is. I am delighted that the OCaml community has also started to migrate the discussions from the mailing list to the new forum (although it might take some time for it to get traction).

FWIW, I am also a fan of Twitter for being my one-stop news outlet and community channel for tech related things. I follow many devs and that fills my timeline with so many great discussions and blog posts, and fewer fake news.


So that’s about it! I realize that this is mostly a rant :) If I missed something, or if you think that I am not giving chat-based apps the credit it deserves for bringing together a community, do tell in the comments!

Top comments (12)

Collapse
 
ben profile image
Ben Halpern

I agree completely, Bobby. This general issue is one of the core problems we are trying to solve in the long run with dev.to. Not all at once, but in the long run. I really love Slack for some cases, but have totally given up on it for the big OSS projects, which also means I don't always keep up with what I should be. Email news lists have always been just as bad for me. Really hard to follow and high implied barrier to contribute.

Our comment threads right now are sort of hybrid between threaded and chronological. They are generally threaded, but the threads only go 4 deep and then they become chronological. I see it as a nice compromise, but it's also something we've left open to tweaking in the future.

I say this with a degree of humbleness. We're far from being the solution, but I've personally identified this as a big problem for some time.

Out of self-awareness, I have to mention this:

Standards

But I see it as a challenge. Gotta do something with my 9-5, might as well try to tackle a fundamental problem in our industry.

Collapse
 
askanison4 profile image
Aaron

This is a great outlook to have. I think I treat StackOverflow a little like a discussion board; though there are times I'd like to ask a question and be able to discuss back and forth, rather than be constrained by the binary question/answer format.

I know the conversations/extended discussion mechanism in SO handles this somewhat, but I always feel like that's hidden in out of the way.

Collapse
 
ben profile image
Ben Halpern

I've never personally been able to get over the hump in finding value in SO other than the Q/A as a resource. I see that as an indication that there's room for a different approach. The last thing we are trying to do is challenge that platform head-on for Q/A, but there is so much more developers need and trying to squeeze it into Stack Overflow's general mantra has seemed a bit square peg/round hole to me.

Collapse
 
bobbypriambodo profile image
Bobby Priambodo

I really love what you're doing with dev.to, Ben! Thank you and the whole team for taking the challenge.

I must confess that dev.to as a community platform slipped my mind when I was writing this article, but since I was talking about specific communities around a certain product, I hope you don't mind it that much :)

Collapse
 
ben profile image
Ben Halpern

I must confess that dev.to as a community platform slipped my mind when I was writing this article

We're new and I don't expect us to be mentioned alongside the established platforms that are way bigger than us. Most of our potential is yet to be realized, so I never feel snubbed when folks don't include us yet. We'll just keep plugging away at the problem.

Collapse
 
thehanna profile image
Brian Hanna

There are some excellent points here. The visibility and searchability, especially for an open source project, should be paramount. Discourse is a great solution, and seeing it in use by any project install boosts their credibility for me.

I still think chat can have a place in a project. Using it for things like build/deployment notifications and minor progress updates has been a boon for me at my current job. It can also be used for user/developer support. Sometimes, I don't want to post some big long thing on a more public forum. I want to talk to someone right away that help with an unusual use case. Stuff like that might get buried on a forum.

Collapse
 
ben profile image
Ben Halpern

Chat has a great place in projects. I think it needs to be a complementary environment, rather than the core one. Slack is weird in that you access this whole different environment just for the chat, so I think it leads you to wanting to do too much with it. Also, Slack as a company doesn't really seem to have an interest in serving this community. Gitter is better in this regard, but still not really a "full solution". Gitter was acquired by GitLab, so it will be interesting to see what they might do with it.

Collapse
 
thehanna profile image
Brian Hanna

Yeah, Slack seems like overkill for chat, period. We use Atlassian's products at my job, so we're all in on Jira/Bitbucket/HipChat, and the combination of the three is really excellent.

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

We are having that problem at my work right now as well. We use Slack, which is helpful to have runnign discussions, but stuff is just getting lost. We're trying to push more informatin into GitHub issues now.At least that has a record of it, and it's organized into issues.

Slack's threading feature suffers from a terrible UX. Nobody wants to use it for that reason.

I also use mailing lists and groups. I find them better for offline communications, but are also rather disorganized. At least they have threading though.

Collapse
 
codemouse92 profile image
Jason C. McDonald

Definitely some valid points. I mentioned in another article that IRC is a bit unique compared to other chat platforms in that lurking is expected. As such, there are a lot of systems in place to allow better async communication on IRC - MemoServ, chatbot !tell features, IRC relays. As for me, I'm on about 10-12 hours a day, but because I'm culturally not expected to answer anything right away, I feel safer ignoring it than even Twitter.

As to keeping track of conversations, that's why we have IRC logs. One grep and I can find anything I'm looking for.

But, I can also see how IRC can be limiting for async conversations. You don't usually expect to get an answer to a question two days after the fact, and it isn't uncommon for a question to get lost in the backlog in particularly busy rooms.

I still say it has a place, but it's no replacement for, say, Discourse.

Collapse
 
samipietikainen profile image
Sami Pietikäinen

I agree completely. More times than I can remember I have found an answer to some problem from old mailing list discussions (in which I have not participated but which are picked up by search engines). Especially when working with some technologies that are not so commonly used. Chances are that someone else has already encountered the same problem and received an answer for it. Though, it's not always easy to find these answers from e.g. mailing list archives, but with chat systems this information is not available at all.

Collapse
 
psnebc profile image
Patrick Schanen

I can completely agree with you. I use Gitter, Slack, Flock.