Hacker News Reader

Comment by woodruffw | Hacker News Reader

Just another reason for OSS projects to never trust closed (centralized!) protocols: no recourse when it (inevitably) hits the fan.

View on HN

I feel like this is the same sort of argument that opponents of self-driving cars will use - "We shouldn't use self driving cars, because they have problems sometimes and a driver doesn't have recourse to correct it!"

While this might be true, we are still trading more problems for fewer problems. Yes, we can't fix slack when it breaks, but it still breaks a lot less than when we were running our own internal chat client.

Except, of course, that self-driving cars do have a recourse for the driver - manual overrides. I do see your point, however, and you're correct in that running an internal chat network probably isn't the best course of action for most groups/small business. Luckily, that's what IRC and XMPP networks are for.

Manual overrides cause more problems than they solve, and probably we should get rid of them in future self-driving cars:

http://www.npr.org/sections/money/2015/07/29/427467598/episo...

Except when you have to manage it yourself and something breaks or the infrastructure you have to manage needs managing.

See the comment above. If you're using Slack to avoid managing infrastructure, there are plenty of great (read: open source) alternatives.

Even if IRC isn't for you, there's XMPP, Mattermost [0], Let's Chat [1], and Zulip [2].

[0]: http://www.mattermost.org/

[1]: https://sdelements.github.io/lets-chat/

[2]: https://github.com/zulip/zulip

Mattermost team here, thanks for the mention!

Just to add, you can use IRC clients to connect to Mattermost https://twitter.com/mattermosthq/status/668898122630721538

Hey, I didn't know that - that's awesome! Keep up the good work - I'm glad to see an open source group tackling the problem of rich messaging.

Reply on news.ycombinator.com