4 ms·

Ask HN: How do you feel about Slack?

5 points by anotherhue 5y ago

Slack (and its contemporaries) have dominated the last 5+ years of my professional life. I also see it becoming pervasive in open-source projects. I am not a fan, I think it has reshaped our communication to our detriment -- repackaging our availability as a feature. What has been your experience? I'm particularly intereted in hearing from people who value it.

atlasunshrugged 5y ago
I also don't love it. I'm now active in 5 slack groups between various projects and it's fine, but definitely sets weird expectations about availability and that noise from notifs kills me when I'm trying to do deep work (or just on a call with someone)
Juliate 5y ago
I use it (and loathe it) at work. As for open source projects I might rely on, having a slack but no active mailing-list/forum/async-channel is a sure red flag.
theamk 5y ago
Every commercial place I worked in used some sort of messenger, which was pretty useful because it is much less distracting than walking to someone's desk, and also allowed one to easily share code snippets, error messages, and so on. Before Slack I've used XMPP, and Slack is much better because it supports mobile, does not lose messages when you go offline, and has archives with functioning search (yes, it is not great, but at least it exists...) Cannot say anything about open source, but for commercial it is sure better than alternatives.
- MattJ100 5y ago
  For the record XMPP supports mobile, does not lose messages when you go offline, and has archives. I'm yet to see an open-source implementation of server-side search, but most clients can search local history. It's probable that either your experience with XMPP was some years ago, or if more recently that your deployment was simply not up to date with more recent features.
  - theamk 5y ago
    Yes, this was a while ago, but while protocol may support all sorts of fancy stuff, many client's don't. For example, I used to use "pidgin" to connect to XMPP server. Our product runs on Ubuntu 18.04, which means most developer PCs run the same, which means I'd get pidgin 2.12 by default. Does it has all those features? I bet no. (In fact, just because I was curious, I tried to determine if the latest version of pidgin supports "do not lose messages when offline" feature... It looks community decided XEP-0313 is the way to go here, but according to https://issues.imfreedom.org/issue/PIDGIN-15653 https://issues.imfreedom.org/issue/PIDGIN-15653 pidgin does not support it) So please don't say things like "XMPP does not lose messages when you go offline" -- because plenty of things which call themself "XMPP" do. Instead, the correct phrase is: "By carefully selecting XMPP clients and servers, you can end up with configuration which does not lose offline messages"
    - MattJ100 5y ago
      Oh, sure. Pidgin has (unintentionally) done a lot of harm to XMPP in the past decade. It was a wildly popular client "back in the day", and even today it's still often the only open-source IM app that comes to peoples' minds. However the project in general has had a general lack of resources for many years. Needless to say it did not keep up with the changing times. There's some renewed momentum in Pidgin recently, and I have hope that the situation will improve. But it is very far from a suitable recommendation for modern featureful messaging at this point.
      - theamk 5y ago
        I don't think it's just pidgin. Let's pretend I want to get started on XMPP -- I just did "apt search xmpp".. my first results were coyim -- cannot find xep-0313 support, but [0] seems to indicate no? dino-im -- HEAD supports xep-0313 but Ubuntu's repo has "0.0.git20180130"... from [1] I think it should be fine too? ekg2-jabbel "0.4~pre+20120506.1" -- looks dead, but based on date, I guess no support empathy (part of GNOME): seems like no support? [2] So... 1/4 for initial sample. And I've had to resort to looking at source code in some cases to determine if this exists or not. Let's not blame pidgin -- most existing XMPP clients do not have offline message support. And if you want to set up a functional XMPP chat system, you have to start by reading forums and then do a bunch of manual compatibility tests on each platform you care about, as there is no guide anywhere on https://xmpp.org https://xmpp.org or any other official-looking places I could find. So it's no wonder that people choose Slack. Sure, it is primarily a web app, and the client is atrocious, but at least I am 100% sure that when my bot posts an report with an image and some buttons, everyone will be able to see and interact with that. [0] https://github.com/coyim/coyim/search?q=0313&type=commits https://github.com/coyim/coyim/search?q=0313&type=commits [1] https://github.com/dino/dino/commits/76e425ed2705349b201444e78719896419862b00/xmpp-vala/src/module/xep/0313_message_archive_management.vala https://github.com/dino/dino/commits/76e425ed2705349b201444e... [2] https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/36 https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/is...
josephcsible 5y ago
I hate it. We used to have open standard, decentralized communication protocols with FOSS clients and servers, and now we have proprietary clients all talking to someone else's centralized server.
- zaik 5y ago
  > We used to have open standard, decentralized communication protocols They still exist. You just have to use them. I deleted WhatsApp and Telegram in January this year and told my contacts that I am only reachable via XMPP, email and SMS. It took some time, but almost everyone I want to talk to uses XMPP now.
Mandatum 5y ago
I prefer Slack to emails and whatever godawful comms our teams had to use in the past. There's nowhere to hide with Slack. If you say something, you have to commit to it. Too often in the past I've been working on a project and someone may commit to something on a call, but end up changing tune later on. If we didn't send out actions/decisions and get agreement from them - these decisions or opinions are never logged. Also the previous "this could have been an email" meeting responses we used to have has been massively curtailed because we're all happy to chat in a Slack room. Slack has made chat usable by more than just engineers. I feel bad for the Open Source community, however I believe there's plenty of tooling available to rip Slack data out of the platform and put it into something else. It just needs to be easier and more commonly used by admins. Similar to what we see on those IRC history websites.

MattJ100 5y ago
Well, this is a good demonstration of the "products vs protocols" issue that I actually wrote a blog post about: https://snikket.org/blog/products-vs-protocols/ https://snikket.org/blog/products-vs-protocols/ Much has been said about the staleness (or "stability") of Linux distro repositories. There's a reason you can't 'apt install slack', and this is one of them - many of the packages you quoted are years out of date. Secondly, there are a great many things that implement XMPP, and not all of them are suitable Slack replacements. It's unreasonable to expect that they would be (just like not everything that implements HTTP is suitable to use for daily browsing of the web). XMPP is similarly a protocol, not a product. To be clear I'm not saying it's your fault for starting with an "apt search", without a better idea of where else to start. That's part of the reason I'm advocating a slightly more product-led approach for XMPP these days. I'm personally focusing Snikket on personal messaging right now, so it's not a Slack replacement ( https://snikket.org/about/goals/ https://snikket.org/about/goals/ ). Luckily there are many open-source Slack alternatives these days (Rocket Chat, Mattermost, Element/Synapse). I think XMPP is further behind in this market. An XMPP-based solution would do well to use Converse.js or Movim, but that still leaves a whole lot of backend setup to deal with. For a custom solution with custom requirements it's great to have these composable building blocks available, but for a simple setup and onboarding experience, you're right - registering at slack.com wins hands-down :)
- theamk 5y ago
  I think the biggest problem with XMPP is the lack of understanding of target audience, and lack of acknowledgement of past problems. Even in this discussion, you and zaik mentioned "XMPP" without any qualifications as viable messenger system. Anyone who reads those messages may try it, hit the old/low-featured client, and give it up forever, like our org did. If the goal to get more users to XMPP, starting with "Try Snicket, it implements right subset of XMPP" will work much better than just saying "XMPP". And in the ideal world, XMPP would embrace Compliance Suites -- the "getting started" page would mention a compliance level for each recommended client, the "features" page would list which features were added each year, and each project homepage would carry a large compliance level badge. Then in our conversation, you could just say "hey, you want Advanced Client 2016 or later, not the ancient stuff in the Ubuntu repos". Sadly, I don't think this will happen because I think XMPP is focused too much on low-featured clients.
  - zaik 5y ago
    When telling my friends about XMPP I always recommend them a client (one of Conversations, Siskin IM, Gajim or Dino) and a public server to register. At least for servers there is a compliance suite: https://compliance.conversations.im/ https://compliance.conversations.im/