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 thing to sell off Stride, it isn't doing well, work with Slack to have some kind of automated migration made available and let customers flip the switch. Maybe if Slack were to keep supporting Hipchat on-prem, or provide a migration path to a new Slack on-prem product, that'd be fine. But to leave HipChat on-prem customers out in the cold?
What's the next Atlassian on-prem product to get thrown under the bus? Bamboo for sure, it's been unpopular relative to Jenkins almost since its beginning. It's definitely surprising that Fisheye/Crucible get any support any more, or Crowd for that matter. But why not Confluence on-prem too? Do we have to worry that Atlassian will stop supporting Confluence on-prem in eight months because Office 365 keeps gaining marketshare?
Atlassian's continued long-term support for minor on-prem products was one of the signals that said, if you pay up for HipChat on-prem, we'll support you long-term, you'll be fine. Atlassian completely shattered that with this announcement and eroded a lot of trust that enterprises were putting in them. Big shot in the foot here.
It's perhaps a mix of services, migration/import assistance and possibly a discount to our commercial version.
Would such a package be interesting?
For anyone who'd like to discuss outside of HN, please feel free to mail us at info at mattermost.com
See https://news.ycombinator.com/item?id=17622987 (also on HN today) to learn more about how Zulip, or contact email@example.com if you're interested in our offer.
Recommended. And, a lot cheaper than Slack which is insanely expensive ($72/user/year) - of course it is not free as it takes up AWS server resources and DevOps time, but we control all our data and security now.
sorry if it's obvious but do you mean Active Directory?
Something to move the needle commercially in favour of on-premise would be helpful in that evaluation.
Nayego is an open source and open standard team chat, that is federated/distributed/decentralised.
I found a link, but it only has a README
I understand you need to have different features for the different packages, but I think this is a feature that should be available for smaller businesses. The g suite is affordable for small businesses and startups, and I doubt it is particularly difficult to implement, so I suggest including it at a lower price point.
For me it’s not even worth continuing the trial without it.
But there are technical challenges. Asking for help from open source community to see if we can work together to find an outstanding solution: https://medium.com/@mattermost/help-with-open-source-hipchat...
It seems to get better every few months, which is nice. Doesn’t feel like it’s sitting on its laurels.
Off topic question and hopefully not perceived as mean:
Why don't you type your email address with an @ ? Wouldn't you expect the higher conversion rate to outweigh the mostly theoretical increase in spam emails? Or is there another reason?
Mattermost, with a clear migration path from Slack, at least.
Everyone has different needs, different existing environments, different service expectations+++
So you can't effectively stick to one price for the "large" tier. Given the differences in complexity and capacity consultants are needed. Startups can't build in-house service teams - the economics are misaligned. Not that you can get away from consultants if you buy from Salesforce, Oracle, SAP, or IBM...
Plus there are issues in terms of pricing and domain expertise across different industries - Federal, Education, Health.. legal issues in what your pricing can be and serious issues around their compliance environment means you need different teams of people to serve different verticals.
If you really need HA you are going to call anyways to negotiate. No one puts 15000 licenses on a credit card.
Since there aren't that many true enterprises that will allow you to test public prices like you can with consumer and SMB products, you have to go private.
The political dynamics you mention apply to developer pull products but you can easily fix that by calling or sending an email. In many Enterprise cases you want to talk to a VP or CXO for a full deployment and the free and medium offers cover the developer pull demand. If you really don't want to talk to sales AND you can spend $500k+ a year, you're a very rare case.
Why not communicate using a made-up or real life anonymized case-study? Example: For <n> people organization, with an environment of type <description>, it typically costs <$x> per user. To be really effective give 2, 3 such example scenarios.
Potential customers would be more than happy to extrapolate from this data to start their internal discussions.
s/extrapolate from/fixate on/.
Seriously, even made up "anchors" for potential enterprise pricing have a tendency to really severely mess up purchase negotiations--for both the vendor (losing them sales when the customer says "it's going to cost four times the example number for a company our size because we need it to integrate with our bespoke, ancient CMS/IAM solution? Hard pass!") and the customer ("this was supposed to be a productivity adder, but since it won't integrate with our bespoke, ancient CMS/IAM solution at a price we can afford, we'll have to train everyone on new processes and duplicate data/access credentials all over the place, making it a time waster and security hole.").
Number of employees and environment type (whatever that means) are not indicative of enough common scenarios in the large-enterprise space to be used to automate pricing decisions.
That's not a statement in favor of opaque pricing or service-provider-highway-robbery; just an observation of the real complexities of big (and often old), unique businesses.
Who knows if that had any influence on their success?
We don't want to pay the price we'd need to pay to keep Slack, and plus we want to host our own.
a) When you hit "Refresh" on your browser, do new messages appear?
b) Do you ever get blue bar message reading "Please check connection, Mattermost unreachable. If issue persists, ask administrator to check WebSocket port."?
If so for either of these, here's a solution you can send to your IT Admin:
Not affiliated with anyone here, but I think the answer is yes.
That said, even though it works as advertised the product is not perfect. The Mattermost UI is bare bones and some things like conversation threading are implemented poorly.
We ship new improvements monthly, so if you're on an older release you could quickly add a lot of features: emoji reactions, GIF selector, custom emojis, Slack-compatible keyboard shortcuts, hashtags, slash comments, Slack-compatible integrations, etc.
I really don't like the current way of "copy old directory somewehere, copy a new one and replace some files from the old one". That is very painfull and this process does not really invoke a lot of confidence.
I should be clear, my own UI complaints are minor, but I want to acknowledge that people expecting a 1:1 copy of Slack won't exactly find it. Mattermost works well for us, but I recognize that an enhanced UI with tight media integration must be important to many people, otherwise Slack would not have become as popular as it has.
Threading is really the only gripe I have personally - I don't like how it works, and I don't use it much because of that. But then I also don't have any real observations about how it could be improved either, and not using it (and basically operating as if it's IRC) is a perfectly fine solution!
For instance, I try to search for "pass" hoping to dig out the password someone pasted and it shows results containing words like "wordpress" and "css" that petty much buries the actual matches even if they're somewhere way down in the result.
web/apps have been pretty much completely rewritten too. it's noticeably better, if you haven't used it for a while.
1. The contact list interface lacks in a couple obvious ways. At the top there is an "Unreads" list, except there is a different unread list depending on which Team you're in. Except maybe it's not different, because unread Direct Messages will always appear in Unread, but unread Channels will only appear in their Team. There's also no option to sort anything contact-related: you have to have your Channels at the top (Public, Private), then your Direct Messages, subsorted alphabetically. (In particular, you can't sort by "most recent", so if you're chatting with 5 people during the day and you have 40 people in your DM list up, good luck finding them after they're marked as read.)
2. There is a keyboard shortcut for "Switch Channels" (Command-K), which you can use to send a DM to someone—but you can't use it to send a DM to two people at once (ie. typing Command-K+"alice" sends a DM to Alice, but typing Command-K+ "alice, bob" does nothing).
3. It's incredible that the native client will mark you as "Away" when you're working on your computer if the Mattermost app is not in focus.
4. I guess this is hard to get around given that there are slash-commands, but if I had a dime for every time I tried to paste a path and Mattermost said "Command with a trigger of '/home/shivatron/foo' not found...", I'd be a rich man.
5. Speaking of paste, I'm glad the message character limit got increased from 4000 to ~16k in 5.0. Does it offer to automagically truncate like Slack, or do I still have to delete some characters and try again in a loop until the message sends?
10 second load times and slow/wrong notifications have not been a problem for us at all.
I'm from Flock ( https://flock.com ) . It’s currently rated the #1 slack alternative on PC Mag(https://goo.gl/eGZqH8). We've also created a tool to help you quickly import all your team data from HipChat to Flock in case you're interested in trying us out. Please let me know if you have any queries !
edit: also https://github.com/Cadair/skill-matrixslack
There is a replacement homeserver (https://github.com/matrix-org/dendrite) but it's not done yet.
Also, client support is awful. The only one I can reasonably tell a non-technical user to use is Riot - but that's somehow more resource hungry than the Slack desktop app. There are good ones, but they are either only for technical users (weechat) or are extremely barebones (nheko, quaternion).
We're basically doing nothing but fixing Synapse's performance problems currently, and improvements are on the horizon. We're late because we got sidetracked fixing flaws in the protocol, but as of the last few weeks we're back on perf again. So far we've sped up /sync by 2x and reduced CPU by about 20%, but the RAM improvements should land over the coming weeks unless we have further distractions.
Meanwhile, on Riot, we're busy landing performance fixes which should make it much less resource hungry than Slack. These are literally landing as we speak: https://github.com/matrix-org/synapse/pull/2970, https://github.com/matrix-org/synapse/pull/3331 etc.
I mean, my 10-active-users off-the-shelf XMPP server (ejabberd) uses about 100MB RAM currently.
It's actually not as bad as I remember (time made me think it's worse than it really is) - it's really only large rooms that feel slow. Oops.
I just guess the whole thing doesn't feel responsive. Messages sent take a while to sync between different clients, etc.
Fit for orgs with external partners, providers, customers, freelances, remote and home office workers...
edit: btw, the number of comments you've made in this thread to “sell” your solution is… abusive?
Unfortunately the whole world seems to be heading the wrong way with cloud based "everything as a service" where you control nothing. If the provider or cloud goes down you have nothing. Even if they just take your keys you have nothing. It's quick and easy to setup and convenient but you're basically a hostage.
You don't necessarily have to fork it, just the possibility of the fork changes the game. It means that the original maintainer cannot shut you down. If enough people deem a fork useful they can work together.
Of course there's a cost associated with it. But how much is it compared to the risk of someone shutting a core element of your business down? You have to evaluate.
Those who really want to do on premise, will find their way to one of several niche products in this space. But I don't think any of these players will grab a lot of market share. Ultimately anything run on site is going to be expensive to support and why bother when you get cloud based offerings. Compliance issues can be addressed in the cloud as well.
Absolutely. Depending on how an organization manages its own IT security, data can even be more secure in the cloud than it would be on premises.
Decent providers like Atlassian invest in their IT security and employ dedicated security experts, something that can't be said of all organizations that host their software on premises.
However, I think in some cases being able to run specific software on premises is still a valid concern. Compliance is only one possible reason. Being able to easily access your data outside of the vendor's software might be another.
While they can be addressed, alleviating compliance concerns often is no easy task either, especially if your organization has to comply with laws and regulations from different jurisdictions. For example, I know of one organization where developers are allowed to use most Amazon services but are explicitly forbidden to use Amazon SES because that service currently is only available in a region that's technically outside (EU but not the same member state) of the jurisdiction the organization is in.
In order to attack an on premise application that is safely behind a firewall in a private LAN, one would have to come up with more creative, staged attacks (such as DNS rebinding or blind XSS attacks).
So, put simply, whereas the attack vector of a cloud based service is basically "the internet", this isn't usually the case with on premise deployments, and therefore they are inherently safer, or at least much harder to attack.
On top of that, cloud based services are usually multi tenant environments, so the assets to gain there are huge. One serious hole in such a service (be it Slack, logz.io, Github private repos, New Relic, etc.) will probably be a disaster.
For the average mid-sized shop that's probably true. However, it's usually larger organizations that worry about storing data in the cloud.
For these organizations and attacks specifically targeted at one of them, I suppose that in order to access vital company data both social engineering and hacking an internal system are much more effective attack vectors than gaining access to a third party system.
How can I guarantee the security of my customers data, if it's not hosted on equipment I control?
Mail us at info at mattermost.com? // and this is an open invite to any HipChat users who want to keep data under IT control.
Regarding importing from HipChat, while it is tricky as the data is within HipChat's VMs and not documented, we can potentially work with you to move over smoothly.
The good news is if you switch to Mattermost we run as a single Linux binary with MySQL or PostgreSQL, so using us you have 100% access to your data as well as the source code to understand everything we do with the data.
It's Java so runs just about anywhere, and with even relatively low resource allocations, you can support a large number of concurrent chats and group sessions. Plus, since XMPP is an Open Standard, you can use any XMPP complaint client of your choosing.
Cisco embeds Openfire in a few of their enterprise products already (including Finesse), so you might have used it without even knowing.
The IgniteRealtime community is pretty active and new releases come out regularly.
Over the past years I used 'Pidgin' as my desktop client, but it was not were I wanted it to be so I was actively looking for alternatives. Dino looked very promising on paper (supported XEPs) but they lack basic stuff like systray support (at least the last time I checked it out).
For a long time Gajim wasn't any better than Pidgin, but earlier this year they released their version 1.0 which added support for some more XEPs most importantly MAM (enables proper history synchronization between clients). Since that release I switched to Gajim and stopped looking for alternatives ;-)
Also, I don't like the fact that it's person based whereas mattermost (and IRC) are group based that also allows person based chat.
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.
If you divide the amount they've paid out in bounties by the number of bounties paid, and compare with their bounty tier rules, it's clear that a lot of the vulnerabilities that were reported in Slack are relatively severe.
(And I agree bug bounty programs are great; we also use HackerOne)
You could easily write a massively insecure application in core python, but things like Zulip use Django which shields you from most of it.
It is about Zullip being open source.
Most people nowadays are using frameworks and abstraction layers which make most of these points moot.
That being said, it’s unfortunate that OSS in many areas lags behind proprietary software in so many different areas, and it’s clear that for many different business use cases properietary cloud services are going to be more cost effective than OSS. As the deployment and ops aspects of software becomes more automated and simplified, I think this might begin to start shifting back in favor of OSS though.
You can always make the argument that for this reason we should only write our own internal tools and use OSS. However, it is just as easy for an OSS project to be abandoned or neglected. Often times enterprise contracts will have a source code escrow clause that provide the enterprise with the source code in the event of a shut down (the same capabilities as a fork & take over maintenance anyway).
We don't actually know the plan for HipChat On-prem yet (do we?). Slack and Atlassian are both known for being customer centric so they will probably follow what Facebook did with Parse. Open source the entire thing, sunset the operations and development over the course of a year or two with minimal security updates/patches and no feature dev. This could be what the investment from Atlassian was tagged for... to make sure their customers are taken care of while most migrate to Slack.
Yes it does, the thing is you have to talk to them to get it and it costs about 10 times as much as on-prem HipChat.
The company I previously worked for switched to RocketChat for this reason (Slack asked ~100K vs HipChat ~10K). RocketChat is free but you'll have to manage it yourself.
(I don't have any association with Keybase, I've just investigated this product as a Slack alternative.)
My team is happy to welcome all HipChat users to the Wickr Pro platform. Unlike on Slack or elsewhere, your collaboration flows are end-to-end encrypted so no 3rd party including Wickr has access to your team data.
We’re delighted to offer 100 free seats for HipChat teams looking for a secure team collaboration alternative. Your teams can spin up a Wickr Pro SaaS private network in minutes, free to trial for 30 days with flexibility to extend.
Test drive our end-to-end encrypted messaging, secure channels, team/project rooms, file sharing for up to 5Gb, video conferencing/calling, screen sharing and enterprise-ready admin controls including SSO.
Get started here: https://wickr.com/the-best-alternative-to-hipchat/
If you need ON-PREM deployment, let my team know here, they can help you seamlessly navigate your transition from HipChat: https://wickr.com/products/enterprise/ and we’ll get you on-boarded.
We run Mattermost on-prem. We've been quite happy with it. They have well-defined  migration plans for Slack, Hipchat, and others.
They're kidding, right? That's a well-defined migration plan?
I’m not sure how this is Mattermost’s fault.
For distributed companies: email for async communications, phone for sync. If you need to bother someone immediately you might as well have a high bandwidth audio (or even video) call.
If I'm not connected to Slack, or even a member of a Slack channel - I can connect/join the channel and be able to get all of the history back to the beginning of the channel (or whatever Slack's limitation is).
This makes it very easy to jump into the middle of a conversation and not worry you've missed some important context.
With Nayego, we are working on that. https://nayego.net/ you can subscribe if you want to see the preview.
Nobody has made persistent IRC channels that are as usable as newer chat products that don't try to be IRC.
So can this be solved for free? Is it even a good idea to solve it?
As others already pointed out, that requires technical skill and fiddly configuration.
It also doesn't help with the specific scenario of jumping into a channel you've never been in before, and being able to get all the history of that channel.
I frequently have to jump into the channel for another team, provide some input around whatever the current issue is, and then I generally leave. I don't care to see/read about whatever that team normally does. With Slack, that's dead easy - join channel, I can scroll up and see the rest of that conversation, then talk a bit, and get out.
There's also a ton of other features, like threading, editing message in-place, and persistent file attachments that either arn't supported, or require some kind of custom implementation - or depend upon IRCv3.
We also make heavy use of various integrations - our customer support team gets pinged in-channel when certain events happen in their support platform, which has Slack support built in.
Our deployment tools notify teams that need to be aware of new releases and links to resolved issues/new features.
So, yes, we could cobble together something that does all of these things - but this is a major undertaking.
Disclaimer: I am not associated with Zulip in any way.
As for Microsoft Teams, they don't have to be on premise since all the big corporations that use on-premise only have for the most part adopted Microsoft 360.
Our added value: UI and specific functions, simple user onboarding, upgrade management...
firstname.lastname@example.org or visit https://watcha.im
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.
Nayego is trying to hard build a HipChat-like client+server that is open source and based on XMPP.
https://nayego.net/ you can subscribe if you want to see a preview.
> As a result of this partnership, Atlassian is discontinuing all real-time communications products, and we are working with Slack to provide a migration path for Stride and Hipchat customers.
They provide dates for shuttering everything. Stride and Hipchat Cloud are shuttering Feb 2019. The latest version of Hipchat Server will be supported until June 2020.
The 2 products aren't merging, so far as I am aware. Slack is buying Hipchat and then promptly discontinuing support for it. It's primarily a move to eliminate competition, not to acquire technology.
It should be simple enough, since you're operating on a negligible scale when it's on premise.
I wrote about this recently, if anyone cares: https://news.ycombinator.com/item?id=17494243
(bring on the downvotes. What's karma for if you don't spend it sometimes??)
Bond: You expect me to [use RocketChat or Matrix]?
Atlassian: No, Mr. Bond; I expect you to die.
Look at it this way: IBM uses Slack. That means that 1. they researched the security threat model and were okay with using it for their own internal data; and 2. they managed to convince all their clients that those clients' internal data, and those clients' customers' PII, would be fine being passed over Slack. That's a pretty large argument, in my mind, for the idea that there's nothing about Slack that disqualifies it from even the crustiest dinosaur of a corporation's requirements. To mangle a phrase: "Nobody ever offended a conservative regulator by copying IBM's choices."
Or do you have security requirements that IBM—in its professional-services interactions with a whole ecosystem of clients, including banks and government agencies—doesn't? If so, maybe you need something on-prem.
Even then, though, you realize that you can just not put the critical stuff directly into Slack, without much impact on your workflow, right? If you're e.g. an investment firm, doing BI and quantitative analysis over tons of data, you can still talk over Slack while keeping the actual data to your Intranet. When you want to refer to the data in the chat, you paste the link to the (Intranet-hosted) data into the channel. Slack can't visit the link, but you can. Isn't that enough for... pretty much any use-case?
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 is more disruptive than helpful. It fosters a "Always on" culture, where irrelevant chats are exchanged publicly to advertise how much work is being done. If you shut down Slack and appear as Offline people assume you are not working.
It also seems to me that now that Slack became the norm for communication, I almost don't receive well written emails with well-argued technical discussions anymore. Everything is now a "Chat" that dilutes the technical discussion because it needs to be responded "directly".
I would expect 2018 to be the year where people start questioning the utility of "Slack everywhere" and not blindly jump on the Slack bandwagon because that's what great startups do.
When used properly (not lazily), Slack is a great place to organize communication between teams. At worst its Skype with a way better UI...what's wrong with that?
* it has a history I can actually search. Skype used to have this, but removed it when they rewrote it in Electron. !@#$ you to whoever at Microsoft decided to get rid of that; I used chat history search every day as part of my workflow.
* it has an API/plugin ecosystem. Admittedly, that's a walled garden so it's a double-edged sword. But for businesses that's awesome. Skype used to have an API but that's been deprecated. Conjecture: from abuse?
* it has security. I can log on to a private Slack and know that the people in there belong there. I can search for people on Slack and know that I'm communicating with who I intended to communicate. On Skype, you search for your coworker by typing in their name and you end up finding some other person instead. Hope you didn't just reveal corporate secrets to China.
Slack doesn't come without its own set of gripes, for sure. Let me enumerate some of them:
* Information density isn't configurable. I want a teeny tiny font. It's better than what Skype has become but still not as configurable as chat clients from the 90's
* Resource hog. Seriously, we've gone so far backwards it's appalling. Chat clients from the 90s didn't need anywhere near as much memory or CPU as Electron does and they were just as functional (sans audio/video/link preview).
I'm sure there's others but I'm tired
But I agree it works like shit, half the conversations aren't there and I can't figure out a pattern or why.
Just zoom in/out with Cmd-+ / Cmd--, it's just a browser after all.
You get to decide if you want to communicate asynchronously.
As for devops alarms, those should be firing on multiple protocols and platforms anyhow.
Anything else can usually be better accomplished by announcing "office hours" during which you can be reached 1-on-1.
However, many people fall in to the latter, and Slack handily beats the competition there. There is also an element of having nice and polished features baked in that appeals to many people. Want it on your phone? There's an app. Want to search? Baked in. Want convenient chat bots? Click a button.
To be sure, all these things are possible in IRC and other lo-fi chat protocols, but getting them set up is easy on Slack. I see this as similar to the argument of Linux vs. OSX. Linux can do practically anything OSX can, but it requires tweaking and setting up. It's a battle of pick-and-choose vs having it all baked in.
I also don't like using chat at work. It's not because I want less interaction, it's because I want less interruption. Email has a norm of asynchrony where I can respond to email when I reach a good point in my current task. With chat, the other party is presumed to be sitting staring at the screen waiting for my reply, so I have to drop what I'm doing to respond.
I don't think the latter is good for my overall productivity.
What do you think has caused that expectation in your mind? Do you wish that for the people you’re chatting with? Have you worked with people who do expect that? Honestly curious.
I wonder how my growing up with it, and in chat rooms with mostly tech-savvy folks, has affected my use and expectations of it, too.
> Have you worked with people who do expect that?
Yes. Manager expects it to be like talking to you across the room. You answer there and then. If you slack him though he doesn't expect to reply immediately and gets annoyed if you interrupt him to say you really need an answer.
> Do you wish that for the people you’re chatting with?
Yes, saves making a telephone call.
There again, if I Slack someone, it'd better be important not time-wasting.
OK, maybe not literally staring at the screen.
> What do you think has caused that expectation in your mind?
I think the structural analogue and communication style — even the name! — of chat is a verbal conversation. In a conversation, you say as little as needed and then pause for the other person to take their turn. Each utterance is pretty short so that you give the other party a chance to respond.
If you do that asynchronously, it takes forever to work through a sizeable quantity of content.
In email, the analogue is written letters. The expected asynchrony is high and in return the writing style accommodates that: each email is usually a roughly complete though with possibly some paragraphs. Since you know the person replying to you can reply to individual sections, it's OK to put out a complete thought. You don't have to shorten it to give them a chance to interject.
Phones reduced that price point - but it still has a cost to me.
Now IM / Slack has flipped it on its head - the cost to the interruptor is negligible but the cost for the interruptee is their mental derailment - and no ability to judge the overall benefit of helping until it is too late
Plus I don't really see the win - for real
time co-ordination it's hard to beat a mass phone conference ( we are doing a complex release with phased rollouts and devops watching the traffic - then get your headsets on, and everyone must hurry up and wait)
Slack is just secondary for that - useful for spelling out what has been said but otherwise ...
For letting others know what has happened - that's called an after the fact report or "email".
So really i don't see the use case except it means that when like the phone, i reach you i am confident of a reply in a given time period - that may well be defining facto
It's the "check it" that's a mess in a high-volume environment.
E-mail threads that can be seen to branch, and in a pinch I can skip irrelevant branches once I've determined their vector.
But each Slack channel is a continuous stream of text with a tiny scroll slider. There's no possibility of skipping a couple of pages of messages unless one just seaeches for direct mentions, at which point why bother? If it's important they'll just ring / call / e-mail..
I'm firmly in the "email should be used for substantive discussions" camp, but ever since we got the bandwidth and CPU necessary for the internet to not be a primarily text-based medium, the illiterates took over and that was the end of that.
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 realtime discussion is failing to document the outcome of the meeting -- and that of course goes into a ticket or long-term docs. A meeting with no notes or outcome might as well have not happened.
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 additional cost of making all of that time strictly synchronous can grow exponentially.
It also excludes large categories of people, including introverts and non-native speakers. I've worked with a number of people who just flat out did not or could not participate in real-time face-to-face discussions, but who could express themselves masterfully via email.
Of course, the "faster! instant! now! now! now!" crowd don't even have the patience for slower, deeper, better-reasoned discussions, which is why they shy away from any form of communication that has any more depth than a tweet or a PowerPoint slide. Slack is great for these people because they don't even have to string words together to communicate, they can just click on a reaction emoji.
Sure, some things (operations, for instance) have genuine urgency to them, and I think real-time communication is essential for situations like that. But if you're doing work that will have an impact on the span of months, quarters, or years--either major strategic business decisions, design, or project development--you're better served by thinking deeper instead of thinking faster, and deep thought is exactly what the long-form written word was invented for.
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
The internet is such a large collection of knowledge, I just wish more people used it to improve themselves, or at least their understanding of the many different things we have in the world.
I tend towards being an introvert, and I'm not always good at coming up with an argument on the spot. I recognize this, and I will often end the real-time discussion by literally just saying "Ok, I need to go think about this before we discuss it anymore. Let's come back in a day or two." Just like you don't have to respond to e-mails the instant they come in, you don't have to do it for real-time or chat, either.
I will also do the same to others when I can. For example, yesterday I suggested a new approach to how a certain part of our product works, and pitched it to the team. There was only minor feedback so I just said "okay, go think about it, and I'll bring it up again later", so I will probably ask tomorrow to see if anyone has further thoughts on it. It's amazing what sleeping on ideas can do.
The thing I'm really trying to get at here is real-time doesn't mean "now! now! now!". There's absolutely nothing wrong with several meetings over the course of days or weeks or months. For strategic and key design discussions, there should absolutely be documentation written between those discussions. In fact, that's basically the way I operate: discuss, document, give time for people to review, and then discuss again, repeating as much as needed.
There's people that are opposite and want the response "now!", and don't want to take time to think through problems -- but I would guess there's a large overlap with the type of people that come over to your desk / call you and say "I just sent you an e-mail, did you get it?" and then only read the first sentence or two of your reply anyway.
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.
Seriously, go read the lkml archives sometime, and go tell the authors of one of the most important and high quality pieces of foundational software in the world that they would be better served with something like Slack.
Most work communication is usually within our issue tracking system
We use slack very lightly,
- most of our conversations are face to face but anumber of remote employees, and slack is used instead of face to face. Often for video calls
- copy pasting things to other people
- a sort of mini internal HN where links are posted to interesting things in the dev world and we discuss
- prodding people "Oi, my PR is still waiting .... " "did you setup ... ?" etc
- telling people where we went to lunch so they can find us.
EDIT: Whoops actually Shared Channels is the feature I was thinking of: https://slackhq.com/introducing-shared-channels-where-you-ca...
I wonder how much of this attitude is a result of poor email client UIs. I switched over to using notmuch for my mail about a year ago, and I now consider email to be a great place for discussions: I can search my entire history almost instantaneously, far faster than with Gmail or Inbox.
> The problem I think most people run into with the realtime discussion is failing to document the outcome of the meeting -- and that of course goes into a ticket or long-term docs. A meeting with no notes or outcome might as well have not happened.
I definitely agree here. This falls under the heading of 'things we used to know as a society that we've forgotten.' Every meeting should have an agenda, even it's just a single agendum 'discuss $FOO,' and every meeting should have some sort of minutes, even if they're just 'discussed $FOO, decided to pursue course $BAR.'
I think the attraction of email is it looks like it short-circuits the need for this. "It's all in writing in the email trail" makes moving fast look easy (no realtime meeting that then has to be written up, the document amended on people's feedback etc). But understanding is missing and misunderstanding happens.
I'm starting to move an organisation's planning from emails into meetings and specifications. They are resisting massively because it "wastes" time. Given every project up to now has changed spec twice after launch, I see time being saved if it's correct at launch.
But again, it can be learned by everyone, it just takes time and effort.
But if you have to choose a medium of conversation, are you better off choosing one that excludes introverts, non-native speakers, and people who aren't loud and obnoxious enough to command the room? Or would you rather exclude people who lack the patience or intellectual ability to read or write more than two or three lines of text at a time? Which choice allows deeper and more thoughtfully considered ideas to enter the discussion?
I'm loud and obnoxious enough to thrive either way, but I really don't want important professional decisions to be made by the "rofl tl;dr" crowd.
They are just different mediums. Long form is better for getting across new ideas that have to be explained for the first time, but a medium like emoji allows for incredibly dense communication with single glyphs once the meaning has been established
With email, how can I subscribe to conversations I'm interested in? Mailing lists are nice, but we have no real way to make mailing lists that start and stop on the fly like a chat channel in a way that is searchable to the entire organization during or after the fact.
What email list system allows for quick creation and the ability for everyone in an organization to know that a conversation is happening and how to join with the ability to get all the context necessary in a chronological order? (Reading threads can get really repetitive in a mailing list, especially when trying to get up to speed on an issue.)
You get to all the requirements, and you end up with a discussion board instead or a new product that is to email lists what slack is to chat.
Email is great for some things, but there's a reason people use slack instead even when they already have email.
I hope you all do well with this!
Isn’t that what subject lines and mail archives are useful for?
Nobody has put together a simple solution in the mail domain. Maybe there's a market for it - turns out someone might pay for it if it's better than the slack experience.
There's always newsgroups, which use NNTP (which isn't that dissimilar to email). They have existing groups in a hierarchy that can be subscribed to. It doesn't really give users the ability to create new newsgroups in the fly though.
This would also be acceptable IMO. Any medium that enables asynchronous long-form written communication has advantages that are fundamentally impossible for any synchronous chat medium to match.
It turns out that listservs have successfully done this for decades. If there was even a fraction of the effort invested in this communication style as is invested in reinventing IRC with emoji and reaction gifs, I'm sure it would be even better.
Additionally, all this bloat and lack of structure makes it hard to search the text for both humans and machines.
Not saying that Slack is better, it addresses some of the structuring and some bloat problems, but adds distraction and encourage discussion bloat instead.
Is it a chat client? A knowledge base? A conference call? A command line? Who knows!
Which is totally why Slack isn't popular with businesses. /s
Just because you personally haven't found it useful, doesn't mean hundreds of thousands of other business users haven't.
I tried emailing longer form things at my current job and rapidly hit a cultural wall: people _do not like_ getting long emails, or emails with more than 1 or 2 replies. Slack people apparently have no problem with because it's "lighter weight", but I struggle to see how always-on disruption is lighter weight than check-it-a-couple-times-per-day email.
I think a deeper problem is lack of delineation of responsibility and adequate planning. Slack & other "always on" communication systems make it easy to say "why plan? I can _just ask_ when I need to know something" or "we'll have a conversation" rather than specifying & recording or relying on a more rigid interface like a ticketing system.
tl;dr: get off my lawn you dang kids!!
I wish there were more people who were in the "newsgroups should be used for substantive discussions" camp. They're better than email in that context.
I am flooded with automated notifications that basically are "who gives a shit". I think the main reason I use email is for password reset. When you receive 1-2 thousand emails of non-spam but still unimportant cruft, it gets ignored or overlooked.
Email is pretty much dead to me as a meaningful way to communicate.
Sidenote: the term "ping me" needs to go away.
Part of this is a UI problem, but it's still a problem.
I didn't say Slack is the answer, either. Just that email isn't a serious competitor to Slack.
Maybe mysterious quasi-state actors will steal your secrets and outcompete you decades from now, but they could probably do that anyway. The SEC will certainly fuck you up right now if you can't demonstrate adequate controls on regulated employees' communications.
Important/immediate discussions take place in person, or on slack. (Or hipchat or sametime or lync or windows messenger or hoary old ICQ for all I care...)
I find that happens an order of magnitude more often in Slack than email. The number of times important things here don't get done on time (or at all) because "Oh, I must have missed that in Slack...)
That's a very harsh attack and I'm sure you're aware of all the nuances you're conveniently skipping over. I'm not sure how you think this adds to the discussion at all.
That's pretty arrogant. Perhaps people have different communication styles than you. Not better, not worse... just different.
The dialup-era Internet was mostly text and a little bit of pictures. There was good text, bad text, and lots and lots of fanfiction, but at least it was text. Even if you went to The Onion, there might be one goofy photoshopped photo but you had to read an actual article with real paragraphs to get the jokes. Now everything is a video, or a picture, or a meme, and everything longer than 140 characters is “tl;dr”. That’s a cultural decline akin to when television displaced reading in the mid-20th century.
I can communicate in either style, so it’s not a personal thing from my perspective—except, since I can communicate in either style, I can also tell which style is more conducive to deep and meaningful discussion.
(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... )
I'm not doubting you, and I acknowledge that I hear that kind of thing with some frequency, but I've not seen Slack (running in Chrome on Ubuntu) use anything like those amounts of resources.
I've had a pretty busy slack client running for several days, and it's using 204,484K of memory and 2.0% of one CPU.
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
fubar 2922 0.0 0.1 61648 26668 2 S0+ 19Mar18 22:58.73 weechat
Re: Slack resource utilization: I'm not passing a value judgment as much as expressing confusion over multiple claims I've noticed about Slack utilization that is far, far greater than anything I've seen.
I personally love Riot and Matrix as a "modern IRC".
It does require having your own server to host it on though.
That's nice for you personally, but how does running an inhouse bespoke IRC server have anything to do with whatever line of business your company is in?
IRC is just a particular implementation of chat. The only thing keeping it relevant is the several hundred thousand people currently connected to servers.
Within a more defined context, such as work communication, adoption network effects become irrelevant. You can just build your own system and set everybody up to use it.
If I want high latency, high bandwidth, there's email. If I need low latency, high bandwidth, that's an in person whiteboard session or a video call.
That does mean I think Slack is overhyped... but that also means I think Slack does something valuable. Just maybe not as valuable.
1. No markdown support and half-assed code highlighting support.
2. No (real) message editing.
3. Silly parenthesis based emoji.
Its search is better than Slack’s; its performance is better than Slack’s; its integrations are better than Slack’s; its client memory and CPU usage are better than Slack’s (whether in a tab or as a real, native app); its group video chat is better than Slack’s (does Slack even have video chat integrated, with screen sharing?). Most importantly for us, its price was 4x better than Slack’s all while offering better features, performance, etc. The only thing it didn’t win out on was hype. (It should also be noted that HipChat could also be bought in a self-hosted configuration, which allowed for HIPAA compliance, something that Slack won’t even bother competing on. I didn’t need it, but hey, it matters to some people.)
Slack is an overpriced distraction monkey. They’re selling it like it’s the whole enchilada, but it’s a damned feature bullet. I personally cannot wait until Slack is dead, because it’s the worst chat service I’ve ever used (and I love full-featured integrations).
Now, I have to find a replacement for HipChat that won’t cost us US$200 per month for our office (if we pay a year in advance, more if we don’t).
I think even though the industry is fairly nascent, a lot of team messaging products seem to occupy unique sweetspots. It's probably just a case of which product suits an individual's/ team's working style more. In fact, I have seen different people rate the same set of features in contrasting ways.
That said, a lot of stuff which you mentioned resonates with features we feel are critical as well (integrated group video chat with screen sharing, seamless integrations, better pricing, among others). We have had a bunch of Hipchat users migrate to Flock over the past few months using our migration tool. Per the reviews we got, they found the transition pretty seamless. If you want to give us a try, reach out to us at support at flock dot com. We do have some offers for Hipchat/ Stride users :)
Letting a strappy upstart have access to that data is a completely different story.
Really IRC just needs some well designed clients, I don’t like any of the offerings I’ve seen for iOS or desktop.
It's changing a lot for some time now.
IRC is interesting, but it doesn't solve the use case by itself. (IE, as a user I can easily look back to the entire history of the channel regardless of when I joined and can search every message that was ever sent on the server - or every message in the last 12 months even.)
I use that daily.
Maybe in a few years. I say maybe, because XMPP is an IETF RFC, and frankly, it sucks.
XMPP is a well-thought-out protocol, and a lot of the XEPs are great features. The problem I always had with XMPP is that XEP support is unequally distributed among clients, and the fragmentation really undermines the amount of cool features XMPP has to offer. As a (made-up) example, Psi+ might support video calls, but not server-side history, and Pidgin only supports server-side history, and Adium is the only one that supports Service Discovery...if I want both, I have to pick a client, and possibly have to use two clients signed in with different resources.
As a possible solution, we could have a "logo program" for XMPP, where a core set of XEPs are required to call yourself an XMPP client (this is the case already IIRC), and you get rights to call yourself "supporting XMPP-Enhanced" if you support these other XEPs, and "supporting XMPP-Full" if you support all of these XEPs. Something like that might work, but you'd have to have a way to actually drive development toward these features.
XMPP could be used to build a service like Slack (with its own clients, specific feature set, etc.) that may or may not be federated and it would still have the benefits of using an open protocol (even if it's not federated I can use a more accessible client, a client on a platform they don't support, less work to get up and running because libraries exist, etc.)
I'm hoping the Compliance Suites will become something like you mentioned in the future, but I'm no longer the author so we'll see what the new authors do with it: https://xmpp.org/extensions/xep-0387.html
That way you could very easily coordinate a common target for XEPs. Clients which would not support the newest features would still work with the others but users could simply see which clients support the state of the art features. And for developers it would make it easier to identify and skip old XEPs (e.g. how many XEPs are there to confirm a message has been received? Which is the recommended one for new implementations?).
You may not prefer it, but it objectively does not "suck".
I challenge you to consider whether your perspective applies to the 99% of people who use Slack that are not developers writing software. For those people, email is often not a place where well-argued discussions happen. It's usually a place where chat-like communication happens, slowly, and in an ill-fitting interface. For non-developers, let's take a operations associate for example or a logistics manager, or someone else whose job is to coordinate and communicate frequently, Slack plays a very different role than it does for devs.
Unfortunately for you, and others like you who don't like Slack, if 99% of your company wants to use it, you'll almost certainly get pulled in. Unless your department or team explicitly opts-out, you'll get pulled into the same platform the rest of the company is using.
This isn't to say you're wrong -- just to say that we must not judge the hype around Slack, or it's clear successes, as a fad if we're only judging it based on the experiences of the kinds of people who frequent HN.
Not sure what it is about HN assuming software devs are somehow intellectually and professionally superior to others.
Dunno but this thread is full of a bunch folks rather arrogantly assuming their way is the One True Way.
Slack (and hipchat) didn't get big for no reason. It's because it fulfills a pretty big need. Tons of people in my company use & love Slack... Last company was a big hipchat company...
However, it's definitely true that email is typically used both for "serious and well-argued discussions" and for chatty threads along the lines of
BTW How are we looking for this month's revenue target?
>No idea, maybe the data load didn't run last night,
>I'll look into it.
>>This report looks broken, the opportunity I closed
>>yesterday isn't in there, what's up?
So, the tens of thousands of teams paying for Slack either aren't having serious conversations or have decided the opposite. Here are some things I think you are undervaluing about team chat:
- It replaces many meetings and phone calls that are more interruptive.
- It helps distributed teams with legitimate needs for casual collaboration.
- It reduces an enormous cost of people being blocked waiting for email answers to simple questions that could not be anticipated.
The disadvantages of team chat can be avoided by discipline, but the benefits above require an assistive tool.
While we are at it, if you can't distinguish Slack from other team chat solutions, here are some things I think you are undervaluing:
- ease of onboarding for teams and individual users
- scalability to large, active teams
- Enterprise IT management
- automatic refunds for inactive users
- integration and third party app community
- Dev community supporting custom integrations
- strong mobile and desktop experiences
All of the above are super important for companies adopting, even though they're not about the core channel-messaging interaction you experience day to day. None of the alternatives check all of these boxes, and only teams is close.
I'm a dev at Flock, and an ex-user of Slack in my previous company, I hardly miss anything Slack had that isn't there on Flock!
If you're looking for a product built by top MIT engineers who spent years thinking about how to make chat actually productive, check out Zulip. I'm one of those MIT engineers, and I agree that Slack is a huge waste of time, for precisely the reasons you describe (here's our attempt at explaining how Slack wastes your time: https://zulipchat.com/why-zulip/, and how Zulip solves those problems; there's more on our homepage).
The fact that Slack is, in most organizations, either very low-traffic or a waste of time is why we don't market Zulip primarily as "open source Slack" -- it really is a different product, designed to be amazing for a large, distributed team doing a lot of communication, without things becoming overwhelming.
If you don't believe me, read this awesome cartoon by one of our users: https://twitter.com/b0rk/status/986444234365521920
(As another reason for Slack's success, I'll also add that a lot of "Slack clone" products are pretty buggy; everyone underestimates how much work a high-quality chat experience is. Check out https://zulip.readthedocs.io/en/latest/subsystems/markdown.h... and https://zulip.readthedocs.io/en/latest/subsystems/events-sys... if you want to learn about the complexity of a few of the more interesting challenges.)
But the flat thread model is still limited, particularly for complicated topics even a thread starts having the same problem as a channel where there is too much going on; have you thought about tree-structured threads, or some way of branching threads when there is a bunch of discussion happening on different topics?
I haven't really used Slack much, but one of the other places with lots of space for improvement in Flowdock was search, and Slack does seem to be investing there significantly, and I hope Zulip is as well.
With Zulip's existing model, you can always fork off a side discussion by just starting a new topic, if appropriate adding links in one or both directions (and people pretty naturally do that when it makes sense to). Some Zulip users are fans of a convention to name a topic "original_topic.d" for a "digression" off a topic, but I think it's a much better approach to choose a topic that more directly suggests what the forked conversation is about.
(And I agree search is really important! If you're having lots of high-value conversations in a tool, it needs to be easy to find them later. Zulip's powerful full-text search has been praised as a lot better than Slack's since our very first prototype version of it. I think a big part of the reason is that the threads provide the context to make it easy to find the rest of a conversation. But we're always working on making it better).
When Slack is down for a few hours, I know start-ups that feel it in the gut.
As a social tool, Slack is one among many, but social tools for work are becoming huge because they enable passive knowledge transfer. Employees can spy on others' conversations to see who knows what and that knowledge makes companies more efficient.
Something's lost and something's gained in living every day, but Slack isn't a fad and it's not going anywhere.
Slack didn't invent those qualities. It's not unique in that regard.
What Slack does do better than most is provide a half decent interface for real time chat amongst groups of people. Personally I'd prefer vanilla IRC because I'd then get to chose my chat client but in terms of official clients go by, Slack is better than most (though that's really more of a criticism about Skype, email, etc than a compliment to Slack. I mean how is it that so many collaborative tools have such poorly designed UIs?)
The rest is a cultural problem that exists will all communication channels (including email). Ask people to be mindful and not use @channel all of the time (you can disable @channel if it is abused). Ask people to keep their chats to relevant channels. e.g. Daily interesting links do not belong in #general, please keep it to #random. Stuff like that.
Also, encourage people to move long complicated topics to a thread (to not annoy everyone in the room). Or ask them to compose a larger email or wiki page on the topic.
There's like 3000 people in there. Sometimes shitloads of conversations are happening at once. The people that refuse to use threads aren't cool, they're just co-opting literally the entire channel for just their conversation.
I see it as a forum, where you browse threads and click into the ones you want to discuss in. I guess other people see it as a bloodless Colosseum, may the loudest win.
If there is already a lively topic ongoing in a room and I need to jump in with another topic, I write a message and say "Hey I have a question, can someone help me?" and then I immediately start a thread with myself so people see that it is a thread and click it to respond rather than just spamming the room.
I have always wanted to try out twistapp and see how it is with their "Thread first" UX mentality.
In my current team that uses Slack, I just made it a policy that all conversations have to be in threads. If they're not I just flip a shit until people give up and make threads again lol. Most people don't care enough to retaliate, so that happened a few times and then everybody got used to the system; this is basically an approximation of Twist now (where the destructive behavior is super easy to commit... sigh)
Things we were looking for:
- Separate work / personal accounts (i.e. not just Skype, Telegram, etc.)
- Decent native apps for macOS, Android and iOS, bonus points for Linux and Windows
- Reliable notifications across those platforms
- Tracking unread messages across platforms (i.e. you get the whole history everywhere, everywhere knows what the last message you read on any device is)
- Some basic niceties like the ability to drop images into a chat and have them show up across all devices
That's it, really. Aside from the last one, that's almost the definition of group chat. It doesn't sound hard. All self-hosted alternatives failed.
Things that couldn't hack it:
- Matrix / riot.im
It seems mostly the Achilles' Heel is apps and reliable notifications. This seems like it shouldn't be that hard, but almost everything fails there. Most platforms couldn't reliably have message show up punctually on all platforms. Sometimes the clients took 15% of a laptop's CPU idling. Often messages just wouldn't show up until you explicitly opened the app on mobile.
So, like I said, now we use Slack. And we're mostly happy. I had to fight the dork impulses to start writing my own version of this and get back to work that mattered.
Hipchat did this amazingly well. There was a strong guarantee that a notification would be delivered - either email or app.
I don't think a lot of others do it well. It seems that everyone is mucking about threads and UI and emojis.
I've had many times where I was looking at a DM room with someone in Hipchat, with the window focused, and it was still sending me emails with every message from them like I was AFK. This is especially common on the mobile apps, both Android and iOS. I'd often be chatting on my phone at lunch, and come back to my computer to find 50-100 emails of every reply I'd gotten in Hipchat.
Its one of the best marketing coups in recent history and I'd love to see more analysis on how it was pulled off.
I parachuted into an org which had a not-great email culture and took up Slack as a replacement. It was amazingly great.
In the early days of Slack we had Office Communicator in Microsoft. But because they thought of themselves as essentially MSN messenger for business they didn't do the things Slack did with their clear vision. Ultimately both apps existed to send text/files/images to people in realtime but Slack communicated a vision of how this should work while the rest just let you figure it out yourself.
At my company, we used to use IRC for internal communication and have since transitioned to Slack. The primary difference I see is that in chat, we see reactions to certain messages, in-line paste snippets, and links that use a slack redirect service.
I don't really see much utility in reactions. In-line paste snippets could just as well be a link I could click on to display the image or document in an external application I launch. And the slack redirect service makes it much harder to search my browser history for the document I was looking for.
I've also noticed that in the browser I use (Firefox), slack will, after a few days of using it in the same tab, become very laggy and non-responsive. This requires me to close the tab and open a new one to free up whatever resources were causing it to slow down so much. This was never a problem in the local application I used for my IRC client.
I'm not very impressed with Slack.
As an early employee of a startup, I remember the day we had to setup the initial infrastructure. For the majority in the room, Slack was an absolute requirement. They didn't wanted to have the ability to chat, they wanted to specifically use Slack, like a badge of honor.
Steward Butterfield pushed private beta invites to his well connected Silicon Valley social media friends, who then imposed it in their startups because “it’s what everyone else is doing, it’s going to revolutionize communication”. Rinse, repeat.
Source: a social media ninja wizard friend of Butterfield worked in the same startup as I did in the private beta days. I found it to be yet another internal chat app at the time, but my CEO drank the kool aid right away.
Before that though yea I didn't get the point.
* You can respond in a delayed manner and not appear rude.
* Complex stuff can be previewed before submission.
* The subject and thread organization adds more fine-grained control than you usually get with Slack channels. The #team-name channel might have discussions on several topics at once, not all of which affect you, and no easy way to filter them. On a message board, it's easy to break out a new thread even if people are subscribed to it by default.
* Slack search is ugly because you come back two months later and have to pull the info out of a tangled discussion with unrelated stuff in the middle.
And part of the hype might be how easy it is to add emojis and have a little fun. It's important, too.
This past year at Inbox Awesome, one of Slack's team leads asked the audience how many there used Slack. Of the 300 or so people there, around 75% raised their hands. Next he asked for a show of hands on how many people felt that Slack made them more productive. Not a single person raised their hand. It's on video at around 17:30 here:
On the day to day level, it crashes even more than Slack, and syncs badly.
The pettiest and weirdest part is it doesn’t signal edited messages. The editing window is super short, but it still feels like being moonlighted when you read something and 2 secs later it’s a different thing.
You cannot edit comments in Hipchat. I can talk about other issues as well but not editing comments is a deal breaker for me.
HipChat works with Pidgin, which doesn't support edits, I imagine you'll see something similar as with the Discord edit feature when you're connected via Pidgin (you get a new message, prefixed with EDIT:).
There was a long thread I didn't follow at all about how that was how it was supposed work.
That's when I switched to Slack.
It often fails to notify of new direct messages, I suspect thinking one device was active when it was received.
• Gchat was effectively deprecated
• AIM is gone
You might be surprised how many companies now use Slack that have NOTHING to do with IT an/or software: everything form PR agencies to manufacturing.
I wouldn't be surprised if half of Slacks user base is now people who were using Gchat or AIM. All the major players who offered free chat basically got out, and Slack was kind of the cheapest cross-platform alternative. Even at the end of it's life million of people still used AIM daily for work, and then it suddenly went kaput.
And with respect, you cannot speak to any culture other than the few you've been a part of. I can say with some authority that this is not a problem at my workplace.
The reason IM has proliferated is precisely because it's instant and usually targeted. Email is a pain in the ass and usually serves as a dumping ground for irrelevant messages. If your culture demands that you treat a fundamentally asynchronous tool as synchronous, that's a problem with your culture, not the tool.
I see it as something similar to the rise of open-spaces. Now there is a backslash against it because people finally realize that it was overhyped and that open-spaces are maybe not always that good.
Regarding emails, I disagree with you. It is still my go-to channel for deep technical discussions on difficult subjects on which you need to reflect. With emails, I have no pressure to respond directly. When I respond, I will write multiple well constructed paragraphs where I explain why I would do this or this technical choice. Emails are archived easily and can be reread and referenced later.
Slack is a dumping ground of irrelevant messages, the opposite of your experience.
I would not hold my breath.
There's one side of it that's less organised then a proper email chain. There's the other side that replaces the physical water-cooler and allows people to join public conversations they'd otherwise not be aware of.
IRC is great and I am using it for 14+ years already. It's stable, fast, efficient and secure with lots of options. I've written a lot of IRC bots in many languages because protocol is so easy and every language have library/bot for IRC that can be easily expanded with your logic/code.
Before there was a cloud and big data, we used IRC for handling distributed services as high availability central orchestration to which many services/servers connected that had IRC bots running on them. We had control over many machines and services from IRC channels, with full authorization/authentication, logging channels, you could run commands on one server or on many same time, you've seen real time error reporting or when node went down.
It worked great and still works great.
I used to run IRC on the server in the screen session, but this is unusable on mobile. And setting up properly was a total PITA.
Slack is great. I don't need to waste time writing bots because all of the tools I use already have simple integrations: GitHub, Box, DropBox, Intercom, etc. Doing all of that within IRC is a pain. For example: responding to an Intercom conversation from within Slack. I can set up Slack for an org in literally minutes. With IRC? Not literally minutes.
Most IRC clients support unicode. Also, I've never had an issue just using an internal pastebin to share code-snippets with other devs. If we needed to work on code together, we would use an application like remote desktop or a shared screen session.
I absolutely cannot see why people still recommend IRC today for work use. It can pretty much only do text for the moment you're online and no we don't have time (money) to hack IRC to meet our needs.
Not inline, but you can share link to the image or send it to other person/persons via DCC directly, that's what you do on IRC.
> Can you rapidly search the history?
Sure, no problems with that, all the channels we use are logged and ready for advanced search.
> Can you customize alerts?
> Does it work reliably on mobile?
Works for us.
> You're debugging something and you want to share a screenshot, inline, how does that work on IRC?
I already answered that.
> Can you start audio or video calls with room participants?
We don't do that on IRC.
If Slack works for you then great, it doesn't do anything for us. We have different workflow than you, which doesn't mean it's worse, it's just different. We don't need integration with dropbox, intercom etc, because we don't use them and we have IRC integration with tools we use already. We host all our tools and infrastructure and we need to control the whole stack.
I didn't said anywhere that new startup should go with IRC (unless you are already familiar with IRC with your team). I've shared my experience and opinion about IRC. We had infrastructure built around IRC already, we have a lot of experience with IRC and whole team knows IRC very well. I know some other teams that use IRC and they don't have any problems either.
You can always paste a link to an image hosting service and launch the viewer as a separate application. I don't really see why viewing the image in the same application as the rest of the text is seen as an advantage. If it's inline, it would eventually disappear from the screen as more messages are posted.
I can use grep on the locally stored log files.
That depends on the client.
The IRC client I have on my Nokia phone works just fine.
Normally, you post a link to an image or pastebin service that shows the problem.
You would have to use a separate application for that. FWIW, I use Slack in Firefox and that feature (at least the last time I tried it), didn't work. I had to install chrome to get it to work.
> image service
Now the data is outside, not an option.
> grep logs
How do you tell a designer to use grep on her iPhone? I can't even figure that out myself.
> use other devices for audio / video
And now what is the point of keeping IRC?
> Now the data is outside, not an option.
The company can easily host it's own image service. The one I work for has had one for over a decade.
>> grep logs
> How do you tell a designer to use grep on her iPhone? I can't even figure that out myself.
How do I get a Slack client on my Nokia N9? Contrived examples can work both ways.
A lot of conversations which happen in a workplace revolve around these tools, and have updates in one place not only save time but also encourage conversations around these updates.
Disclaimer: I work for Flock, an alternative to Slack. We are currently rated as #1 slack alternative on Product Hunt and PC Mag.We have a import tool so that you can import all of your data from HipChat on to Flock.
IRC, MSN Messenger, AIM, and Yahoo Chat were definitely used by both groups. None of them required a lot of resources to run.
This is once again entirely up to the business that deploys it. We use Slack and punish people who use Slack as a project management tool; we have Basecamp for that.
It comes to setting boundaries and consent, which is something en vogue in the 21st century and something I guess a lot of humans didn't get trained on when they were young.
But yes, the thing I hate is the expectation that I'm monitoring it or have notifications firing. Notifications are off all the time. If you need to tell me something important either email me or come and tell me. Slack is not the place for that.
I like Slack as a chat product, but it's very far from a productivity tool. It's often a productivity nightmare that operates to interrupt deep productive creative work.
Slacks API and number of systems with built in integrations blows the competition away.
Sure phpbb is a little clunky but at least I can use it as a knowledgebase.
Newsgroups were far better than phpbb :), and they were more easy to search IME.
I am regularly Cc'd into conversations that have 10 or so people and multiple topics lasting a week.
Search is pretty good too
Anyone can buy a pair of pants. Look beyond the functionality to understand why people do things. It can be social signaling, wanting to be part of a crowd, or dozens of other reasons.
My wife is an architect. She made me see this.
Wait a second... what's the alternative to pants?? :p