[Arathorn]

This is probably preaching to the choir, but hosting your own FOSS chat is nowadays a very viable way to avoid being dependent on a centralised service like Slack. Your options include:

* 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).

[acchow]

Is there reason to believe self hosting will have better uptime?

[lstyls]

Uptime aside, you also have to consider the effect of a single point of failure when you self-host. If your in-house communication hub goes down when your site does, it's going to make firefighting that much worse and you'll pay for it in a longer outage.

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.

[synicalx]

People like to jump on bandwagon or the other, but the real answer is - it depends.

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.

[saas_co_de]

yes. small scale is almost always simpler and less error prone than massive scale.

slack also has pretty dubious quality standards. e.g. their desktop app and their atrocious replacement for screenhero.

[nojvek]

The biggest benefit of slack for me is their search. All messages are indexed ready to be searched. Code snippets, images, giphy, attachments, bots. It’s a whole ecosystem, not easily replicable with irc.

[flukus]

1. Self hosting doesn't have to operate at the scale of slack, so there's a whole slew of issues avoided. Pushing text messages around really isn't that difficult when you aren't serving millions of customers.

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.

[TylerE]

There's also a wholew slew of issues driven right into.

[flukus]

Such as? If you've got less than 1000 users then you need an extremely basic server, a raspberry pi should more than suffice. Then you've just got a little bit of manual (or automated) administration, software updates and backups mostly.

I really didn't expect my post to be so controversial, is the HN crowd really so terrified about running there own hardware?

[seanp2k2]

I'm guessing that you're being downvoted because there's a lot more to consider. I agree that it doesn't take much hardware these days (most single-board computers would work perfectly well) to service <1k simultaneous chat users with efficient server-side software (e.g. UnrealIRCd or ejabberd). However, to make it as reliable as Slack (99.99% monthly uptime is their SLA) for the price they offer it ( https://www.slack.com/plans ) would likely take considerable engineering effort. Sure, you could set it up, toss it in a closet, and it might have 100% uptime for a year...until it doesn't. If chat is business-critical, there are chat companies that have profit motive to deliver a good service. If chat is a nice-to-have at a company (and you e.g. don't have to worry about data retention laws / compliance stuff), maybe it's fine to run it on an rPi / t2.micro (free) AWS instance.

Luckily, there are a ton of great free and paid options out there these days!

[hedora]

For $6670 a month (price for 1000 users), I’m pretty sure most people here can spin up two VMs in two different colos, and setup IRC servers or whatever.

99.99% uptime means it can be down for a few minutes a month, so all it needs to do is fail over properly. In practice, it will probably have many more than 4 9’s.

I think the real reason slack does well is ease of client + service setup, the brain-dead UI, lots of feature creep that a few people care about, mobile clients, etc, etc.

I’m not a huge fan, but it could be worse. At least they didn’t leak everyone’s password like hipchat did.

[scaryclam]

Generally yes, given the reasons others have said. Other than that, at the very least, outages can be dealt with more proactively when you have your own setup. Third parties won't have the same priorities that your company does.

[seanp2k2]

Since Slack's main business is chat, they have a pretty good incentive to get everything working again ASAP. Here's their SLA for "plus plan" and Enterprise plan:

  Our Plus plan Service Level Agreement (SLA) guarantees a 99.99% monthly uptime1
  We’ve designed our SLA to be simple and transparent — based directly on the information we make publicly available on 
  Slack’s System Status page.
  If we fall short of our 99.99% uptime guarantee, we’ll refund customers on the Plus plan 100 times the amount your 
  workspace paid during the period Slack was down.

Source: https://get.slack.help/hc/en-us/articles/204113126-Plus-plan... + https://get.slack.help/hc/en-us/articles/115003205446-Plans-...

Chat is a commodity these days. For most businesses, it probably makes more sense to just let the companies in the business of offering paid chat services do their thing.

[user15672]

Don't see why you were voted down on this, since it's true. Slack working to get things running again doesn't mean they're prioritising your companies particular instance or region. They're likely to be making sure their own region and their own stuff is up and fixed first, so anyone away from the east coast of America is likely to get seen to after that. It would be stupid to do it any other way, since slack employees are likely affected as well and they're the ones trying to fix it. Down voting someone pointing that out is pretty fanboi-esk or really naieve.

Pretty much, if you don't own the service, you don't get to decide where in the queue you are for a fix.

[anonu]

Do these solutions have good mobile frontends?

[avhon1]

I run an XMPP server for my friends. We use Conversations [0,1] on Android and BBOS, and Zom [2] on iOS. We use OMEMO [3] for encrypting most of our conversations, and while it isn't perfect, it usually stays out of the way.

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].

[0] https://conversations.im/

[1] https://f-droid.org/packages/eu.siacs.conversations/

[2] https://zom.im/

[3] https://conversations.im/omemo/

[4] https://chatsecure.org/

[rrix2]

Matrix via Riot has quite a great mobile client

[JeanMarcS]

I run my own Mattermost server and the mobile version is very lookalike the Slack one (I only use chat so I don't know if there's other functionalities on Slack that are not in Mattermost)

So I guess yes :)

[artur_makly]

love MatterMost as it is ITAR compliant

[Veratyr]

"International Traffic in Arms Regulations"?

How is that relevant to a chat app?

[arturmakly]

if u work on military or DOD projects,u cant use most cloud platforms like slack. MM solves that compliance requirement