401–410 of 730 posts
Earlier quoted context omitted.
I'm curious as to how that breaks down? Which kind of workflows are best in email, which in Slack?
Featured specifications work better in email, live debugging/forensics work better in Slack.
When is this overhype for Slack going to stop? It is a chat application with a slightly improved UI like it existed 30 years ago. This is a step in corporate IT that I really cannot fully understand. It seems that every company//startup has to use slack nowadays to pretend to be cool again. Everytime I have a serious conversation about the productivity gains or losses of Slack though, it is pretty clear to me that it…
Huge problem for on-prem Hipchat customers. Plenty of customers out there not willing to put all their internal communications on the other side of their firewall, and now have to migrate. Slack doesn't have an on-prem option. Microsoft Teams doesn't have an on-prem option. What are enterprises supposed to use, RocketChat? Matrix? With no clear migration path? Really poor move on Atlassian's part. It would be one thi…
The writing's been on the wall for HipChat for a long time; e.g. the user experience has been stagnant for many years (e.g. they never added emoji reactions). And even back in 2013, every HipChat customer I've encountered was unhappy or at best unenthusiastic about the product. So we've seen plenty of folks migrate from HipChat to Zulip.
I expect most enterprises will end up on one of the open source Slack alternatives (Zulip, Mattermost, Rocket.Chat, etc.). Frankly, they should have been using one of them anyway. If you care about a really high level of security, you want to be using well-maintained open source software. The well-maintained part is obvious, but the open source piece is really important too: It's a lot easier for white-hat hackers to find and report security bugs in software with access to the source code, and so there will be fewer that haven't been found and fixed yet.
You certainly don't want to be using a PHP app that's had over 700 confirmed security bugs found by external people (https://hackerone.com/slack) -- you can be pretty sure there are more being introduced every week.
I'll add that I expect to see more proprietary on-premise products that are the stepchild of a SaaS product disappearing over the coming years. It's a lot harder to ship software for the on-premise use case, especially if you have engineering culture used to just shipping for a single installation in the cloud (which almost everyone who works on proprietary software is). If you have the right processes and toolchain, it doesn't have to slow you down (and I don't feel it does for Zulip, with our amazing developer tooling and 98% backend test coverage), but very few organizations succeed at this. I've certainly heard some incredible horror stories from famous Silicon Valley companies about teams of engineers spending months on making a fork of a SaaS product shippable for each on-premise release.
Earlier quoted context omitted.
I don't see any compelling reason to adopt IRC. It does nothing that I care about that Slack doesn't do. If Slack completely implodes, I would search for Slack alternative. If IRC really was my only option, I'd use it just long enough to write a basic alternative myself that replaced or extended IRC w/ the features I really want.
For one thing, an IRC client doesn't pin a core of my cpu at 100% and consume half a gig of ram... (But I realise I'm well out on the losing end of this argument, even in groups of old-school hard core technical friends/colleagues, I've been given the "crazy look" when suggesting we just use irc for chat... )
Earlier quoted context omitted.
"discussions are faster and more productive in realtime" Real-time discussion is great if you don't have to think about what you're going to say before you say it. Unfortunately, that places a very, very low upper limit on the level of depth and consideration that a discussion can reach. Some decisions are hard enough and some situations are nuanced enough that you need to take your time with them, enough that the ad…
I agree with you and I feel your points are well articulated. I especially like how you summarized the internet as 'the illiterates took over.' Very poignant, indeed. So much of the average person's internet usage boils down to memes and videos, it's quite unfortunate.
There are so many examples of teams successfully communicating state, sentiment and other information among each other with memes and videos an what not.
Also, to help people blow off steam. We don't need to be absolute productive units operating at 100% all the time.
Goofin off is healthy
Huge problem for on-prem Hipchat customers. Plenty of customers out there not willing to put all their internal communications on the other side of their firewall, and now have to migrate. Slack doesn't have an on-prem option. Microsoft Teams doesn't have an on-prem option. What are enterprises supposed to use, RocketChat? Matrix? With no clear migration path? Really poor move on Atlassian's part. It would be one thi…
I'm guessing it's highly likely that one of the reasons for the acquisition is to make Hipchat the on-prem version of Slack, or at least create a path to that goal. Why does everyone here assume they will shutter the product? Slack has been promising self-hosted chat for years.
It'd be a lot less work to fork Slack and make it work on-premise than do something with HipChat. And that's saying a lot: forking Slack to make it run well on-premise would likely be an enormous project.
Earlier quoted context omitted.
BNCs provide a semblance of persistence. But the real problem with IRC is smartphone persistence, I think irccloud is the only service that solves this. But alas, it isn't free. So can this be solved for free? Is it even a good idea to solve it?
thelounge is an web based IRC client with persistence like irccloud, except that thelounge is open source and self-hosted. https://thelounge.chat/
Earlier quoted context omitted.
Email has a lot of problems, but the dealbreaker for my company is that it isn't secure.
And you somehow trust Slack as a "secure alternative"?
Earlier quoted context omitted.
I'm firmly in the "email has no place in internal discussions whatsoever" camp. Tasks belong in tickets, long-term documentation/policies/meeting notes/etc belong in shared space (wiki), and discussions are faster and more productive in realtime (in-person, video call, or chat). E-mail might kick some of this off, or be used to schedule, but that should be it. The problem I think most people run into with the realtim…
"discussions are faster and more productive in realtime" Real-time discussion is great if you don't have to think about what you're going to say before you say it. Unfortunately, that places a very, very low upper limit on the level of depth and consideration that a discussion can reach. Some decisions are hard enough and some situations are nuanced enough that you need to take your time with them, enough that the ad…
The reality is that email fails to serve the purpose for complex discussions that involve many people, especially when you're using a rubbish email system like outlook.
Another form, be it meetings, chat, forum, whatever is required for this... and to be fair, gmail and the like offer some form of searching and sorting nested threads...
...but your complaint is broadly the same as the argument against having meetings in general.
Certainly, it is an oppinion, but not helpful or realistic.
Slack is disruptive, but 'just use email' isn't the answer.