Why Slack is inappropriate for open source communications

We are, temporarily, in a kind of dark ages of end-user open source software. The reason is that we shifted from software-as-a-product to software-as-a-service.<p>With the old upload-and-forget model of software distribution, you could put a tarball on a free FTP site for a few pennies, and then a million people could use it, or one person could, and you wouldn&#x27;t have to lift a finger. A million people could fork your application, or one person could, and you wouldn&#x27;t have to do a thing. Variable costs for an OSS developer were $0. Fixed costs were just the cost of your computer and an internet connection.<p>But if you deploy an open source service to the cloud, it&#x27;s going to cost you more than a few pennies, and if a million people try to use your service you have two headaches: financial and operational.<p>In theory something like Ethereum solves this problem, but it&#x27;s not really ready for the scale yet, and it&#x27;s hard to use.<p>In theory something like a Heroku Button[1] on Github solves the problem, but Heroku artificially introduces a 30 second delay for accessing free applications, and put lots of their infrastructure behind a paywall that the deploy-er has to manage and pay for.<p>This has been a difficult problem to solve, because unlike the x86 machine of the OSS explosion in the 90s, the &quot;cloud computer&quot; is still actively being invented. Ethereum didn&#x27;t even exist a few years ago, and Heroku is a moving target. Linux Containers are also brand new, and then there&#x27;s Docker and other VM standards, not to mention Google, Azure, etc... we are still grasping in the dark to try to answer the question, &quot;What does a standard cloud machine look like?&quot;<p>Until we answer that question, closed source services are going to have an immense advantage over open source ones. After we answer the question the power dynamic there will reverse and there will be a cambrian explosion of user-facing open source services.<p>[1] <a href="https:&#x2F;&#x2F;blog.heroku.com&#x2F;heroku-button" rel="nofollow">https:&#x2F;&#x2F;blog.heroku.com&#x2F;heroku-button</a>

A great alternative to Slack, in the spirit of IRC, is matrix[1]. It has lots of clients, and a great vision.<p>You use an online client called riot[2] which uses the matrix protocol. There are other clients available[3] including desktop clients.<p>There&#x27;s E2E encryption coming to more of the clients which is inspired from signal protocol (double ratchet part of it specifically), without Forward secrecy so as to maintain session history on new devices.<p>I think it has a bright future and you should consider it too.<p>[1]:<a href="https:&#x2F;&#x2F;matrix.org" rel="nofollow">https:&#x2F;&#x2F;matrix.org</a><p>[2]:<a href="https:&#x2F;&#x2F;riot.im" rel="nofollow">https:&#x2F;&#x2F;riot.im</a><p>[3]:<a href="https:&#x2F;&#x2F;matrix.org&#x2F;docs&#x2F;projects&#x2F;try-matrix-now.html" rel="nofollow">https:&#x2F;&#x2F;matrix.org&#x2F;docs&#x2F;projects&#x2F;try-matrix-now.html</a>

What drives me nuts is that there are so many of these things.<p>I know groups that (for business or pleasure) use Slack, Discord, Skype, Google Hangouts, IRC, etc.<p>All of these clients are a bit more obstrusive than they need to be in terms of pop-up notifications, software updates, cpu, memory, transfer, etc. They all screw up enough that there&#x27;s always a little apprehension that something will go wrong when you get a number of people together for a meeting.<p>It is one thing to deal with one of these things, but when you have to install ten to get your work done you have a problem. I have a high performance computer and I want to keep it that way.

Is that really happening that open source communities use Slack as their primary communications channel? I haven&#x27;t seen that happening in the communities I participate in (Python&#x2F;Django&#x2F;...). What I do see is that more and more communities switch from IRC to Slack as the primary &quot;sync&quot; channel (while still maintaining mailing lists, bug trackers and the like).<p>And as much as I hate it, the success can&#x27;t be denied. Especially when looking at some conferences I&#x27;ve been to over the years. If they even had an IRC channel, it was mostly dead, but the Slack channels were buzzing with activity during the conference. I&#x27;m not sure why that is. Ease-of-use? The fact that many attendees are familiar with Slack from work, but not with IRC?

Issue #2, that slack is based on synchronous communication, is something that is always ignored. Sometimes I log in to slack and see a conversation that I want to add something to, but it is 4 hours old with 50+ new messages on varying topics. Even with Slack&#x27;s new threaded messages it is hard to evolve the conversation after all the synchronous folks have moved on to other topics.

Good points but the bigger problem for me is the lack of an archive.<p>You only have the last 10k (?) messages and that includes public and private messages. If you have a mildly active project, messages may only be available for a month and you lose the history of the project. That makes it an awful support option too.

Forums. I don&#x27;t know why the internet got tired of them, even when they sometimes fit the bill so well. Slack is chat. Mailing lists are far too outdated. Forums are good, and some good people out there are still developing them.

I was expecting Stallman-style advocacy against closed-source as a principle; pleasantly surprised by the arguments.<p>Synchronous communication, indeed, is bad for the main communication channel. However, as a secondary communication channel, it can serve important needs.<p>When people are looking not to just get a single issue resolved, but to form a community, this community is often based on informal communication and emotions. Seeing the same people in the member list every day, exchanging little inside jokes, getting to know individual members of the community on a personal basis — this is something completely irrelevant for the user of the open-source product, but can be an important emotional component that motivates people to stay in the community and continue to put in effort into the project.<p>And, of course, a synchronous channel, where you can get more lax on moderation, is a much more suitable tool for this purpose.

I am the lead developer of Zulip (zulip.org), an open source Slack alternative built around a better threading model.<p>I strongly agree with both criticisms of using Slack for open source, and I am impressed that Dave wrote this post, given that some of those criticisms apply to his own product.<p>However, I think the proposed solution of relying on mailing lists, issue trackers, and forums is the wrong solution.<p>Support for synchronous communication is not the problem with using Slack&#x2F;IRC&#x2F;etc. for having discussions in open source organizations. After all, even with &quot;asynchronous&quot; media like email, bug trackers, or forums, often people reply basically immediately (within minutes or maybe hours), just like you can in chat, and it might be hours or days before everyone has a chance to see the conversation and respond.<p>The problem is that the messages have no organizational structure beyond the channel. In Slack and friends, there&#x27;s no easy way to see what _actual conversations_ happened while you were away, and it&#x27;s really hard for a channel to discuss multiple things, so conversations either die or become hard to read when someone starts talking about something else. Combined, this means you have to (1) read _everything_ in order to know what happened and (2) be continuously online in order to participate effectively. This may not matter if your community is super low-traffic, but if you have hundreds or thousands of messages being sent daily, this effectively excludes everyone who doesn&#x27;t have a LOT of time to spend on the chat community.<p>It doesn&#x27;t have to be this way. Nothing prevents creating group chat software that handles both synchronous and asynchronous communication well. In particular, Zulip is built around a simple threading model that solves both of these problems. In our own chat.zulip.org community, people constantly contribute valuable commentary or feedback to a thread that started a few days and hundreds of messages ago. And I can come back from a week&#x27;s vacation, and skim the 5000 messages that might have happened while I was gone, and easily reply to all the threads where I have something to add.<p>(As a sidenote, it&#x27;s easy to post permanent links to conversations in Zulip, which we use regularly in the Zulip issue tracker to point to the original discussion that led to a given proposal. But the important problem isn’t the link part, it’s separating the conversations from each other: without something like Zulip&#x27;s threading, reading chat logs can be a slog).

It might be more useful to speak in general terms than call out Slack in particular. The concerns expressed here aren&#x27;t limited to Slack (despite the link-baity title), but any form of communication that:<p>(a) Can&#x27;t be referenced or linked from the Web, and<p>(b) Is a form of synchronous communication<p>The same factors, BTW, apply equally to in-person discussions held at open source conferences. I wonder what the author thinks of the value of those insofar as &quot;open source communications&quot; are concerned.

Slack is technically inept as well. Earlier today I was modifying a robot design in Fusion 360. Huge beast of a model with too many parts to bother counting. Fusion was consuming nearly 900MB of memory (and I am rounding up here). Which is unsurprising for a CAD package editing a large model.<p>Meanwhile my mostly idle Slack with perhaps a couple hundred users across four teams was consuming 1.3GB of memory.<p>Not to put too fine a point on it: it is a piece of shit software.

It seems to me that Slack could position itself to provide free and open access to certain types of communities like open source projects, charities, etc. Enable the &quot;pro&quot; features so long as the community follows the rules.<p>The value of synchronous communication is very real and it should not be precluded, but the points are totally valid. Slack is a closed-garden and it does not contribute to the global conversation if the access and historical record is controlled from within.

I feel like more and more people are coming around to seeing the relevancy of distributed federated chat and breaking out of the walled gardens. My person money is on Matrix[0] taking off but I think the general theme of people pulling away from interesting their communication to corporations is a positive. [0] matrix.org

Tangentially, I don&#x27;t get how developers on the one hand strive for private offices and no (physical) interruptions, but on the other want to communicate through chat channels. Maybe these are different people altogether, and I&#x27;m just getting the wrong impression. But personally I prefer a little personal interaction over a long chat.

Mattermost is an excellent open-source Slack clone. It would be interesting if someone could add a feature to publicly host chat logs for indexing by public search engines.

Many of these complaints are just as valid for any business or organization trying to function as a modern software-based org in this day and age.<p>You have remote workers, flexible schedules, people traveling everywhere, all doing knowledge work that depends upon sustained focus and reaching a flow state. All of which Slack and synchronous chat detract from.<p>Slack just happens to be easy and convenient, so orgs end up using it by default.<p>Obligatory link to 37 signals post on this topic: <a href="https:&#x2F;&#x2F;m.signalvnoise.com&#x2F;is-group-chat-making-you-sweat-744659addf7d" rel="nofollow">https:&#x2F;&#x2F;m.signalvnoise.com&#x2F;is-group-chat-making-you-sweat-74...</a>

I&#x27;m not sure about others, but I very much dislike the idea of multiple channels (the way Slack, Discord, etc. do it) on one server&#x2F;chat. It feels messy and half the time conversation doesn&#x27;t fit neatly into any of the choices. Honestly, I can&#x27;t think of something I&#x27;d rather use over Telegram here -- if I need multiple discussions it&#x27;s just like IRC: I make a different chat for each one, rather than having to awkwardly subdivide my main chat. It also has the advantage (even more so than IRC) that all users exist on the same server, so you never have to deal with the awkward per-group account system (Slack) or server-only messaging (Discord) or having to switch rizon-&gt;freenode-&gt;mozilla IRC. WhatsApp would probably be just as good if not for publicly identifying users by phone number, what it really comes down to for me is just having a normal chat app. Maybe even plain old Skype would be nice if it wasn&#x27;t proprietary. I don&#x27;t need you to innovate the way my chat system works with fancy new methods of grouping users. I don&#x27;t mind the bells and whistles (voice&#x2F;video chat, bots, stickers&#x2F;emoji, ...) as long as it doesn&#x27;t get in the way of me having a conversation. But for fuck&#x27;s sake don&#x27;t try to cut off every group from everyone else like Discord&#x2F;Slack.

Mattermost is an open source alternative to Slack btw.<p>And Discourse is pretty great, though much more like a forum.

Forums work better.<p>Using IRC&#x2F;Slack in place of forums is like using a wiki in place of real documentation.

It&#x27;s frustrating that the choice seems to be between modern closed tools like Slack and Hangouts and antiquated open tools like IRC and mailing lists.

I personally prefer Gitter &amp; other tools over Slack for open source communications. The Slack signup process can be a road block as it takes to many steps. To often I run into open source communities that require you to join their Slack channel for posting any questions (that may or may not be bugs in their software).<p>I really like Slack for a lot of things, but it&#x27;s often a tool used incorrectly due to its popularity.

&gt; Slack, et al, are based on synchronous communication, which discriminate against those who do not or can not take part of the conversation in real time. For example, real time chat discriminates against those who aren’t in the same time zone–you can’t participate fully in an open source project if all the discussion happens while you’re asleep. Even if you are in the same time zone, real time chat assumes a privilege that you have the spare time–or an employer who doesn’t mind you being constantly distracted–to be virtually present in a chat room. Online chat clients are resource hogs, and presume the availability of a fast computer and ample, always on, internet connection, again raising the bar for participation.<p>It&#x27;s quite amusing that the author takes his (valid) argument about the problems of closed, synchronous communication straight to the language of privilege, discrimination, and oppression.

I can&#x27;t believe that in 2017 we&#x27;re still discussing what&#x27;s wrong with our chat software. I have to wonder when we will finally see chat as a solved problem.

Discourse offers free hosting for big Open Source projects, and you can self-host it on a $5 VPS too.<p>Full Disclosure: I work at Discourse.

As I posted on twitter[1], Slack is linkable. Not public, but if you can chat you see them. Gitter: public AND linkable. Async is a good argument; linkability is not.<p>Slack&#x27;s UI is good. Not perfect, but it&#x27;s quite usable compared to <i>all</i> the alternatives[2]. People always underestimate the value of good UI.<p>[1] <a href="https:&#x2F;&#x2F;twitter.com&#x2F;zellyn&#x2F;status&#x2F;851818007248678912" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;zellyn&#x2F;status&#x2F;851818007248678912</a> [2] I&#x27;ve been on IRC on and off since 1993. It&#x27;s <i>much</i> worse.

Here&#x27;s combined forum + chat + question &amp; answers software that you might want to use instead of Slack:<p><a href="https:&#x2F;&#x2F;www.effectivediscussions.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.effectivediscussions.org&#x2F;</a> (ED)<p>It&#x27;s open source. It seems to solve the problems mentioned in the article (I mean, openly accessible — can link to a discussion &amp; (soon) to a post in a chat channel. Both sync &amp; async communication (both chat and traditional forum topics).<p>I&#x27;m actually just about to a-little-bit start promoting it. ... Ok so let me try to make you more interested in ED:<p>- Often, organizations setup a chat (e.g. Slack), a forum (e.g. Discourse) + use e.g. StackOverflow — but then they&#x27;ve split their community into three. However with EffectiveDiscussions (ED) you can gather everyone at one place.<p>- ED is looking to improve the quality of the discussions. For example, there&#x27;s a novel voting system that solves (I hope) problems related to people downvoting-because-they-disagree, + a novel algorithm for finding the &quot;best&quot; comments (in threaded HN style topics). Plus some other improvements over HN &amp; Reddit, see <a href="https:&#x2F;&#x2F;www.effectivediscussions.org&#x2F;-32&#x2F;how-hacker-news-can-be-improved-3-things" rel="nofollow">https:&#x2F;&#x2F;www.effectivediscussions.org&#x2F;-32&#x2F;how-hacker-news-can...</a><p>(As you might have guessed, I&#x27;m the one developing ED.)

A different take on solving the problem of asynchronous communication: JayPad is a simple web app which works like a tiny mix of Slack&#x2F;Group Chat and Post-Its. Offering synchronous discussion via chat and the possibility to store results of these discussions into a container of Notes for asynchronous consumption.<p>In its early stages, but working beautifully.<p>[1] <a href="https:&#x2F;&#x2F;jaypad.de" rel="nofollow">https:&#x2F;&#x2F;jaypad.de</a><p>[2] <a href="https:&#x2F;&#x2F;hackernoon.com&#x2F;how-jaypads-help-us-build-jaypads-c66c07c6c3ae" rel="nofollow">https:&#x2F;&#x2F;hackernoon.com&#x2F;how-jaypads-help-us-build-jaypads-c66...</a><p>[3] <a href="https:&#x2F;&#x2F;hackernoon.com&#x2F;how-planning-a-weekend-trip-with-our-buddies-changed-our-perception-of-slack-and-whatsapp-1d53058f51d0" rel="nofollow">https:&#x2F;&#x2F;hackernoon.com&#x2F;how-planning-a-weekend-trip-with-our-...</a><p>[4] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=0g2Hecd-Ujo&amp;" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=0g2Hecd-Ujo&amp;</a>

The argument about why slack doesn&#x27;t work well is a bit of a stretch. I understand all the points on closed system etc. But the author states that slack doesn&#x27;t work because it&#x27;s synchronous and it excludes others from participating in the conversation. Then mentions that even with history recorded, the person in a different time zone can&#x27;t participate. Then the argument is to use email threads instead. email suffers the same problem of slack, where those who didn&#x27;t check their email while a discussion was happening now feel missed out on. However, they can reply 8-20 hours later or even days later. Well, you could do the same thing with slack. The problem with slack is the lack of relevant threads. Everything is one giant thread. But that is how most email mailing groups become anyways.<p>Now, I am not a proponent of slack, I think it has its own problems, but I don&#x27;t think email is any better.

I think there are good points there about offline participation and archival. I would expect that 99.9% of those on HN have at one time or another found an answer via a direct forum&#x2F;message list archive or off a google search result returning the same. That will not happen as discussions move to Slack like systems and even if it were, threading would not likely exist.<p>Addressing another point, and though I do use a Slack imitator for a small non-work&#x2F;non-programming group - an advantage of IRC is that it can be part of many chat clients which handle multiple protocols. Thus I have IRC open with multiple Jabber chats and mucs. Slack et al, at least on the desktop, are space hogs (from those I have seen) and when I am working, space is a premium commodity even with two large displays. The last I checked, IRC integration into Slack is cumbersome and lacking, is this still so?

Sounds like a great new splash screen for them.<p>&quot;Slack is inappropriate for open source communications&quot; - Your friends at Slack.

My HN feed right now:<p>4. TypeScript at Slack (slack.engineering) 183 points .. 5 hours ago | flag | hide | 86 comments<p>5. Why Slack is inappropriate for open source communications (cheney.net) 615 points .. 12 hours ago | flag | hide | 395 comments<p>Quite random, but I couldn&#x27;t help but notice.

Can we just go back to aim? I really hate having one damn view for channels, so if I&#x27;m talking to two people I have to constantly switch back and forth. I still don&#x27;t get how these kinds of tools get such a big following.

I think many opensource communities do not want to dogfood on other opensource projects anymore. They want the best product out there for other things and more often than not these products are closed source SaaS products.

Just yesterday I was looking for a way to present all the messages in a given Slack channel as an RSS feed, and I was surprised to come up empty. (I found lots of ways to go the other way though, from RSS into Slack.) The best I found was this, but it looks like you need a Heroku Dyno and must be the account owner---oh and it only exports links, not full messages:<p><a href="https:&#x2F;&#x2F;gozman.github.io&#x2F;slack-rss&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gozman.github.io&#x2F;slack-rss&#x2F;</a><p>So that is one drawback to a closed system.

Mailing lists really are preferable for a number of reasons but unfortunately Google Groups or worse, mailman is the interface, and they&#x27;re both pretty bad.

I have had good experience communication with the Aurelia.js community using Gitter. I strongly recommend it.

Does Slack&#x27;s terms of use forbidden creating an off platform archive?<p>If not, given that searchable archives are one of the ways Slack makes money, makes me wonder why there&#x27;s not an open source way to pull the chats and archive them in a way that&#x27;s cheaper and independent of Slack.

what do people think about zulip.org?

I know most people hate meetings, but chats are worse. Maybe you want a Bulletin board system ?

I was [breifly] part of a project that used slack as the primary communication medium. I can second all the points in the article. IRC is a terrible format for open source collaboration. Flame wars can get out of control really quickly via text.

Feel like this argument happened 5 months ago and 5 months before that too

I don&#x27;t quite understand what everyone has against email. Just get a good client and server with imap IDLE support and you should be good to go.

I must&#x27;ve missed the memo which says any conversation around the globe is waiting for my input before it proceeds.

I like IRCCloud, it lets me use an open platform, but pay for archival of the channels I care about.

Honestly wondering what benefit for business chat that Slack has over IRC for software devs?

Free and unlimited &#x27;Slack&#x27; is Bitrix24. Smart people switched years ago.

Switched from Slack to Telegram. The desktop client is so much faster.

Just discovered Gitter this week. That may be a suitable alternative.

IRC (and Slack) are <i>not</i> real-time. Why do people think this?

I don&#x27;t know why didn&#x27;t just evolve irc. Feature wise slack doesn&#x27;t really bring much new. It just has a good interface. If someone made an irc client as easy to use as slack then we&#x27;d have our answer.

I massively disagree with #2. Unless your project has very little activity, synchronous or pseudosynchronous communication is a lot more efficient than async through email&#x2F;discourse. It&#x27;s also a lot more friendly to your contributors, it makes things less formal and more human.<p>Async shines when you have a lot of users, but only if it&#x27;s very accessible (searchable). Otherwise it&#x27;s just people repeating themselves constantly.<p>Also, longer rant on the IRC thing. For the past decade I&#x27;ve been using IRC as my central mode of group communication for all open source work. Last year and as part of my (open source) company, I&#x27;ve completed the switch to Discord.<p>I&#x27;m an open source die-hard and it bugs me that Discord isn&#x27;t open source yet, but I believe this has a fairly high chance of changing (MUCH higher than Slack has at any rate). I would heartily recommend Discord for open-minded open source communities.<p>I&#x27;m now using Discord for everything. It has given me a unified interface for all my personal <i>and</i> group communications, easily searchable, with voice chat too (and video chat very soon, I cannot wait to never open Hangouts again). Needless to say, I&#x27;m a huge, huge fan.<p>Slack has none of that. The #1 thing that bugs me with Slack is the forced separate accounts for every single Slack instance. And you can&#x27;t delete any of those accounts, you can only &quot;deactivate&quot; them.<p>Our open source community uses it. It works really well for us because we&#x27;re a gamer-oriented open source community, so Discord is already pretty well known in that circle. On an ideological level, its API gives enough control over everything that goes in in it that I&#x27;m satisfied I could move to another service, should I need to. If anything, it&#x27;s <i>harder</i> to move off IRC because there&#x27;s no public logs, easy point of contact for the regular users, etc.<p>Also, I&#x27;m using Matterbridge to mirror our public channel to IRC: <a href="https:&#x2F;&#x2F;github.com&#x2F;42wim&#x2F;matterbridge&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;42wim&#x2F;matterbridge&#x2F;</a> (highly recommend everybody here checks it out; it supports a lot of protocols)<p>IRC has really disappointed me the past few years. I had a lot of hope that irccloud.com would offer a solution to IRC becoming irrelevant in the face of Slack and Discord, but it just hasn&#x27;t happened. They&#x27;re understaffed and don&#x27;t have enough money coming in.<p>There&#x27;s also a lot of ideological purity in recommending against SaaS &quot;centralization&quot; for comms but the truth is, it&#x27;s not better. Last year my HDD crashed and I lost the logs for my organization&#x27;s original channel going back to its creation... I&#x27;m very, very sad about that. Had I been using IRCCloud (or Discord) at the time, I wouldn&#x27;t have lost all that. Granted, those companies could have, but the chances are lower than me fucking up.<p>This is the same reasoning why email is usually better off handled by companies whose livelihood depends on offering you the service, than by yourself.<p>Also like I said elsewhere in this thread, for a project using a Freenode channel and another using a Discord&#x2F;Slack server, there is no difference between Freenode disappearing and Discord&#x2F;Slack disappearing. Your host disappears, you have to find a new one, update tons of references and contact lots of users to let them know. On IRC, that&#x27;s even harder. You <i>can</i> run your own IRC server, but very few do that, and those that do get less mindshare because connecting to yet another server is very annoying on IRC. It also costs you more, both in money and maintenance.

Some people only go to church on holidays...

I&#x27;ve been making this exact case since it came to popularity.<p>There&#x27;s tons of FOSS alternatives! No excuses!

The article, at the end (spoilers) states that async communication should be preferred for open source work. And I agree that async is important. But there are times where you do need that synchronous, let&#x27;s talk now communication. And for that, Slack is great.

&gt; <i>This means that the content inside those systems is closed. I cannot link to a discussion in a Slack channel in a tweet.</i><p>Such a shame that you can&#x27;t make a link in one closed system to another closed system.<p>&gt; <i>The tools that fit this requirement best are; mailing list, issue trackers, and forums.</i><p>Mailing lists <i>suck</i>. They&#x27;re hard to read, hard to follow, and create an endless supply of unresolved issues that everyone forgets about. Big projects using mailing lists seem to do so out of inertia rather than choice.

Please, stop advertising slack. Any time when i read hackernews, i see 2-3 &#x27;news&#x27; about this chat program. It was big mistake to use slack in our company.

For open source projects: offer Github issues, IRC for chat and a proper forum like phpbb or a more modern forum like discourse (or one of the clones) and&#x2F;or a mailing list.

It seems kind of funny that an open source project can&#x27;t find an open source form of communication.

Was hoping for something original but nope:<p>&gt; these services are not open