* Riot.im / Matrix.org (decentralised global network; e2e encryption; open protocol)
* Rocket.Chat (Meteor-based; focus on UX and feature)
* MatterMost.com (clone of Slack UI; open core license)
* Zulip.org (all about threads!)
* ...or indeed IRC or XMPP.
(disclaimer; I work on Matrix).
Here at FB, a lot of day to day coordination takes place via FB products. But production and release engineering communication happens over IRC, especially during major outages. The fallback factor in critical to keeping the plane in the air.
With Slack, the application itself is probably pretty tough, but for a lot of businesses their infrastructure and connectivity TO Slack (ie internet/WAN) is probably not very resilient. So for a lot of smaller outfits I'd say that Slack is better.
But if you're a large org and your infrastructure is very resilient and diverse, then you're probably better off self-hosting - assuming you can leverage your existing infrastructure to do so.
slack also has pretty dubious quality standards. e.g. their desktop app and their atrocious replacement for screenhero.
2. You can perform maintenance outside of office hours, with SaaS you don't get to decide when an upgrade (and potential outage) happens. I don't care about 99% uptime, I care about having 99% uptime while I'm working.
3. You can have backup services.
Generally, the experience with the mobile clients has been quite good. Conversations and Zom are stable, attractive, and featureful. The biggest issues are some interoperability problems with desktop clients (displaying messages that should be hidden) and some things which I believe are server-side configuration issues.
Zom hides a some useful configuration features (in the name of being dead-simple to use), so I'm trying to convince one of my iPhone-owning friends to try ChatSecure [4].
[1] https://f-droid.org/packages/eu.siacs.conversations/
[2] https://zom.im/
So I guess yes :)
How is that relevant to a chat app?
[citation needed]
Also read this post by Amir, the founder of TwistApp, "Why we're betting against real time messaging" - https://blog.doist.com/why-were-betting-against-real-time-te...
https://aws.amazon.com/solutions/case-studies/slack/
The API isn't even returning valid error codes.
logging error: {"subtype":"api_call_error","message":"{\"ok\":false,\"error\":\"_http_error\",\"status\":0,\"retry_after\":null}","stack":"Error\n
I am betting they are saying 'connectivity' because that is the error the client logs.
We've no solid plans right now as we're focused on tidying things up internally, but will consider it. Thanks again for holding tight
The slack.com IP's are owned by AWS, while status.slack.com resolves to some Digital Ocean IP's.
"Slack is down? Better post to Slack and let the team know."
When your business motto is 'always on' - it's really, really bad to be 'off' - it's a deep transgression of the brand promise.
BB was structured poorly for this - they didn't grasp the concept of multiple nodes of redundancy very well. (Easy in hindsight).
But - we should all be impressed at how highly available Google, FB and some other brands are. That's impressive.
The things we take for granted.
Also curious: why is this so low on the front page? 250 points, posted an hour ago...
I like how statuspage.io even has metastatuspage.com in case their primary domain/DNS/TLD has issues.
#jokingpeopleCOMEON
We are aware of connectivity issues and are actively lnvestigating.
3:58 PM PDT・See in your timezone
You can easily test this by disconnecting from wifi. As soon as you're offline the fan starts spinning until you get your connection back.
I'm probably not making this any better by commenting, of course.
Given timeframe and upvotes, how is this not the top of HN?
Slack has been experiencing service degradation often lately, so I would not be surprised if people start switching.
In our team we already started looking for an alternative.