Hacker News Reader

Comment by hobarrera | Hacker News Reader

There's also letschat: http://sdelements.github.io/lets-chat/

Dunno why people tend to flock over to the propietary option though. :(

> people tend to flock over to the propietary option

Because it Just Works(tm) and there's no fiddling or faffing about necessary. I'm all for [FL]OSS applications, but sometimes proprietary solutions, even if they do the same task, are just easier to use and integrate (both technically and bureaucratically)

In the case of something like Slack though, there's a huge business risk: Storing your confidential internal discussions with a random startup of questionable security practice.

True, but it also gives you an out if customer data is breached. You, with good faith, contracted a thirdparty to manage and secure your data. If you run your own Letschat and some exploit is found that dumps your chat db, you're/your company is on the hook.

FWIW, I don't and likely will never use or promote Slack for intracompany chat.

The opposite. If you install opensource software on you own servers, and make it available only for your company's intranet, you are perfectly safe from outside attackers. Proprietary software can also exploited or they can just sell your data for bucks, when they are about to bankrupt.

Unless someone compromises your intranet as a whole.

> Because it Just Works(tm) and there's no fiddling or faffing about necessary.

That's what marketing would have you believe. For example Hangouts broke the ecosystem horrible, and now xmpp and hangout users can no longer intercommunicate (and wonder why their messages are silently dropped).

Users complain that they need 6+ apps to keep in touch with friends.

The real answer, IMHO is "Because they market it as 'just works'.".

Then you put on a great deal of risk in terms of owning your data, having unwanted changes in the product, or Google acquiring (and closing down) your service provider.

Well for one thing, there's the hassle of maintaining it.

Don't get me wrong, I maintain lots of things. It's my full-time job. I count it as a victory every time I can gain some capability without adding some additional thing to maintain. Double victory even better every time I can take something I thought I needed to maintain and throw it on the scrap heap, eg because its functionality was subsumed by something else I need more.

Then there is security. If I take this open-source app and deploy it on my servers, and there is a vulnerability that results in privilege escalation, I have just opened up my network. Skilled admins will balk, but if I chat over Slack and there is a security vulnerability in Slack, even something related to my own (or my users' own) incompetence, I've just exposed... worst case is Slack, and Slack's network, and whatever my users already saw fit to expose to Slack.

It should already be eminently clear to my users that data in Slack's hands has left the garden of our own control, and is not to be trusted.

I am a proponent of other and opener Slack alternatives (to put it mildly), but I prefer things that come in a bigger stack, so when I waste my time setting them up, I get something back better than... my own watered-down version of Slack that I need to add to the maintenance charts.

(Insert small, shameless plug for Urbit, which has a centralized talk server and stores backlogs)

> Well for one thing, there's the hassle of maintaining it.

You're confusing FLOSS with self-hosted. You can use free software, but hire it as a service. Example: https://githost.io/

about the security issue, you're wrong: if you want to host it for your company, put it behind a VPN or defend the site with a password on the HTTP level. This prevents all attacks from outside.

That also hinders remote access and promotes a sense of false security with users who don't know better. Better to tell them to use a secure channel for sensitive things. Then again if you thought slack was really secure I could set how you might think that.

There are both arguments. We have a VPN but don't let just any user on it. Then again I'm not sure if I want those people on slack with me either. The times when we want to use slack can tend to not overlap with the times we want to worry about whether the VPN works or if I can connect to it. We even use slack to organize a distributed disaster recovery and coordinate it!

Reply on news.ycombinator.com