Slack Is Buying HipChat from Atlassian | Hacker News Reader

Slack Is Buying HipChat from Atlassian

bloomberg.com

1,006 pointsuptown710 comments

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 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.

> 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?

Mattermost[1], with a clear migration path from Slack, at least.

[1] https://mattermost.com/

We use Slack now, and are looking to migrate to Mattermost (since we run GitLab already).

We don't want to pay the price we'd need to pay to keep Slack, and plus we want to host our own.

We moved from Slack to Mattermost, and Mattermost is garbage. Messages are delivered late (by hours), if ever. You don't get notifications correctly. It takes seconds (more than 10 sometimes) to load a page. Sometimes the page goes blank. Much of our office has reverted to email and phone calls for many things that would have worked fine with Slack.

I'll counter that anecdote with an observation that I have never observed any of those issues. In our deployment Mattermost is reliable and I've never heard any complaints like those from my colleagues. It could be a question of scale; we only have probably 50 or so regular users.

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.

Thanks @JeremyNT! Mattermost team here. May I ask which Mattermost version you're running? Also, what features would you like to see?

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, for one, would like to see normal package upgrade process - atleast for debian-based distros.

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.

edit: typo

We're on 4.10.1, so I think we have most if not all of what you mentioned. Thanks for the great open source product!

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!

I wish the search feature to be more straightforward. It seems to be trying to be smart about searching close matches but it just misses exact matches and when I really have to search some messages I have to search it with SQL in the database. It's not good when I can't tell my members to use the search feature when I know it's unreliable.

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.

Hi @jawilson2, Mattermost team here. Sorry to hear you're having issues, it sounds like websockets haven't been fully installed on your Mattermost instance.

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: https://docs.mattermost.com/install/troubleshooting.html#ple...

Is it okay to rely solely on websockets these days? I was always impressed by pusher.com's commitment to a variety of fallback protocols (and there are three blog posts about it, see https://blog.pusher.com/how-we-built-pusher20-part-1/)

> Is it okay to rely solely on websockets these days?

Not affiliated with anyone here, but I think the answer is yes.

It's supported in all relevant browsers after all. Mattermost works perfectly for us.

It's not a question of browser support, it's a question of infrastructure support. When I was using them years ago, there were a lot of networks which blocked them.

Approx how many users?

And Mattermost's UI team was considerate enough to have a dark theme. Something Slack couldn't be bothered for.

Worth noting that mattermost has made pretty significant improvements around this in the past several months, now that there's a large customer: https://eng.uber.com/uchat/

web/apps have been pretty much completely rewritten too. it's noticeably better, if you haven't used it for a while.

Unfortunately I can't name any names, but I can say that Uber isn't the largest company Mattermost, neither in terms of revenue nor number of employees. I don't know for how long not-Uber has been using it, but at least a bit more than a year now.

the fact that companies like HP builds/sells mattermost deployment/support/... yet internally still relies on lync is a joke (and pain to live with)

They use Mattermost internally, they don't sell it to customers (not sure if you were assuming I was talking about HP or a similar company that just deploys Mattermost for customers).

hp, hpe, dxc.. whatever 'division' is one part of .. then it must be deployed in a small amount of centres as most support teams (of any kind) that I've interacted with were all tied to lync only

Neat. Thanks! I haven't kept up on other-users outside of the uber post, good to hear there are more fish in the ocean :)

For us at Discourse we find Mattermost perfectly acceptable as a chat program.

10 second load times and slow/wrong notifications have not been a problem for us at all.

Some additional observations on Mattermost (currently on 4.0.0.43 of the OS X desktop client)

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?

I run 25+ deployments of mattermost (some free and some enterprise for LDAP support) and don't have those issues on any of my systems. Some features we would love to see arent there, but all the basics work great if your network and configuration is good.

Something seems off in your setup. I've been doing some crazy live database massaging straight from psql and everything has been reflected basically instantly across all Mattermost clients.

We had a similar experience (moved from IRC to Mattermost). We're on Matrix now, running with no problems.

Doing on premise is hard. Office networks have firewalls with not so great configurations. Mobile networks can be incredibly flaky and unless you have geographically distributed servers it's hard to guarantee latency and performance. While building Flock , we faced multiple issues with firewalls which took us a great deal of time to tackle to ensure that notifications work well ( We ditched TCP with TLS and came up with our own protocol similar to Facebook zero which relies on shared secured key for encryption). Cloud based solutions are much easier to set up and much more reliable compared to on premise solutions , which is another reason why Atlassian also created Hipchat cloud and Confluence cloud.

Disclaimer:  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 !

I'm using Mattermost in a small team but a web app that's taking hours to update seems like a problem with your server or network setup unless your team is so large that it was never designed for such load even with serious hardware thrown in.

Enterprise E20 pricing (with the all-important high-availability clustering feature) is unlisted. Yeah, going back to opaque pricing and needing consultants to take care of anything and everything is a real step up /sarcasm

Hiding enterprise pricing is quite common for many SaaS companies.

And yet, Atlassian got as big as they did in large part because of transparent pricing. Because enterprise sales have such a long sales cycle, that transparent pricing gave people inside their enterprises the confidence to push for a product they knew their budget could afford, rather than spend large amounts of internal political capital getting colleagues to rally behind a solution that wasn't affordable for them to begin with. It makes adoption more risky and more difficult.

> And yet, Atlassian got as big as they did in large part because of transparent pricing.

Who knows if that had any influence on their success?

Hmm "everyone" for many "Enterprise" shops the spend on sales team is bigger than on software eng. so one of the reasons Atlassian was always profitable is they didn't have a sales team until they were huge.

This is widely accepted because they did not spend money on an enterprise sales team in their early years, yet saw enterprise adoption.

It is, and when I see that, I almost always move one. First, because if I can't know what the price is, its probably expensive. Second, it usually means one company is getting charged much more than another, and since there is no price, I have no idea if that'll be us.

It's the only way to run a business.

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.

See my response to sparkling. Part of what enabled Atlassian to get as big as they have is transparent pricing. A customer can always negotiate down from a list price, can always negotiate for additional support during setup and migration. But that transparent pricing establishes a price ceiling that drives a lot of internal discussion and decision over which solution gets the first move in terms of reaching out to sales and getting started with an initial proof-of-concept.

The challenge in building Enterprise SaaS is that you don't know what the right price ceiling is or how to differentiate your customers & products. You need to charge enough to have a business and not too much to scare people away.

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.

500K a year on chat is not a very common case

Yes. But one can easily find creative solutions.

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.

> Potential customers would be more than happy to extrapolate from this data

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.

Matrix also has migration paths from Slack, eg https://github.com/lampholder/concorde

edit: also https://github.com/Cadair/skill-matrixslack

The matrix homeserver is... suboptimal. I'm running it for a personal instance (two users), and it's using insane amounts of RAM (4-8 GB) and still managing to lag (even though I gave it 4 cores on a Ryzen 2700X). Forget talking in a matrix.org room, even talking to people on other personal/single user servers isn't fully stable.

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).

Disclosure: i work on Matrix.

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.

Why is you current solution so ressource hungry?

I mean, my 10-active-users off-the-shelf XMPP server (ejabberd) uses about 100MB RAM currently.

a 10 active user Synapse should use about 1GB max, so unsure what’s up with the earlier post. The reason it’s currently so much heavier than XMPP is that resource usage scales with the size of rooms being participated in, not the number of connected users - and we aggressively cache those rooms in RAM. However, 100MB is a much more sensible target and we’re busy optimising to try to shrink things down.

Maybe you want to see the preview of our work in progress? https://nayego.net/ Open Source, real Open Standards, mature technology, decentralised/federated/distributed, and a great UX.

Fit for orgs with external partners, providers, customers, freelances, remote and home office workers...

I might have missed something, but your website doesn't provide much information, and I've been unable to find any elsewhere (only an empty GitHub repository).

edit: btw, the number of comments you've made in this thread to “sell” your solution is… abusive?

> a 10 active user Synapse should use about 1GB max, so unsure what’s up with the earlier post

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.

> What are enterprises supposed to use?

We run Mattermost on-prem. We've been quite happy with it. They have well-defined [1] migration plans for Slack, Hipchat, and others.

[1] https://docs.mattermost.com/administration/migrating.html

"For teams with large amounts of data, the export function has been reported to fail and it may be difficult to reclaim your team’s data. Consider contacting HipChat support to see if a new solution is available."

They're kidding, right? That's a well-defined migration plan?

I don't think its fair to blame them on the failure of the solution you picked before, and nobody else will be able to handle better.

I'm not blaming Mattermost for Atlassian's choices, I'm saying, you can't really try to recruit dissatisfied HipChat customers with promises of a supported migration if you can't help HipChat customers de-facto migrate from their old product to your product.

I read this as HipChat’s own export function having problems handling large amounts of data.

I’m not sure how this is Mattermost’s fault.

I'm not sure what they mean by "export function". Hipchat isn't "an application", it's a bunch of services running on a network of VMs. At the very least, Hipchat includes Elasticsearch and MySQL. Seems odd that they'd rely on any particular Hipchat API when they can rip that data out of the guts of the machine.

I'm sure there's a fair amount of business logic between what's in the database and what's delivered to the presentation layer. Pulling from a database means that the new company has to reverse engineer Hipchat's API implementation.

HipChat internally uses Postgres and Redis, not some proprietary undocumented blob store. While I'm sure that a working applicative export function would make things easier, I don't see why you can't give Mattermost the relevant read-only credentials to those datastores and let Mattermost read directly from the source.

Setup an old faishoned IRC server?

There is also Zulip (https://zulipchat.com)

Or matrix/riot?

Zulip actually seems to tick a lot of boxes for us, I'll see about bringing it in and spinning it up on a box. Thanks for the recommendation!

The threading concept in Zulip works really well. I haven't used it for work, but I would love to.

Happy to help!

Disclaimer: I am not associated with Zulip in any way.

One of the main benefits of Slack (to me, at least) is persistence, which you don't get from IRC.

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.

Persistence can be created the the right proxy/helper and clients

As much as I love IRC, this argument seems to me to not be that different from the "just use rsync/ftp" Dropbox argument. There is this IRCv3 extension proposal, though: https://github.com/ircv3/ircv3-specifications/pull/292

I agree. I think it's just normal, human self-centeredness. Because it's easy to them it's easy. I work with 95% non-technical people. They aren't going to tackle the problem of IRC persistence on mobile devices when they can just use Slack. :)

This is a common refrain of IRC users who don't know what it's like to have real, convenient persistence that works for everyone.

Nobody has made persistent IRC channels that are as usable as newer chat products that don't try to be IRC.

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/

A web-based client is not going to provide adequate persistence on a smartphone.

Lounge works fine on a smartphone because the actual IRC connection would be handled by a server where you host it, not your own phone.

Do you get notifications when you are mentioned on your phone though?

If your browser supports web push spec, yes!

> Persistence can be created the the right proxy/helper and clients

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.

Years ago, my company used an internally hosted XMPP server. When you joined a group chat from another client, it would replay messages that were sent while you weren't connected (or possibly some fixed time period of messages).

That is the MUC room lastest messages logs. When you disconnect+reconnect fast you have them all the time.

With Nayego, we are working on that. https://nayego.net/ you can subscribe if you want to see the preview.

Protocol is way too outdated. Sharing files is already difficult.

I've seen a few companies with their own Mastodon (or compatible software) instances. They can post local-only for internal stuff or just not connect it to the fediverse at all. MIT even has its own.

No support, no integrations with various other parts of an enterprise stack, no channels or other ways of grouping relavant material with each other. Social networking is not organized / enterprise communications.

It will be some time before the ActivityPub ecosystem is ready for the enterprise. I was putting it out there for companies that don't need that level of integration or have people who can build it.

Would Keybase Teams fit the bill, with end to end encryption? Or has to be on-prem, even if encrypted, for your requirements?

(I don't have any association with Keybase, I've just investigated this product as a Slack alternative.)

Has to be on-prem if the networks are air-gapped. KB Teams also has a long way to go to meet feature-parity - channels, integrations, etc.

We use Keybase for work chat. It's quite good, and the file sharing options make it even better--you get a synthetic filesystem mounted under /keybase, so you can share a file to the whole team by copying it to /keybase/team/TeamName/, or share it with just one person by copying to /keybase/private/<you>,<them>/

For on-prem, why not use a free and enterprise-quality XMPP server, like Openfire[1]?

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[2].

[1] https://www.igniterealtime.org/projects/openfire/

[2] https://www.igniterealtime.org/index.jsp

The client-side story of XMPP is pretty bleak, especially if you're trying to get non-technical people to use it.

This is why we need specific services (like Slack or HipChat) that are XMPP but maintain their own ecosystem, clients, specific feature sets, etc. Then if you want to use third party clients (eg. for better accessibility, or because your platform isn't supported officially, etc.) you can, but if not you can use their clients. HipChat was almost this way (I used Mcabber with it extensively), but had just enough bits of the protocol that ignored the XMPP spec or were only accessible through a second non-XMPP channel that it was a bit annoying.

It's a real shame that the industry has forsaken the protocol in favor of walled gardens.

We'll be trying to fix that by offering the XMPP "Team Chat" client that is much needed... https://nayego.net/ you can subscribe if you want to see the preview.

The reason is open protocols soon become the single biggest blocker to innovation. Open protocols stagnate and ossify. So some competitor with a proprietary system will come along and eat your lunch. That's why there have only been 2 changes in email clients ever - the move from terminal to desktop GUI and desktop GUI to web 2.0 client. That's why XMPP and IRC clients will never compete with slack (queue the 'what does slack have that IRC doesn't have thread').

I don't think it's as much that the protocol stagnates as much as it is that companies have a strong incentive to get users into their walled garden. If you use an open protocol, you can't lock people in.

No good web front ends?

Already tried Movim :) https://movim.eu/ ? It's a fully-featured web-based XMPP client. It integrates all the modern XMPP features (message editing, history management, file-sharing, video-conferencing, publications…), it's responsive and easy to use and deploy on a self-hosted instance.

Btw. I just saw that movin is advertising 'Conversations' (Android) and 'Dino' (Desktop) as alternative clients. While I use Conversations every day and can recommend it too, on the desktop side I would recommend Gajim instead.

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 ;-)

We are trying to fix the shameful situation: https://nayego.net/ you can subscribe if you want to see the preview, but it's work in progress.

Suggestion: Have a tour of the product that doesn't require a signup. If I don't want to give you my email address, I'm left to use my imagination based on your description.

Servers seem solid and there's also ejabberd but what about clients? I want clients that are stable, cross platform and does push notification and last time I checked, there were none.

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.

Skype for Business, works on prem. Matrix is probably good too. Confluence can be installed on prem already.

S4B works with our VoIP infrastructure and is on-premise but the client is awfully slowly and badly needs to be reworked. But with Microsoft is abandoning on-premise services...

It's so slow and buggy that sometimes it registers clicks I do on the chat window as if I did them on the contact search one and end up sending that funny meme to a multichat I created with 30 I don't know instead of the contact/tab I selected.

SfB is ok for one-to-one or one-to-few communication, but the chats are pure garbage.

I consider Skype to be a dead product at this point.

We might have to revert to talking. Aahhhhh!

Or - yikes - doing work, instead of just communicating about work.

I can't tell if you're being serious or not, but for a lot of distributed companies, it just isn't realistic for people to get on the phone every time they need to talk to one another.

Wasn't too serious

But ...

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.

welcome to 2018

Hi @solatic, Mattermost CEO here. If you have an on-prem HipChat deployment you want to migrate our team would love to discuss the possibilities.

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.

Gotta say, I love that the CEO is commenting here.

There is an export option for HipChat so if you could write an importer for that the migration would probably be straight forward. We also have customers who insist on having control over their data so we are looking into mattermost as well.

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.

HipChat is known for having a problematic low-level protocol (based on a fork of XMPP), it's featureset is much more limited than Slack's, and it's implemented in a different programming language.

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.

Or they could just leave it as is or rebrand it as Slack enterprise until they build a new version based on Slack.

the UI/UX is so different I'd be very surprised if they managed that

See SKYPE for Business. replace('Lync', 'Skype') probably...

Oh Mircosfot's strategy is the weirdest: OCS, Lync, Skype, Skype for Business, Teams, Yammer... People are just lost.

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.

https://developer.atlassian.com/blog/2018/07/atlassian-slack...

> 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.

(I lead the Zulip project, one of the main open source alternatives to Slack.)

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.

To be fair, there are tons of very low severity vulnerabilities disclosed on HackerOne and this does not mean the application is vulnerable. Slack is definetly not vulnerable because it is written in php and you can pollute an iframe on their career website. Having such a program in place is actually good for the application security as it does get audited by tons of hackers thanks to the monetary rewards.

I agree it's theoretically possible to write a secure project in PHP, but it's very difficult, especially if you're hiring people like crazy.

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)

It is not about the language is it... I don't think there is so big difference between php and python. Besides Slack is most probably using whole lot more tech than php.

It is about Zullip being open source.

It's also about the language. See, for example,

https://www.quora.com/Why-is-PHP-hated-by-so-many-developers

That is from 2014. There have been many changes in the programming language since.

Most people nowadays are using frameworks and abstraction layers which make most of these points moot.

If you use a framework like Laravel it probably covers most things.

You could easily write a massively insecure application in core python, but things like Zulip use Django which shields you from most of it.

At this point I don’t think any company should be relying on on-prem solutions remaining on-prem which aren’t open source. There’s too much to be gained from a cloud + SaaS business model. If you want to be either on prem or just avoid cloud lock in, open source is the way to go. The user just has much more power in the context of OSS than they do proprietary software.

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.

Your first point sort of misses the idea that multi-tenant SaaS applications could and have shut down their service overnight (see Smyte https://news.ycombinator.com/item?id=17371074). At least with HipChat On-prem the customers who are running that version can migrate on their schedule instead of just having the service turned off.

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.

Wickr Enterprise should be a pretty good option. It's basically a team oriented and somewhat less open source Signal competitor. It can be deployed on-prem.

My team is happy to welcome all HipChat users to the Wickr Pro platform. The good news is that we already have a lot of customers who migrate from Slack and HipChat to Wickr when they need to have security and compliance. Users find that unlike on Slack or elsewhere, that their collaboration flows are end-to-end encrypted so no 3rd party including Wickr has access to your team data.

Mattermost CEO here. We're thinking of offering a special package for HipChat customers who want to stay on-prem using Mattermost.

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

Hi,

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?

Higher conversion rate? This is a simple, age-old trick that eliminates most of the low-effort spambots (read: most of them, as there's enough money made there), while letting through any human that is smarter than an amoeba.

Hey, I sent you guys an email - looking forward to hearing from you

Thanks! Got the mail and responded, looking forward to discussing more.

Yes, I'd be interested. We're evaluating Slack, MS Teams and Mattermost as a successor to Hipchat.

Something to move the needle commercially in favour of on-premise would be helpful in that evaluation.

You will be soon able to evaluate Nayego as well: https://nayego.net/ you can subscribe if you want to see the preview.

Nayego is an open source and open standard team chat, that is federated/distributed/decentralised.

Where's the source? nayego.net doesn't have any links.

I'm pretty sure it's spam.

I found a link, but it only has a README

https://github.com/Nayego/Nayego-client

Not sure about good on prem products, but if you want to broaden the scope - there are a couple of others including Glip, Flock, and Twist which I have come across in some reviews, including the PC Mag reviews. Have tried out Flock and Twist, specifically- you might want to add these to your consideration set

Hey there, we are using mattermost as self-hosted chat infrastructure. I personally like the software, even if some of my colleagues don't agree with me here. Whatever you do in the future, I really hope you don't pull an - potentially incompatibility introducing - acquisition like this one. It is very frustrating to have a piece of infrastructure working just to realize one year later, that you will have to migrate again...

Impeccable timing.

FYI, we've posted the idea of a HipChat migration package to Mattermost on Medium to hear more feedback: https://medium.com/@mattermost/migrating-end-of-life-hipchat...

We did this at my company; we already had self hosted free GitLab. We tied it into our AD and went happily without Hipchat about a year ago. Some things are rougher (image support) but it was mostly smooth and equivalent, and actually nicer in that it supported Markdown.

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.

> We tied it into our AD

sorry if it's obvious but do you mean Active Directory?

98% likely that they do.

Yes, I do. Sorry for the abbreviation. We used the LDAP connector that is publicly available in GitLab and then tied Mattermost into GitLab authentication.

I recently installed Mattermost open source, but will likely move to something else. This is a trial for me, but the lack of google authentication in the free version, and particularly that it is only available on the enterprise version with opaque pricing, which will likely be unaffordable for me at this point, is pretty much a deal breaker.

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.

I’ll add my own voice: I’ve been pretty happy with Mattermost (for both business & personal uses). It’s a bit tricky to set up initially, but once it’s set up it Just Works™ — and that’s the most important thing for a piece of software in my opinion.

It seems to get better every few months, which is nice. Doesn’t feel like it’s sitting on its laurels.

Hey I tried looking into setting up webhooks (inbound and outbound) on Mattermost (we are running our own instance) but your technical documentation is quite spread out and thin. If you could improve that I'd be super grateful!

We recently launched https://developers.mattermost.com/ to make it easier to find developer documentation. If there's anything you want for docs that isn't there, let us know on GitHub and we'll help find it.

Zulip CEO also here. For folks migrating from HipChat, we've decided to match the current price you're paying for HipChat for Zulip enterprise support (and we'll also provide a high-quality migration path similar to what we have for Slack and Gitter).

See https://news.ycombinator.com/item?id=17622987 (also on HN today) to learn more about how Zulip, or contact support@zulipchat.com if you're interested in our offer.

Certainly interest in a migration path from HipChat to other on-prem solutions.

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...

This shows one strength of open source where you have the option to fork and maintain your own solution in the case the project heads the wrong way.

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.

Forking and managing has a cost associated with it too. If your own DC burns down you also have nothing. There is no "wrong way" just a different ways to evaluate risks-benefits and choosing whatever works best for your case.

100% this. As soon as you fork a project, you are now responsible for the evolution of it (even if that's just merging in upstream changes). It puts a large burden on engineering teams to track changes and maintain the fork.

OpenOffice is dead but its fork, LibreOffice, lives on.

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.

Because business world discovered it was the only way to actually make money with open source, either by selling hardware or services.

Microsoft Teams has on-prem support.

source?

On premise is apparently not big enough as a market for Atlassian. This does not surprise me: it needs a lot of hand holding; and saas gets you revenue much cheaper because you get economies of scale and much less support headaches. On top of that people get stuck on old versions of your product, which you then need to support as well because they payed you a premium for it. With SAAS you just have one version to worry about: the current one. So I don't expect Slack will be very eager to do on premise installations any time soon. The whole point of Slack is not doing that. In the same way, on site salesforce installations are not a thing, or on site Google docs. Even MS is moving away from on premise with office 365. Seat based, annual license revenue is a nice thing too for them.

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.

> 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.

They also become much more attractive targets for APT since compromising say Slack is way more interesting than some avg. mid size shop.

It depends on what an attacker is after.

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.

Depends if APT is say FSB or MSS Slack is very attractive target. But in general you are prob. right.

Yeah but this goes both ways; Slack and Microsoft know they're huge targets, and have competetent detection and mitigation in place to deal with intrusions. Of course that doesn't mean a breach won't happen, but it's not like APT casts the "hack" spell and suddenly all your PII is out in the open, you have to fuck up somewhere and not notice for a period of time.

I think you're right in general, but it's also worth noting that on-premise software stacks are still very attractive targets; companies may be running old versions with vulnerabilities, so attacks are both easier and can continue for longer--one site patched the vuln? On to the next one; just move down the "customers that use us" list on the provider's sales page.

On premise deployed stacks are usually shielded off by network firewalls though, which cannot be said about most cloud based services (yes, I get it from a convenience point of view).

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.

Agree with this. On premise doesn't seem to be an attractive value proposition for most vendors. Most of them seem to be moving away from that model. Even customer requests around this seem to have reduced. We used to get a lot of requests around on premise in the initial conferences where we pitched our Flock messaging product, but that number has been steadily decreasing over a period of time

> Compliance issues can be addressed in the cloud as well.

How can I guarantee the security of my customers data, if it's not hosted on equipment I control?

You can't 100% guarantee anyway. But you can pay your cloud vendor to do that for you, with the right legal contacts. Should work out cheaper due to economies of scale.

On-prem isn't the problem, building a crappy product is the problem. Atlassian's other products (Jira etc) over 50% of the revenue comes from on-prem customers. Same is true for GitHub: https://medium.com/@moritzplassnig/github-is-doing-much-bett.... It just turns out that offering an on-prem version is not enough to close the gap created by all of the other features, integrations and UX that their competitor had. On-prem is a great feature, but it isn't a silver bullet. Nothing is.

> Slack doesn't have an on-prem option.

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.

The customers of these on-prem options are themselves developers, what's stopping them from forming a consortium and building a free software alternative themselves?

It should be simple enough, since you're operating on a negligible scale when it's on premise.

I went to their city tour in Austin Texas and they said they where going to fully integrate Jenkins with Bitbuket and Jira. I suspect Bamboo is in trouble. I kept asking where their Hipchat under red hat image was with no answer. At the meet in great I was told by Hipchat Engineer to look for an another solution! I wonder if they new then?

> 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?

Ahem:

    Bond: You expect me to [use RocketChat or Matrix]?

    Atlassian: No, Mr. Bond; I expect you to die.

If Atlassian are killing this "wing" of their HipChat business, it must have not been a very large money-maker for them. The market for this kind of product is dying, in other words. Along with the companies who refuse to re-evaluate the threat-surface of moving their communications to the cloud.

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?

The company who insist the on-premises relies on proprietary software? What are they thinking?

Slack might not have an on-prem option now but if they are buying HipChat they will have one soon. Yes it is possible they will remove it but they may go the other way and make some parts of slack available to on-prem as the two products merge.

> as the two products merge.

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.

On the other hand, could this be a signal that slack might be considering offering on prem ?

Obv IRC bro

(bring on the downvotes. What's karma for if you don't spend it sometimes??)

The reason Slack is buying HipChat if you were to ask me, is to take over the on-prem market for chat apps - given that they're loosing money by not going after this market. When looked at it from that perspective, the purchase makes perfect sense.

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.

Hi, I am Watcha CEO. Watcha may be an alternative to check: our solution is based on Matrix and thus can be deployed anywhere.

Our added value: UI and specific functions, simple user onboarding, upgrade management...

xavier@watcha.fr or visit https://watcha.im

Wickr CEO here as well.

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.

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 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.

A few months ago slack's early plan was posted here. From day one this was the goal - they knew it was just a chat app so they had to make it feel like something different.

Its one of the best marketing coups in recent history and I'd love to see more analysis on how it was pulled off.

It also see it as a hugely successful marketing coup.

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.

I was involved in the early days of IRC, and personally, I'm amazed at how great Slack is.

I parachuted into an org which had a not-great email culture and took up Slack as a replacement. It was amazingly great.

I wish I could find the original document. They do spend about 1/8th talking about how it has to be a great experience. But the majority of the document discusses how they aren't a chat app, they had a broader vision of team communication. And so you don't compare Slack to IRC because IRC is "just" a chat app while Slack is for "collaboration".

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.

Not sure, but perhaps you are referencing the article from Stewart Butterfield, We Don’t Sell Saddles Here: https://medium.com/@stewart/we-dont-sell-saddles-here-4c5952...

Yes! Thank you.

> I was involved in the early days of IRC, and personally, I'm amazed at how great Slack is.

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.

> Its one of the best marketing coups in recent history and I'd love to see more analysis on how it was pulled off

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.

To be fair, it now has actual useful zero setup functionality like screen sharing and file sharing.

Before that though yea I didn't get the point.

I think it's far less about marketing and more about lowering the barrier to entry. I work at a real estate company. They were using Slack before I got here and did not have a single technical person on staff. This company would have never considered IRC if Slack didn't exist.

"Always on", except when they are down, which has been a monthly occurrence lately...

None of the problems you mentioned are unique to any particular messaging product, up to and including IRC and Jabber.

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 would agree with you, except that Slack promotes actively that culture of quick response and disruption. And I indeed blame that most work cultures took that in blindly without reflecting on what the impact would be.

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.

Slight aside: I think one of the big problems in the IRC and XMPP communities is that we discuss them as if the protocol itself or the public federated network (in the case of Jabber) were a "messaging product", but it's really not. Someone could (and should) build a messaging product with XMPP or IRC. HipChat started out that way a bit, but then tacked on more and more proprietary bits, or abused the XMPP protocol in its own clients enough that it could hardly be called XMPP anymore, which was a real shame.

There are two camps: the we-should-just-use-irc camp, and the we-need-every-feature camp. You fall in to the former, and I would bet that a lot of people here fall in to the former.

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.

> There are two camps: the we-should-just-use-irc camp, and the we-need-every-feature camp.

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.

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"?

Where did I imply that? There are tons of options for business chat. My point was only that email isn't even in the running.

If you want secure emails use GPG. Unlike slack, GPG is both open-source and offers government-level security. I don't think slack is more secure than GPG.

And how does that work for your average person using outlook / google for email?

Then build on top of email, instead of developing yet another 'secure' proprietary system.

If that were viable people would already be doing it. It's not, and so very few people are. I wish this weren't the case but it is.

Companies are generally at more risk from failure to produce message content in a lawsuit, regulatory action, HR investigation, etc. than from eavesdropping. "Secure" in a corporate setting means subject to IT's surveillance, filtering, and archiving. If anything, security's job is to make sure employees aren't using things like PGP, personal webmail, Facebook, etc. to evade corporate retention policies.

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.

I'm talking about personal e-mail. Still businesses can easily enforce retention policies with PGP by using a master key.

The security model for internal email on a corporate email server is pretty similar to a corporate slack instance.

I've never seen any email system used securely. Even smart people will send sensitive info to a personal address instead of corporate, for example. Email wasn't purpose-built for controlled internal comms.

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.

That's a little too harsh. Not everyone is good at expressing themselves through an email chain; doesn't mean they're illiterate though.

It's very much a learned skill. I was fortunate to learn it well in school (and polish it further in my professional life). People who haven't learned to express themselves clearly and concisely are indeed to the left of me in the spectrum of literacy.

But again, it can be learned by everyone, it just takes time and effort.

Not everyone is good at expressing themselves in a real time conversation, either. Any medium of conversation excludes people who aren't good at that medium.

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.

That's kind of a false dichotomy you've got going there. Introverts and non native speakers are all slow deep thinkers who need a thinkers medium to communicate, which is slow by your definition. Everyone using a quick communication medium is a moron though right? I assume that's what you meant by people who lack intellectual ability.

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

It’s not a false dichotomy because it’s not a dichotomy: I’ve mentioned that I myself can communicate effectively either way. A lot of people can.

Email is crap for many types of workflows that Slack excels in.

It’s too bad most of those workflows don’t apply to business use cases.

Is it a chat client? A knowledge base? A conference call? A command line? Who knows!

> It’s too bad most of those workflows don’t apply to business use cases.

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.

Businesses pay for a lot of stuff that doesn't work. Simply saying everyone else is doing it is not necessarily convincing.

I'm curious as to how that breaks down? Which kind of workflows are best in email, which in Slack?

_This_ is the 64 thousand dollar question that no one seems to have a clear answer to, and leaves people frustrated with both email and slack.

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!!

Featured specifications work better in email, live debugging/forensics work better in Slack.

Featured specifications work better in source control...

You can have both with git format-patch/git send-email and git am :)

Email is crap because there is no agreed on way to structure old and new content, quotes, references and links, everyone insists on bloating with html signatures and crap that isn't part of the discussion.

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.

There's way too much noise in my email inbox, stuff gets lost.

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...)

> There's way too much noise in my email inbox, stuff gets lost.

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...)

Email can also create bottlenecks and unneeded silos of information...

Sorry to get triggered but oh my god I dislike those buzzwords. I find those two come up any time attempts are made to delineate responsibilities or make it possible for teams to run in parallel (by saying "you work on this area of speciality, I'll work on that" i.e. "silos").

Ehhh, you kinda mixing problems here.

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 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.

Your suggestions may work inside a company. E-mail is the only federated system we've left. If you need to contact somebody outside it, you're screwed. XMPP/Jabber could have solved some of this, but it's pretty dead right now.

The org I work for has a bunch of Slack channels that we invite our clients into as single channel guests (If they don't already use Slack). We have Gov & corporate using it without issue and they love it.

I generally agree with greg, and that covers 90% of the cases, for the times where Email is used with external entities, it usually gets dumped into issue tracking / wiki

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.

I think if you ask Slack about that they'll happily tell you about Slack Grid.

EDIT: Whoops actually Shared Channels is the feature I was thinking of: https://slackhq.com/introducing-shared-channels-where-you-ca...

"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 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.

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.

One thing to think about with respect to memes and videos is they may evolve to be more dense in their ability to symbolize and convey a much larger amount of information.

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

I don't disagree with not being productive 100% of the time. My gripe is that for many non-tech people, their computer time is majority memes and videos. The ratio is all wrong, IMO. This incorrect ratio has created the click-bait internet and other scorns of the modern internet IMO as corporations are catering to the masses.

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.

Goofing off via chat has been a thing since IRC, and you don’t really need much above and beyond IRC to goof off. And if tech companies treated Slack as belonging to the same class as ping pong tables and kegerators, that would be highly appropriate. But they treat Slack like it’s a serious business communication tool.

Its superficial to suppose the immediacy of slack is its only feature.

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.

Outlook may very well be shit, but that’s largely because business/enterprise email products are optimized for the same PowerPoint-addled minds that Slack is. Rich text is where email first started to go wrong.

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.

One of my biggest frustrations with e-mail as long-form discussion like this is misunderstanding points. Someone will write paragraphs of text arguing their position, but they made a bad assumption or missed something simple at the start that either partly or completely invalidates the rest of what they are saying. Depending on if people realize this or not, it's easy to slip into a kind of bike-shedding discussion arguing about the incorrect details. I've been on both sides of this, and it's one of the reasons I dislike e-mail for it.

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 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 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.

I'm in the same camp. In my company there is so much knowledge hidden in inboxes that should be available and searchable by everybody instead. I ask my colleague and be forwards me an email thread from three months ago where I was not included. This is inefficient.

> 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).

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.

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.'

Email: Two use cases.

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.

> 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.

Isn’t that what subject lines and mail archives are useful for?

What's the mail archive that can be set up with the same ease of use and permissions as slack? What, are you going to say hypermail?

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.

> 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.

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.

Our product https://www.fwdeveryone.com does almost all of what you’re looking for, and will do everything within a few months. (We still need to add live updating threads, and we’re also working on an add-on so you can upload content directly from gmail.)

I like it, and that solves an interesting use case. I'd say there's a use case of assumed-private email and assumed-public email, and you're trying to solve both at the same time. What I'd want is basically this combined with a mailing list system where mailing lists could be made and ended quickly - like a slack channel, that ties to this.

I hope you all do well with this!

> With email, how can I subscribe to conversations I'm interested in?

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.

Are there any resources on deploying your own internal NNTP service

The standard software package is called INN ( https://www.eyrie.org/~eagle/software/inn/). It should come pre-packaged in upstream repositories for various linux distributions.

> the illiterates took over and that was the end of that.

That's pretty arrogant. Perhaps people have different communication styles than you. Not better, not worse... just different.

What word would you use for people who are incapable of communicating through the written word? Or for an Internet that is increasingly designed to cater to such people?

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.

> I'm firmly in the "email should be used for substantive discussions" camp

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 never had a chance to get into newsgroups that much, but I believe you.

> the illiterates took over and that was the end of that.

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.

Email has unfortunately become "I don't check it or care anymore"

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.

The different in the Linux/OSX comparison is that Linux is constantly improving. IRC hasn’t changed much in years.

> IRC hasn’t changed much in years.

https://ircv3.net/

It's changing a lot for some time now.

A set of RFCs isn't really in the same ballpark of the same planet of the same local galactic group as a mature product that I can go sign up for and be using in under a minute.

Maybe in a few years. I say maybe, because XMPP is an IETF RFC, and frankly, it sucks.

What do you not like about the protocol? Like everything, it has its warts, but having worked on a few more-or-less proprietary protocols XMPP is much better designed and thought out than most of them. The community has had a lot of time to address some of its flaws whereas Slack, Stride, et al. tend to reinvent the same problems XMPP solved 20 years ago.

Let me just start by saying that I'm a big fan of XMPP. I run my own server, and talked to my friends exclusively through XMPP until that fateful day that Google turned off federation support for Gmail chat, and I lost contact with a bunch of friends. I still run my own server, though I don't use it nearly as much as I used to.

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.

I'm going to be pedantic here, but I think it's important to be precise: this is a problem with the public/federated XMPP network (let's call the network "Jabber", since some people use the term that way), not with XMPP (which is a network protocol that could be used by any number of services). That is to say, XMPP==HTTP, Slack==google.com.

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

I thought about this too. My idea was to introduce some sort of version badges, like 'This client supports feature set 2018'. Every 2 to 3 years there should be new definition of which XEPs a client should support in order to be allowed to be called 'Supports feature set xxxx'.

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?).

It's amazing - I've used IRC before but every feature is an indecipherable mess based on what it offers me as a user.

https://ircv3.net/irc/

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.

IRCv3 has some great features it’s trying to standardize: https://ircv3.net

Mean while, every single chat and IM application has steamrolled straight past.

I think ‘steamrolled’ is a little strong. Slack is more or less a pretty design on otherwise old concepts and ideas. Not to trivialize that: it was despirately needed.

Really IRC just needs some well designed clients, I don’t like any of the offerings I’ve seen for iOS or desktop.

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.

I don't see any compelling reason to adopt Slack. It does nothing that I care about that IRC doesn't do. If IRC completely implodes, I would run my own IRC server.

> I would run my own IRC server

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 horrible on phones (shitty history when you drop out of an internet connection, no cross-device unread-count synchronization, no encryption or login, etc). There are add-ons that try to fix that, but it's still a giant pain.

I personally love Riot and Matrix as a "modern IRC".

The Lounge is an IRC client that solves the problems you describe (persistence on any device, synchronised unread counters, push notifications) - https://github.com/thelounge/thelounge

It does require having your own server to host it on though.

Hadn't seen this before. Looks nice. I tried the demo, smooth other than the /j is not an alias for /join, which I think is an obvious oversight.

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... )

Slack isn't perfect; I agree with that. I haven't experienced the CPU issue, but it does seem to like RAM quite a bit. I just opened it w/ one account active, and it was eating maybe 400MB of RAM. I bumped that up to 6 open accounts, and now it's chewing up maybe 2GB of RAM.

I'm quite fond of emacs-slack, which is a much better client experience than the Slack 'web' UI.

> pin a core of my cpu at 100% and consume half a gig of ram...

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.

200M/2% is still pretty bad, isn't it? IRC clients worked perfectly on machines with less total virtual memory 20 years ago (and before).

    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

I hear you! I've been using the Internet most every day since 1988, and am still occasionally struck by the amount of resources seemingly straightforward programs use these days.

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 had this problem with Slack. I switched to using it within Chrome. I can't be sure why it performs so much better that way (Chrome throttling it?), but it does.

If I had an irc server/service were I could easily login/control access with a Google domain account... <3

I like this approach very much.

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.

It seems he is in a different camp, specifically the one where you aren't on a chat application all day

You're in the mute-everything-non-critical class, which is a good practice regardless of the client. If they really need you, they'll ring/call/DM. Otherwise, you can check it whenever you're ready.

I think you're confusing communication throughput with latency.

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.

I have a different expectation while using Slack. I agree that enough people have your expectation that it's something that should be discussed and agreed upon by everyone using the 'chat' system... Slack provides an easy @channel and @everyone mechanism to control notifications.

I completely agree. It is also the effort to interruption ratio that has reached a tipping point. Once upon a time if I wanted someone's help right now i would have to walk to the actual desk, and bribe them with caffeine or chocolate. If the effort of levering myself out of my chair was greater than the benefit to me I stayed put - hence interrupting another person had a minimum price point - the other person may not like it but the price was paid in public and there was a perceived value to the business.

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

I find clients tend to call to ask "a quick question", this is very disruptive. My experience is if they can't be bothered putting it in writing, then it's probably not very important.

Have you considered that just might be your own psychological burden though? I mean, plenty of people I know respond to slack messages a few hours after the fact, and I myself don't feel super guilty for turning it off for a few hours, and nobody seems to care.

I have never expected that the other party is sitting and staring at the screen in any Slack or chat I’ve used. An @mention will change the expectation of interrupting or not, but as someone who has used various chat programs for 24 years of my life, this ha never been an expectation I’ve had, nor one I’ve seen too frequently expressed.

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.

I've used Slack when contracting at companies (remote and sat in the same room)

> 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.

> I have never expected that the other party is sitting and staring at the screen in any Slack or chat I’ve used.

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.

I do that but it's not the same as not having a chat I'm expected to be checking.

> Otherwise, you can check it whenever you're ready.

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..

Not directly relevant, but it's possible OP is a girl, so not necessarily "he".

It’s possible I’m a fish person, but not likely. And this adds nothing to the discussion.

When was the last time you used Linux? I installed Ubuntu on a Dell lappy provided by work, everything just worked and it required less tweaking than osx would have for serious SWE work.

I heard the same luring song for the last 20 or so years. If Linux works for you then enjoy it. Don’t even try to suggest that Linux is easier than Mac OS X because I don’t like liars.

it's easier for development. os x sucks, I use it to surf the web on my ouch. my real dev machine is in my office with linux

It "sucks", really? You don't think that might be a bit of an overstatement?

You may not prefer it, but it objectively does not "suck".

I'm in the camp that Slack is a great UI for work chat, and that work chat is for low latency, low bandwidth communication.

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.

I would agree with most of what you said except for the point about Linux and OSX. Yes, it used to be like that some 10+ years ago, but not anymore. However I can still find this myth repeated here and there nowadays. These days Linux works out of the box, with no more tweaking or settings up than what is required for OSX.

Hipchat actually outperformed Slack for my team in every respect, with three exceptions (all of which were supposed to be solved by Stride):

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).

You and I have had very different experiences with Hipchat. The search is terrible, the integrations are worse, the mobile app hardly ever sends me notifications when it should, there's almost no customizability, the native app randomly drops messages. For me, Slack isn't hype, it's simply a better product.

The lack of Slack on-prem over HipChat is a deal killer for major Enterprise. You can justify "cloud" when Microsoft is running it and has millions of dollars to put into feasibility and security studies and audits.

Letting a strappy upstart have access to that data is a completely different story.

This point is spot on, but often overlooked.

Disclosure: I work with Flock, a messaging product.

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 :)

You write and borrow plug-ins for Slack. With plug-ins, Slack becomes an extensible, configurable, fine-grained company alerts system. You adapt it to alert you about your latest website traffic, analytics goals, customer support requests, and bug tickets to triage.

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.

What you've described is just as applicable to nearly every other popular communications platform whether it's Slack, IRC, Skype, Twitter or even email.

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?)

It depends on the company model. If everyone works in the same place, is probably not that useful. If you're partially/fully remote, something like Slack is pretty much necessary. It really changes the way you experience other people.

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.

We use HipChat. It’s terrible, and it has been a frequent comment that having Slack would help us build better communication culture, because people avoid using hipchat (and use Skype or other platforms instead).

I don't think I've ever used HipChat. What don't you guys like about it?

Sync. I have three computers and an iPhone. If I check a message on one device, it still shows unread on the other devices. It's total crap.

That’s the best case.

It often fails to notify of new direct messages, I suspect thinking one device was active when it was received.

I actually raised a ticket for this.

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.

To be fair Slack doesn't do this and other network related things much better (in my experience). For each complaint here about HipChat I experience the same failings in Slack, just less often. But Slack is a bit better, so people make the argument that it adds up. (We moved from HipChat to Slack several month sago, I didn't find it much of a game changer apart from getting the company to pay Slack to store history and make it searchable but I'm someone who would be content with IRC and searching local logs.)

I worked at a place where employees lobbied for Slack endlessly until we got rid of HipChat because -- and I am being completely serious here -- you can't upload as many custom smilies in HipChat.

That was one concern we had where I work, but Slack does many things better—not just unlimited custom emoji.

On the other hand you have to manually resize things for Slack, whereas Hipchat would autoscale and let you crop too. So annoying.~

On the basic level, it doesn’t have as many integrations as slack. It’s mostly important for obscure services, as they often won’t be integrating thousands of chat apps, so they’ll choose Slack.

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.

Gaslighted. Moonlighting is a different thing.

In addition to many general software issues (it crashes a decent amount), it's not particularly easy to send images or documents over it (where as with slack I can take a screen shot of a dashboard and post exactly what I am referring too).

HipChat (At least for me on Windows) absolutely messes up any SQL I try to send to someone. It's unusable because HipChat apparently adds characters to the beginning of each line. At this point I just email the SQL, but I really shouldn't have to for quick and dirty queries.

It's pretty terrible at handling any kind of networking failure (or whatever else causes it to have trouble getting a message delivered). Sometimes the UI will make something appear to have been sent, and quite some time later it gets marked as unsent. There's no explicit option to quit trying, or retry. Sometimes that message eventually disappears, and sometimes the recipient will then receive numerous identical copies of the message without me taking any action. This seems to be typical among users at other companies I talk to as well. This also seems to happen a lot more than I would expect, given that Internet connections are pretty reliable these days.

> What don't you guys like about it?

You cannot edit comments in Hipchat. I can talk about other issues as well but not editing comments is a deal breaker for me.

Sure you can, though I stumbled on it. Type s/sub/repl and it edits.

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:).

Nah, it just shows the regex as typed. So not much of a different experience from traditional irc!

The client freezes and crashes frequently, and messages routinely fail to deliver, with less than 20,000 people in an organization.

Going through all of your channels you don't need immediate updates from and doing /mute will go a long way to getting the silence you want. People can still @mention you to get your attention if needed. You can check muted channels on your own time when you feel like it. You should also set up Do not Disturb and turn off the red notification dots.

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.

For some inexplicable reason, in the absurdly big Hack Reactor alumni slack, it's considered cool to scoff at people asking for conversations to be taken into threads.

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.

Ask, don't scoff? Also to be fair, Slack's implementation of threads is awful. Probably their most poorly done feature in my mind.

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.

I've definitely found that preemptive threading is a lot more successful than hoping others will cooperatively thread the conversation

I tried out Twist with my team and I loved it. Much easier to keep up with corporate communications—people tag you on the threads you absolutely should care about, for the rest you can skip entire conversations if they aren't relevant to you instead of sifting through a giant unorganized Slack channel. Searching works well. Idk how scripting bots for it goes but I never really cared for 99% of the bots people write for Slack so I never minded. Highly recommend.

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)

That slack is rather depressing I think I have most channels muted.

Oh my God, people use Slack without changing the "Notify me about" setting to "Direct messages, mentions, and keywords"? I work on a 100% remote team and would rapidly go insane without that.

We do not use Slack, we use IRC for direct and fast communication. We do not use it for things that need RFCs and technical specifications, for that we use gitlab and other tools.

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.

Can you share an image inline? Can you rapidly search the history? Can you customize alerts? Does it work reliably on mobile? You're debugging something and you want to share a screenshot, inline, how does that work on IRC? Can you start audio or video calls with room participants?

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.

I think most of the "Why not IRC?" sentiment comes from a viewpoint of "I only use chat for sending short, ASCII sentences." The parent comment really captures the additional use-cases which make Slack much more productive for developers discussing code.

> I think most of the "Why not IRC?" sentiment comes from a viewpoint of "I only use chat for sending short, ASCII sentences."

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.

This.

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.

> Can you share an image inline?

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.

> Can you rapidly search the history?

I can use grep on the locally stored log files.

> Can you customize alerts?

That depends on the client.

> Does it work reliably on mobile?

The IRC client I have on my Nokia phone works just fine.

> You're debugging something and you want to share a screenshot, inline, how does that work on IRC?

Normally, you post a link to an image or pastebin service that shows the problem.

> Can you start audio or video calls with room participants?

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.

There are clients that support automatic inlining of linked media. see irc-cloud which even does the hosting for you.

I don't know what fight you're fighting but we have other fights to attend to.

> 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?

>> image service

> 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.

> Can you share an image inline?

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?

Yes.

> 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.

What is the good story of multi-computer/mobile IRC access, with shared read state notifications?

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.

You could use znc.

The Lounge solves the problems you describe: https://github.com/thelounge/thelounge#overview

> When is this overhype for Slack going to stop?

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.

From my experience, in most office jobs, email is primarily used for serious and well-argued discussions concerning projects, business goals, technical details, etc. Software developers really don't use email any differently from IT support, accountants, HR managers, or salespeople. Non-developers generally reserve chit-chat for chat software, just like developers do.

Not sure what it is about HN assuming software devs are somehow intellectually and professionally superior to others.

I agree that the "software dev" distinction here is not relevant.

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

  Thanks.

  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?

Sure, but it's not like a software dev wouldn't send a similar email, just discussing something development-related instead of revenue-related.

I am in complete agreement on this point.

Sorry about that, seems my eyes skipped over the first line of your previous reply.

> 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...

> 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.

I would not hold my breath.

There are two other thing that have happened in the past few years:

• 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.

I think you've gotta acknowledge that a lot of this stuff is just fashion.

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.

> Anyone can buy a pair of pants.

Wait a second... what's the alternative to pants?? :p

I think they mean as opposed to buying the right pair of pants that will make you feel awesome in front of your friends. It's not just about covering your lower body - it's about the fit, the style, the fabric, etc.

I feel the same way about web browsers, and before that, sound cards, and before that, color monitors.

I participate less in channels but 1-on-1 chats with colleagues I work with is indispensable. I am an old hat, I have been online for 25 years (OK, it'll be 25 on September 2, fine, yes I am part of the Eternal September cohort). But I have never seen any app, talk, ICQ, AOL, MSN, Skype, you name it, I tried it, I used it which made this so easy. Discussion and code separates, inserting images and longer code snippets are trivial. Remember the IRC rule of not pasting more than three lines and pastebinning the rest? And now it has video and voice which works, just like that.

And part of the hype might be how easy it is to add emojis and have a little fun. It's important, too.

At my company we use slack because Skype was getting worse. We tried some alternatives, and slack was the friendliest, easier to use, with the right features. I don’t see any hype in our choice - simply it was the right one.

In my experience, Slack is the first chat application that both techies and non-techies actually use. I don't know why that is. But instead of asking when the hype is going to stop, it might be useful asking why the hype is there in the first place. [Edit:spelling]

> Slack is the first chat application that both techies and non-techies actually use.

IRC, MSN Messenger, AIM, and Yahoo Chat were definitely used by both groups. None of them required a lot of resources to run.

Those aren't slack problems, those are people problems. I can just as easily point to email threads that are incoherent and hard to follow. I can also point to meetings with no agenda that waste everyones time but give the appearance of 'managing' or team building.

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?

Better than "Skype with a way better UI".

* 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

I could also add to your list that Slack actually works in other platforms than Windows. Yes it's Electron but at least it's guaranteed to work, unlike Skype for Linux or Skype for Mac.

Funny enough I use Linux and am using the new Skype. The old Skype on Linux wasn't perfect but it was leagues and bounds ahead of the current Electron-based garbage.

Oh, it has history... in Outlook, that's like Edge saving your bookmarks in Excel kind of absurd.

But I agree it works like shit, half the conversations aren't there and I can't figure out a pattern or why.

> Information density isn't configurable

Just zoom in/out with Cmd-+ / Cmd--, it's just a browser after all.

That address font size issues, but not relative sizing or spacing issues.

Most people are too arrogant to communicate asynchronously successfully. People think that chat is like being on a telephone or in person and that they can demand one's full, exclusive attention. That is some serious arrogance bordering on narcissism when done in personal conversations. At work, it could me more tolerable, but the downside is that no work gets done. Managers need to start to understand this. If you keep someone's full attention for eight hours a day, you should expect no progress. Of course, managers don't understand this either because they are like everyone else described above. In some places, this is understood. I often go days with only a few slack messages at my work, so it's hardly impossible. Then again, we are a fully remote, async business. If I'm not responding, it's rude to demand that I respond, except for pre-scheduled meetings. Not even for emergencies like servers being down. If you have something urgent, call. If not, wait. It's very simple. It works great.

It’s also possible to mute chats, disable notifications and revisit them periodically.

You get to decide if you want to communicate asynchronously.

I don't see how this helps when someone is demanding your attention in your personal life or at work. But it will definitely make things worse with people who demand exclusive attention and on the job possibly get you fired.

The clichéd answer on HN would be to change your employer if your working environment doesn't allow you to concentrate on the job.

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.

When is the Slack-hating hype going to stop? It's a tool that lots of businesses find useful. Its a company that makes a good product that they sell for money to people who find it useful. This is exactly the kind of success story we badly need a lot more of in our industry. And yet the top comment on every Slack-related story is some variant of "why not just use email or IRC?" It's a bummer.

Because just about every technical team needs the ability to do some sort of real-time communication, and Slack's UI is obviously better polished than the products that predate it (HipChat/IRC/etc).

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.)

Someone finally gets it! This is exactly what I've seen as horrible as a Slack user. Zulip looks great!

wow, this looks really really really good

A Julia Evans cartoon is high praise indeed. Good for you!

I didn't get why everyone was getting hyped over a product without threads when they were the most useful part of Flowdock, so I'm glad you're trying to think about it further.

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.

We've thought about a tree-based model, but our current thinking is that a feature of that form would add a lot of UI complexity, for fairly limited benefit. One of the key things we'd lose with a tree-based model is the ability for someone catching up on a conversation to efficiently read it without a lot of jumping around between different views (or having to read a tree, rather than a linear history).

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).

Did you really have to mention your “MIT” education twice to convince us that you solved a relatively simple UI problem?

I don't think it is a simple problem. Much like TODOs, everybody has their opinion about how a chat app should behave. Zulip seems fine, but it's not that unique either, there is also Twist and I can imagine that many of the other competitors do too. Note that Slack has threads too but they are different, Google Chat also has threads but they are not named.

I have this same complaint about message boards all moving into Facebook groups. Sure it's convenient but the same content ends up recycled endlessly.

Sure phpbb is a little clunky but at least I can use it as a knowledgebase.

> 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 like the message board model, like Basecamp, myself.

* 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.

>> 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.

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.

Not a slack user but an avid fan of our persistent chat tool for a central place on with alerting and deployment approvals where you can immediately dive into meaningful conversations about either.

Slacks API and number of systems with built in integrations blows the competition away.

> 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.

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'd say you should give Flock a shot! It does provide a very similar feature set and does some things differently! The ease you talk about is all there, a lot of third party app integrations are also there. The platform lets you run proper apps inside of flock, apart from the usual slash commands and bots. All the pricing grids provide video conference by default, even the free plan! And the pricing is way cheaper than Slack.

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!

Email does not guarantee quality, or coherence.

I am regularly Cc'd into conversations that have 10 or so people and multiple topics lasting a week.

We really wanted to not use Slack. We really wanted something self-hosted. After weeks of wasting time trying a half-dozen alternatives, we bit the bullet and now use Slack too. I too thought, "Chat isn't that hard -- why wouldn't we self host?"

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:

- Jabber

- IRC

- Rocket.Chat

- Mattermost

- Zulip

- 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.

Same here. Mobile apps and notifications are super hard - especially when you pair them with email notifications (in case you don't see a chat).

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'd argue that Hipchat had the exact opposite problem with notifications. It was _too_ aggressive about notifying everywhere.

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.

I'll take this over open offices, at least you can tune it out.

Search is pretty good too

At my job we use Slack to track pull requests for review, to monitor alerts for services, to track releases for deployments. Of course we also use it for private team chats. Some of the non-technical people have other bots they use too. Slack is much more than chat.

Im with you on this. It's a great product for sure - it has something about it. (Although Flowdock has way better threading).

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.

> 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.

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:

https://livestream.com/accounts/9197973/events/7910977/video...

Well, it's not like it's a technological marvel or anything (I mean, the amount of ram it uses is kinda insane), and chat apps are like the "hello world" of network programming, BUT! From what I've seen the social effects of it are huge. There's just a lot of nice subtleties that they nailed, and it's so invisible that there just doesn't feel like there's a need to find an alternative. It just kinda works and you don't have to think about it.

Applications like slack/flock/microsoft teams work because they integrate all of the apps/third party websites that you would use. So instead of checking multiple websites in a day for updates ( crashes on crashlytics, new reviews on play/app store, new pull requests on github , new task in JIRA etc), you can get realtime updates for them in one tool.

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.

Am I the only one who sees this as anti-competitive? This is basically collusion - Atlassian agreeing not to compete in chat in return for a payment from Slack. It almost seems like we're intent on making literally every mistake we made with traditional businesses, but with electronic products.

"Taking out a competitor is good for Slack, said Butterfield: “There’s fewer choices for people.”"

Really surprised that a CEO would make a comment like that on the record.

Well it’s not anti-competitive to be competitive...

"There’s fewer choices for people," is such a short quote that I would avoid judging it on its face without seeing the full context.

Slack's competitors include Google, Microsoft, and Facebook. You can say that all of those companies have terrible products if you want (Hangouts, Teams, and FB for Work), but all have been positioned to act as Slack alternatives.

I don't think Slack is worried about looking anti-competitive in that crowd.

"Competition is for losers"..."Always Aim for a Monopoly" -- Peter Thiel

https://www.youtube.com/watch?v=z6K8PZxyQfU

https://www.youtube.com/watch?v=UUzvo4HwojU

It looks more like a product acquisition than collusion.

> Slack will pay an undisclosed amount over the next three years to acquire Atlassian’s HipChat and Stride products

...which are being immediately shut down.

Their official post says they are working on a transition path:

https://slackhq.com/atlassian-and-slack-partnership

Yes, I should have been more clear.

They are immediately deprecated. It doesn't appear that Slack has any real interest in Hipchat/Stride tech (I know I don't).

Depending on how you define "immediately". This is from the Atlassian FAQ:

  The end-of-life dates for each products are below:

  Stride: February 15th, 2019
  Hipchat Cloud: February 15th, 2019
  Hipchat Data Center (v3.0): June 22nd, 2019
  Hipchat Data Center (v3.1): September 26th, 2019
  Hipchat Server (v2.1): December 8th, 2018
  Hipchat Server(v2.2): May 30th, 2019 
  Hipchat Server (v2.4): June 30th, 2020

Okay, so given that Atlassian has a clear and direct reason to develop a competitive chat application, presumably they'll embark on producing a new solution and marketing it to their customers as a competitor to slack? I'm not sure I buy it.

If by "anti-competitive" you mean all of a sudden there's less competition, then yes it is although that's nothing unique, competing companies merge or make strategic deals all the time. But if you mean "anti-competitive" as in violating anti-trust laws then probably not given the amount of choice that still exists and the apparent lack of monopolistic strong-arm tactics being employed by either side. I'm no lawyer of course.

Edit: Original made it sound like I was suggesting the companies were merging, which isn't the case.

Despite slack being quite popular and truly a good product, Microsoft still has the upper hand. If you have the "Microsoft Suite" you get everything, access to all their products. Slack is fighting an uphill battle against Microsoft and eliminating Atlassian will help.

Dividing those who aren't diehard Microsoft fans won't help.

How is anything aside from legal infiltration going to make the playing field any less competitive? If we're all still playing by the same rules, there is still competition.

It's certainly IS anticompetitive.

Anticompetitive practices aren't illegal though. They are only illegal if a company has a monopoly or has significant market power.

Now, the question we have to ask is is Slack a near monopoly in it's marketspace? Maybe. I could see the argument go either way.

Not really, Teams is half as large and growing much faster because it’s glued to the side of Office 365.

Alas, perhaps I have just spent way too much of my life living in startup land. I've never even heard of people using these Microsoft chat products.

The Fortune 500 makes up 73% of American GDP.

I imagine there's some observation bias here, but aren't there other enterprise chat apps out there in the market?

Like if my neighbors and coworkers and friends use Slack, I'm not sure if they're a proxy of the entire market.

The reason I say that is because there are other apps that do similar things that hail from Microsoft, Google and Facebook.

Then the retort goes: well they don't do integrations and aren't as developer focused as Slack and Hipchat.

Then, naturally, wouldn't that incentivize those other apps already in the market to build out those features, and do it better?

I mean this without being tongue in cheek, but Teams itself is anti-competitive. It's a horrible product which is basically only in use because it's bundled into Office 365. Absolutely nothing in Teams is not done better in other products, including Microsoft's own products such as Skype for Business or plain old Skype.

Business chats in general are just completely incongruent with what users are expecting from end-user chats like Telegram or WhatsApp or Messages. Even Google has fallen far behind with regards to Hangouts, and Allo is not a good answer either. From a business perspective, I get why businesses choose Teams or Allo, but the actual products have usability as an incidental feature. With both major players, the chats are just there to ensure that Slack cannot/will not grow, same with other programs such as Discord. It's a revenue stream that is yet untapped, and soon Microsoft and Google will come calling for their payment from Businesses.

What about it is horrible? My team loves it.

Agreed. Teams works really well for us as well.

Seconded, me and my team love it.

Same here. We just started using it and everyone really likes it so far. Much better than Skype. I've tried Slack and didn't really care for it. I realize MSFT is mimicking the Slack style in Teams, but I just didn't really actually want to use Slack. But Teams seems like something I want to use.

I have a few reasons to list:

1) It constantly minimizes for seemingly no reason (at least once a week).

2) The "Teams" and "Chat" menus are separate. They're in the same window in Slack, and that just makes sense.

2.1) The "Teams" menu won't list more than 4 channels per Team by default. If you want to open a channel there you have to open the menu or favorite everything. I know this can be fixed by good sanitation by Team admins but Slack's way of doing it encourages it automatically.

3) Can't invite outside users like you can with Slack.

4) The chat history is so short it has to load after maybe 10 lines when scrolling up.

5) The "thumbs up"/message menu covers the message when hovering over it so it's impossible to highlight a message to copy/paste starting from the right to the left. You can go the other way but I never have until Teams.

6) Updates take forever to release! I've googled issues that MS staff note as "on the docket" for adding but months later it's still not added.

7) I frequently don't see the toast/popup notifications for some reason. I don't know what's going on there and it could be me but I don't remember it happening when I used Slack at work.

8) When it updates it shuts down without notification.

9) This might be the Android "work profile" in play but if I get a call or sometimes even a message the Android notification will not go away until I restart my phone.

I mean, Slack isn't perfect but I didn't have any complaints about it except that the call functionality would disconnect randomly.

re toast/pop ups, it’s SO frustrating that they don’t use the OS built in notifications framework! doesn’t respect DND and plenty of other integrations because of this ridiculous decision

This list contains the majority of my and my teams' complaints about Teams. For us, the big issue is that historical data is near impossible to dredge out of Teams because of the aforementioned scrolling issue. Search is universal and cannot be limited to a single user, and also is fairly literal, meaning you can't really search for something that So-an-So posted awhile back about X, unless you know the exact content of X.

Bookmarking exists, but you can't link to public bookmarked chats.

5 is a surprisingly frustrating one for us as the exact way it occurs is simple: Someone messages you, then right away attaches a ticket number, for example, which appears on the second line. The context menu will obscure this number completely, and only if there is enough whitespace on the line to double click to "Select All" can you select it.

Teams gives incredibly limited access to the calendar, insomuch that you can only go a few days back and forth, not a week for example, and you can't block out your time via Teams (i.e., add just an appointment time for yourself, since you need to add someone else to the meeting)

The mobile client seems to be absolutely the only application that decides there is a low internet condition, despite every other application on my phone fetching content happily and freely (Outlook on Android likes to do this too and refuse to fetch message content, frequently requiring a force quit of the Application to recover from and the Application becomes completely unresponsive)

Back to the Desktop app, it's also quite slow just in general, moving between Team Chats is very sluggish whereas other chat programs handle this in a snappy and graceful manner. File uploads are very awkward, and the fact that dragging and dropping a picture from a browser uploads it as Sharepoint content instead of as just inline (like other messaging clients) do is just a bit asinine. To have to first drag it to the desktop, then attach the file is just another annoyance.

All in all, for me it's just comparing what Teams offers to what something like Telegram offers, and it's night and day between the two. Most of the time in our org, as soon as you're past the acquaintance stage with someone after discussing an issue on Teams, you ask to be allowed to talk with them on Telegram instead.

For the actual chatting part of a chat program, it's really bad. For internal video/calls, it's not too bad (though our experience trying to use the Web-version to make a video call was an exercise in Microsoft frustration, as we found out that we basically had to use Edge if we wanted to use the Web Version to do it, and even then it didn't work). Nevermind that a Safari Version has been promised from months at this point without any delivery.

To me Teams feels like Microsoft saw that there was revenue in locking clients into their chat eco-system, but didn't have a product ready, so they decided to release Teams and just get everyone onboard. My cynical take is that soon they realized they didn't have to compete if they bundled Teams with their Office packages and called it a Slack Competitor; suddenly, the decision was pay for something like Slack, or a "Slack Competitor" you already bought.

I will give Teams this thought, their bot integration is very nice. I think Telegram does it a bit better, but we do make very good use of the chat bots for basic automated updating and information distribution.

I didn't know they had a desktop app. I only use it in a web browser and on my phone and I don't think they have those issues. Maybe you should give those a try?

FYI, as a Microsoftie, (so I really have no horse in the teams v skype/lync debate) I find teams to be FAR better than skype. I'm on a half-remote team, and when we have to interface with groups that preferr skype, it always seems more frictional; I even was joking to my peers today that in teams we are more prompt+get through+done with meetings even faster than our in-person versions. It has rough edges that I trust engs are looking into, but I raise an eyebrow at the assertion that skype does it better, outside of integration scenarios which are rapidly improving. (And I used to use skype as the primary method of communication between my breakdancing crew a decade or so back, and used slack more recently for another job, I simply don't see Teams being as far behind as you imply.)

Similarly, I personally find the bundling->anticompetitive argument very unconvincing, especially given G-suite and other players in the cloud office space, especially in this context as atlassian's business model "rhymes" pretty heavily.

(As always disclaimer all opinions are my own, etc etc)

I don't love teams, but don't think it is horrible. It's a lot better than what I expected.

> Absolutely nothing in Teams is not done better in other products, including Microsoft's own products such as Skype for Business or plain old Skype.

I haven't tried Teams yet, but I struggle to imagine how anything could be worse than the current state of Skype for Business and still function even minimally.

(Disclosure: I work at Microsoft but not on Teams / Office)

I've used Slack for 2+ years, hipchat for ~1 year, Discord for gaming for years, and now Teams for ~1 year. For work, I like Teams best.

In my mind the most significant, perhaps the only significant, difference between Teams and the rest is the threaded-by-default approach. It was hard to get used to at first, but this make it so much easier to keep track of different conversations that would otherwise overlap. In my mind, it's the best of both chat and email. Slack kind of does this but it's not nearly as seamless. You have to hover over the small reply icon and most of the time people don't do this. In Teams, you are forced to use threads and I think it is a good thing. Teams definitely has its quirks but with the velocity of improvements I've seen, most have already been fixed and I'm optimistic the rest will all be ironed out before long.

I don't even include Skype for Business in this comparison because in my mind Skype for Business is in a completely different category. It doesn't do the same things. And I can't think of another software product I dislike as much as Skype for Business / Lync.

Slack going out of business is also anti-competitive. There is probably something like a half billion Teams users now.

Right, because everyone knows the second law of business is that the number of competitors in a market can never decrease over time.

Jokes aside, how is this anti-competitive other than trivially reducing the number of total competitors? If 4th place wants to give up in the race, should all of their work be in vain? AFAIK a product like Slack doesn't require tons of up-front legislation preventing new entrants in the race. Competition in this domain is very much alive, regardless of what a few big kahunas decide to do.

Using collusion without knowing what it means... Businesses make business deals all the time. If I had a company that made an inferior product and wasn't able or willing to invest time and resources to improve it, you know sure as hell I'd look to sell that product IP off before my competitors take all of my marketshare anyway and my company gets nothing for years of pre-existing work.

That's a sensible business move that lets them allocate resources to their strengths. To believe it's some kind of secret or illegal deal is pretty naïve. It's obviously not a mistake either - Hipchat is technologically behind other products on the market, and Atlassian has other core products that are doing really well (JIRA, for example).

I've never really gotten into any of Atlasssian's products. It seems like they make tools for managers with bolt on functionality for engineers (which may be why I never caught onto their products). I hope this is good news for Slack, but as a software engineer today, Atlasssian's products are not the first ones I would recommend in any category.

What would you recommend instead of Jira?

What is the problem you're trying to solve?

An opinionated workflow of collecting from a development team and its customers potential future efforts, estimates of the cost and value of those efforts, prioritizing based on those estimates (maximize expected value, minimize expected cost), scheduling & forecasting efforts based on a sound statistical model (e.g. estimation error).

You can accomplish most of that with Phabricator[1], except for the forecasting efforts. As for the forecasting; I worked at Amazon which had a dedicated JIRA engineer and that was the best I've ever seen JIRA being run and used. In my time there, I never saw any manager predict anything consistently accurate over the course of a long project with it without actually talking to engineering.

JIRA promises armchair management, but I've yet to see those tools actually work. That being said, you may be a better JIRA user than anyone I know. JIRA has always be promoted as a tool from the top down, never from the bottom up.

[1] - https://www.phacility.com/phabricator/

JIRA's problem is it's too configurable and popular with folks who are into prescriptive authority, so it absolutely can be worst tool you've ever used, and frequently will be.

100% agree.

Stick to github issues or similar. Whatever is closer to the real work and gives you the biggest bang for the buck. Not the most wet dream. You do not need a gazillion of workflows and checks and stories and epics and boards etc. "Keep it simple, stupid"

What I like is to specify dependencies. Unfortunately, the simple ones (Github, Gitlab, Trac) don't have that feature.

The Jira we use at work has gone overboard. There is too many ways to specify and people are confused. For example, we have "blocks" (B cannot be finished without A closed) and "follows" (B cannot be started without A closed).

As a first step GitLab has implemented relationships in issues, for more context see https://gitlab.com/gitlab-org/gitlab-ce/issues/4058

Phabricator (https://www.phacility.com/phabricator/)

I would also recommend this. I've been using it for a while and it's amazing. Tightly integrated into version control, great team/project/task management, code review tools, great command line integration though arcanist.

Clubhouse [1] It has flexibility of Trello and features of Jira. We have been using for a year and we really enjoy it.

[1] https://clubhouse.io

Our team is happy with https://www.pivotaltracker.com

Jira was great, ~15 years ago. It was a tool that actually helped development, especially with the GreenHopper plugin

Now almost the entirety of its functionality is to help various middle managers track things that are important to them, while continuously making development slower. Manager 1 wants to track Metric A? Add a drop down. Manager 2 wants to track Metric B? Add a new form to fill out. And tie them all together with workflows so that you can't do your work and mark it as complete until all the boxes are checked and fields are filled.

Those that haven't experienced this probably just haven't worked in a medium or large corporation.

> Now almost the entirety of its functionality is to help various middle managers track things that are important to them, while continuously making development slower.

This!

Hey, it could be worse. It could be VersionOne.

VersionOne has the advantage of being too clunky for middle managers to figure out.

V1 is too clunky to figure out by developers (or any human being for that matter) and looks like something designed in the 90-ties.

> Those that haven't experienced this probably just haven't worked in a medium or large corporation.

So true, though I expect that of the HN crowd (given it's hosted by YC).

Everytime I hear someone praise Jira, I think "Do you have more than 100 people using the same instance?" Middle manage needs charts and reporting, and that's Jira's strength. It's an absolute disaster to use on a daily basis.

We chose Pivotal Tracker over Jira because we didn't need all that stuff, and PT fit fairly well with our existing workflow. But... is the ability to do those things really a disadvantage? Seems more like a problem with the way these medium/large companies work than with the tool itself. If Jira didn't exist I don't think they'd use something like Pivotal and just do without all the tracking; they'd just have something ad hoc and unwieldy cobbled together instead.

> Those that haven't experienced this probably just haven't worked in a medium or large corporation.

It’s really an organizational problem, not the tool.

Amen to that! Both as a user and a developer in the atlassian ecosystem, the experience is like you're 2 decades behind simple basic features with astronomical implementation effort. "Enterprise" has never gotten a negative connotation within atlassian walls it seems.

I run the Atlassian stack for my company, so here's some thoughts on this:

- Jira is pretty bog-standard these days, huge installed base. It's a bit weird to administer, and not as powerful in many ways as I'd like (especially compared to a more flexible system like ServiceNow). However, it's entrenched and a lot of people like it.

- Confluence is a top tier wiki. I actually find it very nice to work with, both from an editing, organizing, and also an API standpoint. It's much nicer than MediaWiki or Sharepoint for this purpose, and though it's not ideal for collaboration on MS documents, it's still very solid for working on shared documentation.

- Bamboo is a decent build system. It's lagging behind Jenkins in terms of integrations and support for source-controlled declarative build stuff, but for teams that like to point and click it works well, and the support for parallel builds, branch builds, etc. is all much easier than it is in Jenkins.

- Bitbucket is a reasonable choice for on-prem Git hosting. I prefer GHE, but if you have the rest of the Atlassian apps, there are some integrations that are nice, and it's not terribly expensive, so if you have ops familiar with running Atlassian apps it may be a good choice for you.

That's about it. Not something I love, but definitely not something I hate. Their support is also quite good, and guided me through a painful upgrade of a stack that my predecessors had left neglected for five years with no patching. Can't complain about that!

> Confluence is a top tier wiki

Can you explain why you feel this way? I've felt nothing but frustration using Confluence internally. It seems to continually get in the way and have an obtuse and unintuitive way of doing things.

Navigation in particular is nearly impossible for me.

I'm in a company which uses the full atlassian suite (on premise) and I find your comment is a very good summary. I always see people complaining about jira on the internet, but in real life, everyone I know seems happy with it, I have no idea where that come from. Maybe it depends on your admin and/or the size/culture of the company

Whenever someone passionately hates Jira my go-to line is "your Jira instance can only be as good as its admin."

IT departments in charge of installing and upgrading Jira don't tend to bother with optimizing it, and most companies don't have dedicated Jira admins.

So you either have a motivated employee that will moonlight as an admin and figure out how to make it better in their spare time, or you just end up using all the defaults, which most projects probably don't need.

Every engineer I met dislikes Confluence. Engineers who write most of the documentation don't like using Confluence which lead to out dated, subpar and incomplete documentation.

In my org, I noticed this and created a github repo to push documentation in Markdown. I created initial version of docs and now every engineer in our team uses it because they know markdown, appreciate version controlled docs and can use whatever editor they want to. This repo is now filled with quality documentation for most of our stack and operations.

I'm an engineer and love Confluence + Gliffy. Writing fully interlinked documentation with illustrations and tables and styling is much easier than with any other tool.

I'll second the love for Confluence as an engineer. Easy to use and navigate imo. Hate JIRA with a passion though, at least the two implementations I've use have been exhausting with fields and options.

I'm an engineer and I like Confluence, especially compared to any other options. And doubly compared to markdown (although I concede I'm probably the only engineer who dislikes markdown)

> Confluence which lead to out dated, subpar and incomplete documentation.

How exactly is it Confluence's fault if your team does not update the docs?

Confluence's editor is truly awful. I've spent 15 minutes just trying to remove superfluous newlines -- it's maddening. If you do something like {{fsck}} to create a bit of monospace text, it's totally unclear if there is a space after the text, or there isn't, due to the way the reverse video section is larger than the actual text. God help you if you accidentally backspace into the monospace section, everything you type after that is monospace. It's extremely frustrating.

I wouldn't be surprised to learn that many folks when faced with the prospect of updating a document using the Confluence editor will instead just find something less terrible to do.

I often write my entire document first using the old style Confluence markdown, and when done I import it into a new Confluence page. You can't take an existing document and convert into markdown, but if you are the only person working on the document this is a workable approach.

> I've spent 15 minutes just trying to remove superfluous newlines

I find that hard to believe but have reported it to Atlassian?

If all the problems which have mentioned are true why not move to something else?

How do non-engineers update documentation?

I don't care for Confluence at all. It feels engineered to death (as does Jira, for that matter)—it can do everything, but nothing well. I've been trying to organize my team's Confluence space but I'm constantly confused by the software which seems to be working against me.

I think my issue with Atlassian software is that it feels so unopinionated—they've added every option and customization because they have such a large enterprise customer base with unique needs—and the result is that it becomes byzantine and unfriendly because it can do _everything_.

We've been working on an open source solution for this, if you're interested - markdown or wysiwygy based editing with a hosted option – http://getoutline.com/

How do I write macros? What advanced styling options are there? How do I manage templates? How do I restrict access to certain content?

> (especially compared to a more flexible system like ServiceNow

Oh dear god no. Our company runs mixed Jira and Service Now, and for all Jira's disadvantages, at least I can get a link. to a ticket. To you know, reference or share. Without explaining the awful UI for where people need to put the ticket number in if they want to see it.

While we're sharing opinions, my take on these.

- Jira is tolerable. Many of the more essential features are only available as plugins and many of them feel like ugly bolt-on hacks (looking at you, Insight) to the point that Atlassian won't even investigate your problems unless you replicate them without plugins. But my largest complaint about the system is how dreadfully corporate and boring it feels to me in a very abstract sense. Jira is the least fun I can have with computer.

- Confluence's search is abysmal; fgrep would do a better job. The markup language could use improvement but it's not that awful.

- No comment on Bamboo and Bitbucket. I'm not a developer.

   It seems like they make tools for managers with bolt on functionality for engineers

Yep. And who are the people who decide what project management software to use?

They changed the headline to "Slack Is Buying HipChat" from "Slack and Atlassian Team Up to Take on Microsoft in Chat Software". The latter still survives in the URL.

The "team up" makes it sound ridiculous, like some sort of cabal is being formed -- the team up here is like when I team up with a cheeseburger to take on hunger.

+1 for the cheeseburger analogy. I'll be using it. Thanks!

> Taking out a competitor is good for Slack, said Butterfield: “There’s fewer choices for people.”

Strange quote.

Yeah, a rare glimpse into how these execs actually think. I'm suprised the pr people let this through their filters.

I agree completely, that's a terrible statement for an executive to make and PR should have stopped that. But on the other hand, I can almost see the logic in it. I'm making a huge leap here, but I remember back in the early 2000s, I had some friends who used AIM. I had some friends who used MSN. I had some friends who used ICQ. I had some friends who used Yahoo. These different chat services were really all exactly the same, the only difference is you can't chat between AIM and MSN. I don't care which chat service "wins", I just want all my friends using one so I don't have to sign into fifteen different services just to communicate.

In that situation, Adium or Trillian or various third party clients were basically required if you had any sizable group of friends. Just standardizing on one chat platform would have been better than everyone making their own, since they weren't really competing to make anything better. They just existed, and all did exactly the same thing and were incompatible with each other.

The question is, does Slack differ from Hipchat differ from Teams in any meaningful way, and does Hipchat disappearing actually make a difference when Slack exists? I honestly don't know the answer.

> I just want all my friends using one so I don't have to sign into fifteen different services just to communicate.

If only the different services would be able to talk with each other, you wouldn’t have to get your friends to all switch to one of them. But, here we are, a decade or two later, and interoperability is still nonexistent.

> interoperability is still nonexistent.

I'd say interoperability _again_ nonexistent. For a brief while it looked like XMPP federation was working.

Could also be a reporter misquoting. Reporter says, “how do you respond to someone who says this creates fewer choices for people?” CEO: “There’s fewer choices for people, but they are better than choices.” Boom, first half is the money quote.

Is that the real quote?

No, it’s a hypothetical situation where a reporter can create the conditions for a money quote.

Why is that strange? It's very well established that people hate choices (regardless of what they may say) when you actually measure it:

https://sheenaiyengar.com/the-art-of-choosing/

And it's very good for the company, as they don't need to do as much competition with HipChat so they can slow down innovation and raise prices. Win, win.

It's true that individually most people are happier without a choice, but when you take them away you end up cutting out whole chunks of people. What if the thing that went away was accessible to people with certain types of disabilities and the new thing isn't? What if the old one wasn't a public company but the new thing is and now they have to comply with U.S. export laws and you were perfectly okay using it in Iran before but now can't? etc. There are a number of cases where most people won't want a choice, but by giving them what they want and removing one you hurt a lot of other people.

This reminds me of Aaron Levie’s recent take on Kara Swisher’s podcast - on how enterprise software is going to be either about Microsoft (jack of trades) or about a collection of smaller companies (specialists in their fields) integrated with one and other. Slack and Atlassian focusing on what makes them great and working together makes a lot of sense

Levie is wrong. His personal bias is showing: an over optimism that Box can survive as an independent long-term. It's going to be Microsoft and other giants. There's no scenario where Slack remains an independent company, for the exact same reason there was never a scenario where Github remained an independent company. It'll be surprising if Slack is still independent three years from now.

It's perpetual consolidation in enterprise, nothing has changed about that in decades. Microsoft eats Github. Atlassian eats Slack (or some other company does). Maybe Atlassian is the next Oracle, or maybe Oracle or Salesforce or SAP or Microsoft eats Atlassian.

The one thing every scenario has in common: the little fish don't stick around and cooperate, they all get eaten and merged into ever larger companies. Nothing can stop that process, all the little fish have shareholders more than willing to sell when the big price comes in from the giants.

PeopleSoft, Siebel, Sun, MySQL, Great Plains, Sybase, Business Objects, Ariba, SuccessFactors, Concur, RightNow, Taleo, MuleSoft, Demandware, ExactTarget, etc etc

It's the same thing going on over and over again. The little fish never stick around. Box will end up in someone's stomach just the same as the rest.

Alas, I mostly agree... But what about Basecamp or Mailchimp for example?

What big corp wants to own the liability of Mailchimp? The minute you crack down harder on customers using spammy email lists, the revenue picture changes dramatically.

Just not big enough with a large enough installed enterprise base.

I'm curious then why did nobody buy Atlassian then? There's a possibility that a new company grows out of one of them.

The big fish (Google, Amazon, Facebook, Microsoft, Apple) will continue to buy smaller companies until governments steps in and breaks them up in an anti-trust suit. The EU will lead that charge. The writing is on the wall.

if the EU just wants to fine the big tech companies out of existence, then the big tech companies will just stop doing business there. The EU cannot break those US companies up. If disproportionately large fines (e.g. the fine Google recently paid) continue, the tech companies will just leave - which may be what the EU wants, but it also seems that the EU is pretty bad at creating technology companies

It hurts to think about how much brainpower is being spent worldwide, over and over for decades, by busines customers and competing developers, on......

sending text.... from one computer to others.

I have this nightmare where I wake up in the year 2045 and am still reading about yet another chat app being released that’s incompatible with the hundreds of others out there.

Interesting. I worked at a healthcare tech startup last year and the reason why we had to use Hipchat is because the self-hosted Hipchat Server was HIPAA-compliant and Slack does not have a HIPAA-compliant self-hosted option. Have no idea what they're going to do (or anyone who needs to comply with stricter regulatory guidelines that prevents use of cloud-based messaging apps).

They seem to be HIPAA compliant now. (No self-hosting yet)

https://slack.com/security

HIPAA compliance doesn't mean anything unless they're willing to sign a BAA with their customers' organizations. Perhaps they're signing BAAs now, but in the recent past (~6 months ago), I asked and they weren't signing them.

Even if they sign BAAs, that doesn't mean that every health organization is willing to go off-prem. On-prem is popular for a reason.

Yes, absolutely. Good point.

Shameless self-promotion: We (Trillian) just received HITRUST certification, provide a BAA, and offer both a SaaS variant and the self-hosted Trillian Server product, both of which run over our own open IM protocol. We're not exactly a Slack/Hipchat clone (having been around for 18+ years, we're more of a traditional IM and group chat solution with some modern stuff like an API, chat bots, and federation capabilities) but have been getting great feedback in the healthcare space with our business offering. More: https://trillian.im/uses/hipaa-compliant-texting/

I still remember (and may still have an installer for...) Trillian back in the days when it was just a multi-IM client.

I like your pricing comparisons for on-premises servers - particularly the comparison to a Skype for Business site license. https://trillian.im/uses/self-hosted-instant-messaging/

Am I correct that you're pretty much focused on just the IM/chat side of things rather than all the calendar/phone/build system/coffeepot/refrigerator integrations that Slack seems to talk up?

We think integrations can be great, and offer a few of our own right now (a proof-of-concept /weather command and a deeper integration with Global Relay for some of our fintech customers, for example). That being said, we're being careful about integrations and making sure they're more than just novelties that do nothing but move email notifications into a group chat. Our primary focus is lean and mean instant messaging, the good old contact list + presence (with ICQ-era fun like invisibility allow lists!), speed (being one of the last few companies offering a desktop chat client written in C++ that chugs along without using 2GB of RAM!), and strong administrative controls. Secondary to that is our focus on integrations that bring clear value to our customers. I expect we'll add more good ones this year!

Looks like it still has the multi-IM feature.

I just grabbed the personal client. It's very lean. Reminiscent of old IM clients, really. That said I haven't entered a chat yet.

Whoa, that's a name I haven't heard in a while.

What options are left for self-hosted chat systems with comparable features? We've been using self-hosted Hipchat at our company and there is zero chance we will ever use a cloud solution.

https://www.mattermost.org/

We moved to RocketChat, which is gradually getting there.

A Matrix.org server?

How easy it is to administer channels on Matrix? Like making team-private channels that can't be joined without approval?

Channels default to unlisted and invite-only, and the per-channel permissions system is fine-grained.

It's pretty simple to adjust permissions using Riot - I haven't tried it with the other clients, though.

* Zulip https://zulipchat.com/

* Rocket.chat https://rocket.chat/

* Mattermost https://mattermost.com/

* Riot/Matrix https://riot.im/

And XMPP is not completely dead, depends on what you mean "comparable features".

Out of interest, why would you guys never use a cloud solution? Sensitive conversations? Server reliability?

Management doesn't trust externally-hosted solutions with our IP. This expands beyond chat applications as well.

For example when a company acquires another, your workflows will be broken, you are forced to move and learn the new tool and you have no control over YOUR OWN data at all.

Like when you buy a product that seems solid and then have to scramble to find a replacement because it's being shut down out of nowhere?

--Hipchat onprem user

People I respect¹ seem to like Zulip (https://zulipchat.com/), though I haven't used it myself.

¹: https://twitter.com/b0rk/status/986444234365521920

Zulip on the desktop is a great experience. Unfortunately their Android app is pretty much unusable, which is a non-starter for me.

(I lead the Zulip project)

When did you last try Zulip on Android? I agree it was pretty much unusable in 2017, but everyone who actively uses it agrees it's improved a lot in recent months (I use it every single day, and have a good experience using it to get my work done). The mobile apps remain our top engineering focus area, since they're certainly far behind the desktop experience's level of polish, but we've generally stopped hearing new users describe them as "unusable".

I should also mention that Zulip's threading model makes the experience of replying to a conversation when you get back to your computer feel great, which isn't true for any other chat tool. You don't have to be glued to your keyboard/phone in order to communicate effectively or avoid missing out on participating in important conversations, and I can't emphasize enough how much better this makes life.

That doesn't eliminate the value of mobile (as I said, this is our top focus area right now), but it's a big part of why people love Zulip today, despite the mobile experience being way behind the desktop experience.

Did you tried Movim? It's a web based XMPP platform.

* Self-hosted (simple web application), a Docker image is available, Debian package incoming

* Chatrooms and one to one chat with file sharing, embeded pictures, administration, discoverability, message editing, archives management, synchronisation between devices

* Post publication in Communities and personnal accounts

* Compatible with XMPP transports and services like Biboumi to bridge it with IRC

* Responsive so it fit on your desktop and your mobile (the UI is also fully in sync between your devices)

* Video-conferencing (one to one)

* and many other things…

You can check it on https://movim.eu/ and give it a try :)

P.S.: I'm the maintainer of the project

Check out http://inverse.chat/

> "and are providing a migration path to Slack for all our customers."

Well, not all of your customers. Unless Slack is introducing a self-hosted version?

They've already nuked the page on the self-hosted hipchat offering, which now redirects to https://www.atlassian.com/partnerships/slack

Which is a complete bummer. Slack isn't an option for us.

I haven't looked at them in a while but I believe Mattermost is still offering self-hosted options and I believe they still market themselves as a slack alternative.

It is possible to get a confidentiality agreement with Slack over and above the normal terms if you negotiate with them.

Hipchat took standard IRC, and added some interface fluff, youtube links, and emojis. They achieved great market footprint.

Then Slack starts up later - makes literally the same exact product, and manages to surpass, and eventually subsume Hipchat.

Crazy.

HipChat had some major uptime issues. I have friends who experienced whole day outages at their companies.

I hear a lot of people on HN say it was "Just IRC" and I'm always surprised by that. If IRC was so compelling then why didn't it take off? Why did Slack have a meteoric rise? It can't be for no good reason.

I think the answer is that the interface fluff they added is actually extremely important and valuable. They made it dead simple, and fun to use for EVERYONE. My limited experience with IRC was honestly not great (please don't kill me, I'm sorry). Where is the mobile app? How do I get notified when I'm not online? What is EFNet/Freenode/etc? I use a slash command and paste my password in plain text to login? I can't just paste an image?

Social apps are extremely difficult to get right. People seem to discount "silly" things like Emoji reactions. Honestly it DOES sound silly to say this, but it really is a great way to express and communicate. This is especially true for our large and diverse team. It also cuts down a TON of message spam ("Congrats!", "Yay!" etc)

My Linux user group used to hangout in IRC until 3 or 4 years ago when little by little we stopped joining the channel. Some of us tried IRC clients for smartphone and it was a lousy experience.

Until one day someone created a Telegram group. Now we are all there, the conversation might not be as fluid as IRC, each is in their own timezone, but it is there.

Yes, IRC I think finally "failed" once persistence went from "nice to have" to "need to have" feature. Yes, you can work around this if you are a top 20% techie who enjoys that stuff, but most don't.

Mobile basically made the "all clients synced from anywhere" a necessity, and then lack of IRC client development for things like rich media hurt to boot.

Scrappy founder here. Telegram crushes it for low latency, instantly synched desktop/mobile flexibility, easy topic channels and groups, and trivial bot API. I've not seen anything do what it does as perfomantly.

For code, wiki, and issues, it's self hosted Gitea. It's a dream to fire up thanks to Go and SQLite, and users forget you're not at GitHub.

Nothing more than those two plus email needed here, yet anyway.

>If IRC was so compelling then why didn't it take off Define 'take off'. It was quite popular in the 90s and early 00s, but not in comparison to say AIM or ICQ for example. But where are those two networks now ... and IRC is still there.

People seldom seem to acknowledge this, but software apps go through fads just like everything else. Slack won because it was the new hotness and it was able to get the network effect snowball. Especially in the beginning, small things matter a lot, and Slack was pretty polished right out of the box.

IRC's main issues in my opinion are a lack of integrated file/attachment handling (you can't just post that meme GIF in a channel without finding someplace to upload it first) and hideous clients. If there were more free clients like the Colloquy Mac client I still use even though it basically has been abandonware for almost a decade, I think IRC would have had an easier time getting traction.

> Crazy.

Indeed so, if judging in a reference frame of gross oversimplifications and dismissing importance of details.

I hate Slack, the client, the cloud lock-in. But I think they and those in between of golden IRC times and them did refine team chatting experience.

Speaking of my own experience: it's now easier to follow discussions and way easier to form more complex messages (mostly thanks to markdown) that convey your point. Just some things of the top of my head.

> Indeed so, if judging in a reference frame of gross oversimplifications and dismissing importance of details.

I'll admit, re: IRC - yes, that's a stretch and ignores details. It's more that Slack managed to kick Hipchat's butt so thoroughly that really surprised me.

Do you think they're the exact same products, and that there's absolutely zero reason for anyone to prefer Slack over HipChat?

As someone who uses both Slack and HipChat on a daily basis, I am very happy to see that HipChat is the one shutting down. The "cute" features that Slack adds aren't worth much individually, but the overall user experience is much better on Slack than HipChat.

Gosh, I hope there will be a #MovingToMattermost movement coming. This feels like a dangerous move to me, and bad for the market, competitiveness, and users. One more thing the tech world does not need right now, is even further increasing its reliance on a single service (and even more so one with a mediocre track record of uptime).

Customers with HipChat installed on their own servers will be able to use it for an extra few months or as long as two years, depending on the version.

Slack and Atlassian will make it easy for customers to move, but they won’t be forced to switch, Butterfield said.

So they are not forced to switch, but if they don't then their chat will cease to work?

Well, thanks to this today I learned that Microsoft had a product called Teams. I didn't see anybody using it but I saw plenty of people using Slack. Maybe is Team addressed to big companies? My customers are all medium or small.

Does anyone here have some experience using Teams? Is it really in competition with Slack?

Teams is bundled into Office365, so if you use that for email or Office software, you've got it for free.

It's exactly the same product as Slack, almost carbon copy.

Teams at the moment is mostly used by massive companies, as Slack is really built for smaller teams. I like Slack, but it is very unreliable. I am constantly disconnected, have messages never sent. This is not on the free version, it's almost inexcusable in the amount of times it happens.

> I am constantly disconnected, have messages never sent.

Weird, I have never had those issues, and have been using Slack heavily on a daily basis for a couple of years.

I used it in two different jobs, both with paid plans (and obviously different internet services) and both have had the same disconnection problems. Maybe it's a regional issue? I'm around Nashville/Atlanta. I have had multiple instances of someone asking me why I haven't replied only to see a message marked as "failed to send" because of a disconnection. This is multiple team members too, not just myself.

The huge advance of Teams is that you get it in a package if you buy Office365. Otherwise it is a chat app similar to Slack with less ready made integrations.

I use Teams at work. Rumor has it that we are switching (back) to Slack, and I cannot wait. Teams is terrible. The UI is sluggish, and the UX is unintuitive to the point that it almost feels intentionally confusing.

Teams is a shitty version of Slack but it’s bundled and included with Office 365 which almost every big business licenses. Free is a hard offer to refuse.

Teams also did not have a free version until about a week ago.

I oversee a ten person team, we use Teams and love it.

I use Teams in a small, half-remote team within a large company (50K+ employees). It's been great in comparison to the other option available to us, which is Skype for Business.

We have both HipChat and Teams at work, with my team using HipChat. My team ran an experiment to move all conversations and collaboration to Teams for a trial period. That trial period ended with everyone feeling very frustrated that they spent more time trying to figure out WHERE things were going on in Teams rather than the content of actual collaboration efforts. Teams has a horrible design for threads, and is ill-suited for the type of rapid-fire communication of a highly vocal team. I dread having to go back to that product and will be pushing either Slack or Mattermost as a migration path from HipChat Data Center.

It's a smart move from Atlassian, Slack is a superior product with an huge mind-share.

Most of the time companies stick with their own products as if they were a sacred cow no matter the costs.

Well, I wouldn't say Slack is a superior product necessarily. Stride had some really great ideas, like focus management and designating decisions out of discussions.

What bothers me the most with the current on-premises chat solutions is the lack of a true alternative for jabber/xmpp with OTR (or equivalent e2e encryption) support. I honestly hate that in 2018 there is no way to move away from Pidgin/Adium if you want to keep this functionality.

- RocketChat - OTR breaks very easily, and https://github.com/RocketChat/Rocket.Chat/pull/10094 has been open for months - Matrix / Riot - Last I tried it had the most complex and unusable interface - Mattermost - At first glance seems to include E2E, but when reading a little bit more...not really, just at rest encryption - https://mattermost.atlassian.net/browse/MM-669 - Zulip - nop - https://github.com/zulip/zulip/issues/6096 - Movim - nop - https://github.com/movim/movim/issues/63 ...

Matrix / Riot is not there yet, but is improving UX-wise. The flipside is that the popularity of the Matrix.org homeserver has caused scaling/performance issues lately (having a distributed/federated protocol is only easy to scale if you actively encourage users to diversify their homeserver choice). Still though, despite three teething issues, I genuinely think it's the most promising. E2E is working better than it was anyway.

OTR hasn't aged very well (it doesn't support asynchronous communication, multiple parties or multiple clients per party). For XMPP there is OMEMO, which is gaining traction (and is based on the Signal ratchet), but like with OTR, the forward secrecy it provides might be unwanted or even forbidden in corporate environments where you have retention policies in place. E2EE is great for private chats over an untrusted cloud provider, but really not a priority in enterprise environments.

Although it reduces competition in short term, it’s likely to give more competition in the long term by creating a strong competitor to Microsoft.

And based on the numbers in the article, it seems like Atlassian had less than 4% marketshare (Slack expects single digit growth - and assuming they have around 50% of the market)

This deals seems like the last step before a full - and in competitive terms logical - merger between Slack and Atlassian.

>Although it reduces competition in short term, it’s likely to give more competition in the long term by creating a strong competitor to Microsoft.

That's pretty dependent on which way Slack decides to go in terms of facilitating large Enterprises' needs for absolute control of and visibility into communications platforms. Monitoring and governance of Slack is, at present, a goddamned nightmare. The third party tools that currently exist are, in my experience, somewhat unreliable, and all of them are crippled by the fact that Slack's API drastically limits visibility into the platform. I've worked with more than one very large Enterprise customer with special compliance needs whose Slack instance(s) are one foul-up away from having a regulator rain down fines/sanctions, and in every case Slack is pretending like the issues don't exist while my customers shove their head in the sand. And compliance aside: the Slack API doesn't even have methods in place to deal with things like emoji-react trolling on read-only announcement channels, and a plethora of other little features required to control toxic and obnoxious behaviors.

I love Slack to death, but it's not an Enterprise product yet.

>> We are purchasing the IP for Hipchat Cloud and Stride

It would be nice if Slack took a leaf out of the Hipchat play book and made a native (non-electron) Mac app.

What's wrong with the electron app?

I personally don't have a problem with it, but a lot of people have a problem with it taking up a bit of system resources, primarily ram.

Thanks! The only Electron app I use is Visual Studio Code and it works great so was curious.

(Crazy btw that I get downvoted to oblivion within seconds for asking an honest question.)

an example -- i currently have 3 workspaces on my slack client (on linux) and it's currently using 500mb of RAM, which is insane for a chat client. the only thing using more ram is firefox with literally 25 tabs, including gmail's inbox and pocketcasts playing a podcast (~1gb).

You can reduce this a huge amount by simply using it in a tab in a browser. When I'm travelling I use it this way, as it eats much less battery - I just pin a tab.

It reduces the available resources for my dev vms (read: actual work) by a disproportionate amount

Especially if you are signed into multiple workspaces. The performance degradation increases by a factor of two for each workspace I am signed into.

That said, there are ways to create performant electron apps (vscode as an example), just seems like slack isn't able to do that for some reason.

Its terrible on memory if you are connected to multiple workplaces.

As others have said, it's not great resources-wise, but it also doesn't fit in well with the OS.

Hey all here,

So I observe that lots of team chat users seem lost and don't what to do anymore.

The problem with alternative Open Source team chats attempts is that they are just another silo, or walled garden. Instances do not talk to each other. A private island cannot join continent. Even within the same organisations plenty of incompatible team chats are used competitively, fragmenting the workforces.

We propose to fix all that with Nayego: https://nayego.net/ Nayego is an open source team chat under development, that has a world-class UX, and that is federated/decentralised/federated like email.

Nayego wishes to address the organisations that are open and extended, where teams are working together with other internal teams, and with partners, customers, providers, but also freelancers, and remote and home office workers.

Nayego is and will remain free/open source and open standard (XMPP, SIP, WebRTC). If you wish to register to the preview, please go to: https://nayego.net/ We will do our best.

Sounds nice, too bad there are no screenshots so I can't see what does it look like without giving my e-mail.

Does it run on an open protocol? (Maybe HTTP or XMPP based?)

That is right, I "exchange" screenshots against feedback, on a live interaction...

Yes, it runs on XMPP and SIP and WebRTC, and obviously HTTPS (because what does not?).

Echoing Promarged, the world class UX claim had me searching for screenshots, not having any was a major turn-off.

I understand.

A complete and comprehensive UX is not seen in a few screenshots...

You have several potential customers here telling you what they expect to see on a landing page when considering your product. If you’re this stubborn about listening to non-customers who are telling you exactly how to get them into your sales funnel, it gives the impression you would care less about their needs and suggestions regarding the product itself once they become customers.

Listen to your ideal customers, then regurgitate it back to them. If screenshots are not enough, how about a video? Discuss the pain points you’re solving, and show how you solve them. Maybe embed a chat session on the page and let me chat with a bot to feel why it’s better, but do something so I take your product seriously.

No, but you can get a good idea of it. If your UX is as "world class" as you claim then I would expect you'd want to show it off as a main selling point.

Giving me nothing but a bunch of marketing fluff on the home page makes me immediately lose interest.

Your landing page takes five hundred years to load.

If you cannot do well such a simple thing as landing page, how do you have any courage to promote your actual product, which is much, much more complex than a single page?

If anything, all your marketing pamphlets are now working against you, not increasing confidence in your product, but rather decreasing it.

Perhaps you should do your best first, then hijack threads with shameful self-promotion?

Yes, you are right, thanks for noticing and reporting, the landing page is slow these days, because under load, you guessed ;-)

I hope they buy Skype and every other corporate chat app too. So, I do not have to run all this crap at the same time

Microsoft owns Skype. I doubt they'd sell it to Slack.

One can dream...

This is a curious quote:

"Taking out a competitor is good for Slack, said Butterfield: “There’s fewer choices for people.”"

I know most tech CEOs might think it, but you don't say it out loud!

And whoosh there goes another option for non-cloud-based enterprise chat.

Would be cool if they re-released Hipchat as an on-prem Slack

there's Mattermost for that, which is open-source to boot.

Unless you need most of the features that Hipchat onprem has - then you get to pay $39/user/year.

Weren't both Slack's and Atlassian's offerings cloud-based?

HipChat had an on-prem (self-hosted) release, but it's been near-abandoned for quite some time.

? It just had a release back in April.

They offered a version of Hipchat that could be hosted on perm (Hipchat Server/Data Center). Slack has never had a on perm product.

No. Hipchat had an on-prem option. In fact, I'm kind of stunned to see that the blog post on Slack's website doesn't mention the on-prem version at all. Given that on-prem was one of the differentiators that Hipchat had against Slack (and one of the reasons that many companies stuck with Hipchat, even though Slack had more features), the lack of discussion around the on-prem version seems like a huge mistake.

Why would you mention a feature that cuts against your core business model?

Hmm mentioning it would probably be a bigger mistake. If they say anything they'll have detractors and proponents, by staying silent it allows them to prep & bleed off users who MUST have onprem.

All in all I would guess that slack will probably retain more than 80% of users, which is pretty good.

Lotus Sametime still exists.

I hope this means Slack will invest in improving their core desktop offering; it is a notorious resource hog

I'd love that too, but it won't happen.

Well in that case I hope MS gets a second wind like it does for VSCode. I use IntelliJ daily since I use a lot of the bells and whistles, but VSCode is great and also runs on Electron. It seems that there's a lot of things MS is doing right with the tool that Slack can't or won't.

Maybe WASM to Electron is in the horizon? :)

Microsoft is the only company I've seen that can actually get any performance out of Electron, and even then it's still a resource hog. In their favour, though, VSCode is written exclusively for Electron, unlike many of these apps which are essentially SPAs lightly reworked for a non-browser.

Wow. Atlassian is really on the way down, giving up on such an important and strategic part of the business. They've given Stride not even a year to try to compete.

Guess they'll always be the JIRA company. Congrats to Slack to winning the Enterprise Market!

Stride was launched last year. I guess it didn't get much traction then if they gave up on it in less than a year. For consumer it is of course bit sad to see the 800lb gorilla just keep growing and eating up competition, but I can see how this makes sense to at least Atlassian; they are getting better Slack integrations, and possibly other partnership benefits for what seems like essentially free. Not sure how much this move will benefit Slack (the company, not the product), but maybe they'll absorb few more customers this way. Although I imagine many Hipchat/Stride admins will be reevaluating their choices instead of just jumping blindly to Slack.

I was curious whether or not the Sride project was failing. We were about to do a migration once some key integration things were done; doesn't look like they'll finish those.

What bothered us the most with HipChat was their lax security model. Any file uploads in HipChat would be uploaded to an S3 bucket and opts for security via obscurity [1] as opposed to proper authentication.

This forced us to send sensitive material via email as opposed to directly via HipChat.

[1] https://community.atlassian.com/t5/Hipchat-questions/Securit...

As a Hipchat user, I welcome this decision. I was not happy with using Hipchat at work for a number of reasons including

* No inline syntax highlight * No edit of message (apparently I've seen some do this but I never figured it out) * can only attach one image at a time * Message fails to send then after some retries, sends multiple times

It's great that I won't have to use it again. However I'm a bit surprised that atlassian is discontinuing Stride given that they have launched it relatively recently.

Last time I used hipchat, you could edit your last message with s/search/replace à la sed

* slack gets paid to take hipchat off atlassian's hands

Actually Slack is paying Atlassian.

HipChat was orders of magnitude cheaper. This is like Coke buying RC cola to eliminate a cheaper alternative.

But Atlassian is investing in Slack

I don't know if Stride was losing out to Slack, or if it was losing out to the FOSS competitors like Rocket, Mattermost, and Zulip. I've found Rocket and Mattermost to work well for small teams (no experience with medium or big deployments).

With the FOSS alternatives plus the more fringe competitors like Ryver, Glip, and Twist, plus related tools from Dropbox, Basecamp, etc., it's hard to see there being a market for Stride.

Tangentially related, recently Google pushed an ad for chat.google.com my way (in a Gmail popup no less). It seems they made a Slack competitor, it sort of uses Hangouts for one-on-one chats but its own thing for groups (and groups from Hangouts don't show up there) and broke Hangouts in Gmail since then (some conversation where the other person wrote the last message shows as unread the next time I open gmail).

Of course they released another IM product. Their IM teams are at war with each other.

I tried it. It's garbage. Worse than every other option listed here. You can't even search for rooms.

I'm not a huge fan of Slack or Hipchat either way, but I can't help but lament that there is less competition for enterprise chat solutions now.

Non-tech people like Facebook (et al). Understandable. Hell, tech people like Facebook. Because of the social graph, understandably, I get it. You can't fight the compartmentalization of our previously open Internet, I guess.

Or maybe, at least developers know better.. ?

Turns out no. What annoys me to no end is when developers willingly crash right into this "electron react"-whatever hipster bullshit cause its "cool". We had IRC _thirty_ years ago. Slack is not cool. Sure, upgrades are in order for IRC. But it works. Slacks evaluation is so laughable. Obviously it is because of its data - that it won't share.

Anyway. We should know better. We should not willingly put everything into slack or hipchat or whatever. Why would we?

Ease of X, I guess.

Give me an api where I can sync all my stuff locally and, you know what, fair enough, go nuts, but these guys build their businesses based on holding on to their data like vultures (no surprises there) . Understandably. I just thought tech savvy people would know/do better.

Anyway, that's my two cents. I feel like a minority.. Now get of my lawn.

This both sucks and is great. Sucks for me. Hopefully will be great for Mattermost and Matrix.

For HIPAA compliant shops Slack is a non-starter. Mattermost will hopefully get a lot of corporate $ now. I wish Matrix's dendrite[0] golang replacement homeserver was finished and in better shape. I'd much prefer to go the Riot/Matrix route, but it doesn't feel ready for prime time yet.

HipChat Server was SPOF but could be made to be HIPAA compliant by hoisting their AMI out and encrypting the base image.

I literally was at the tail end of hacking Hipchat Data Center to be fully HIPAA compliant and HA using Vault, Consul (+locks), Terraform, scaling groups and friends. I was so excited about getting to blog about it. sigh

Looks like I'll be re-engaging Mattermost. Last time I looked their E20 pricing was like 4x more expensive per user than it was costing for HipChat DC. Hopefully they finished their HipChat importing option.

[0] https://github.com/matrix-org/dendrite

Hey, can you elaborate a touch on the lack of HIPAA compliance with Slack? Some folks on my team seem to think it's compliant - and I'm not finding true hard answers either way (ignoring the BAA side of things)

Slack showcases the HIPAA logo on their security page, but upon closer inspection - https://slack.com/terms-of-service/supplement#healthcare - you'll see that unless you've signed a separate agreement with them, you acknowledge that Slack is not HIPAA compliant and that you are not to send them any PHI. My guess: they are signing BAAs for grid customers only (so the logo isn't a lie) and making them pay handsomely for the pleasure.

As I shamelessly disclosed upthread, we (Trillian) offer a HITRUST certified, BAA-backed solution for healthcare organizations that comes in SaaS and on-prem variants. More: https://trillian.im/uses/hipaa-compliant-texting/

Our Corp IT requested engineering to Pilot Google Hangout Chats as we already have GSuite. Turns out that Slack is the most expensive enterprise application that IT owns. It is more expensive that GSuite, although it provides a specific utility, while GSuite has emails, spreadsheets, docs etc. etc. That doesn't really sounds sustainable.

Any feedback on Google Hangouts Chat?

Would be interesting to see Discord make an entry into the space. They're killing it on the gaming side already.

It seems really weird to me that a CEO of a big company like Slack comes forward and comments "There’s fewer choices for people.” as if this is supposed to be a good thing. I get that this is true on paper, most CEOs however would rather hide this effect of a merger in order to avoid government regulation.

Of course, in an ideal world, the obvious technical flaws in chat products would easily enable competitors to “take on” the broken ones.

Why does it seem so hard to get chat right? Heck, Yahoo Messenger had lots of features in about year 2000 that we still lack or struggle with in newer products?

Hi there, I'm currently building out some chat-based groupware and also feel like we've gone backwards since 2000.

Can you humor me with some nostalgia and tell me what features of Yahoo Messenger you used?

I'm really hopeless about chat applications. So many apps and platforms, so little inter operability.

All that users need, most of the time, is a web app and a smartphone app for private messages.

Channels and voice are special cases. Voice is hard to achieve, and channels are usually covered by private servers.

We were using hipchat, worked fine with our custom integrations and workflow. Stopped working when they switched to stride ( had to do with version of jira we are on) Now that my integrations are all most working again I have to probably look at using mattermost.

We don't want to use slack.

Why not?

Probably because they don't want to (or can't) have a huge portion of their company's internal communication stored forever on a third-party server.

I still find it hard to believe that so many companies are okay with doing that.

And yet most large companies are using AWS and the like. This obsession with "MUST be behind OUR firewall!" is very arrogant, penny-wise pound-foolish thinking - and it tends to wither in the face of a frank, honest cost/benefit analysis.

Amazon probably has more, if not better, security and engineers than most of the companies we're talking about.

>Amazon probably has more, if not better, security and engineers than most of the companies we're talking about.

And Slack has...? A bunch of VC money and a hastily thrown together chat app?

Pricing mostly Can't host it ourselves, not really an issue now that we have a new boss and he doesn't care as much about hosting everything ourselves. Thats why moving to stride was in the works. I tried testing slack with a sub section of our team and they didn't like it at all.

I've been toying switching to mattermost for a year now though. See how it goes.

Wow. Atlassian is really on the way down, giving up on such an important and strategic part of the business. They've given Stride not even a year to try to compete. Guess they'll always be the JIRA company. Congrats to Slack to winning the Enterprise Market!

I wonder what all these folks who have worked and are still working on Stride will end up doing? If I am not mistaken most of the devs who worked on Stride are located in Austin, TX. I wonder how they feel about this whole change...it must feel yucky!

Having worked on that team, it always felt yucky. The product has been a train-wreck for years.

I wonder then, this "partnership" means that whoever is on the Stride team is now going to somewhat work really close to Slack's team? Or is Slack acqui-hiring the Stride team? or ... ?

People are talking about secure alternative matrix/riot, mattermost, zullip... not that i have anything to do with them but Wire https://wire.com is pretty impressive (you can geek out on haskell backend).

In small org we have been using riot/matrix and it is great. Works well but it is more like modern IRC. It doesnt have too much ui sugar. Mattermost on the other hand looks cool but had slow clients and there was some bullshit with push notifications requireing some enterprise server license. Hope its no longer the case - i mean why would you want chat without notifications?

It's crazy to me that so many people here think IRC is a valid alternative to Slack in 2018.

With the recent trend of consumerizing business apps, IRC is an awful experience compared to so many modern chat apps. It's much harder to set up, looks way uglier, and lacks useful features.

Not to mention IRC has a somewhat technical setup, which makes any non-engineering team reluctant to buy in. Software companies have sales, marketing, design, product, support, leadership teams... use a tool that works great for everyone.

Personally we use Twist. I enjoy that it's lightweight and performant compared to Slack, which feels clunky (just take a look at your activity monitor).

We have been using Stride for a few months and are baffled by how bad it can be and how it seems to miss key features that was in Hipchat (such as a call indicator). I used to always say "this is not the hard part of your job, stride " because it would fail to do basic things such as display images.

A colleague of mine found a security issue but had a hard time logging it and had to make it public.

Basically, I got the impression that the stride team in Atlassian was a bit of a mess.

All that said, it is sad to see it go because it was an alternative to the near monopoly of Slack. The only other alternative is rocket chat and MS teams now.

For being the business chat darling, Slack is just not that great at being an amazing chat platform.

I'm comparing to WhatsApp, because in my org that's what everyone defaults to, as the basic chat functionality in Slack is a subpar experience: * No delivery notices, even in private chat * Can't upload multiple attachments/images in one go, but instead defaults to N single uploads * No option not to download large images * Logs in slow, needs to be "connected" and thus struggles to send messages on intermittent connections

Maybe the HipChat infusion of people with a different viewpoint will help?

"Taking out a competitor is good for Slack, There’s fewer choices for people.” - Stewart Butterfield in the above article.

When are tech CEO's going to realize it's bad to sound like a monopolist b/c anti-trust?

I tend to agree with Ben Thompson of Stratechery that one of the best ways to thwart emerging monopolies and preserve choice for consumers it to prevent companies from acquiring competitors. Although today Microsoft is the goliath and Slack is the david, in today's world David's grow up very very fast...

Spotted on Twitter: "Imagine winning a market so dramatically that your competitor shuts down their competing services, hands you their IP, and gives you money for the trouble."

Seems like a move to take on Microsoft Teams. This is something that these independent software vendors will need to do in order to take on Microsoft: integrate and enable a best of breed world. Its not really a great experience if I buy Slack, Okta, Box/Dropbox, GSuite if I don't have a seamless and integrated and experience throughout. The only way is to build a integrated ecosystem and enable these horizontal use-cases.

This is disappointing. Our compliance department requires an on prem solution. I don't necessarily agree, but convincing them is a challenge. We've been using RocketChat. The experience has been great, but it's becoming more critical to our business and harder to manage. We were starting to look at HipChat as a replacement as we already have a large Atlassian deployment. Maybe Mattermost is worth a look?

Even those less competition normally isn't good I'm hopefully optimistic about this. It seems by and large slack has won the chat wars for open projects/podcast live chat/business. My company uses HipChat (due to being in the Atlassian suite) and so I'm not going to have both Slack and HipChat open but if we move to Slack it means I can participant in some other open Slack channels.

I haven't used Stride, but some of the features it was touting that Slack doesn't have seemed nice. I liked the idea of marking something as a "decision". Not sure how that played out in practice, but I know I'm constantly searching our Slack conversations at work to try to find decision points. Would be cool if they integrated that, and other features from Stride.

We've been waiting a long time to move to Slack, and recently started migrating over ~2,000 users from HipChat.

Everyone is desperate for the migration to be complete, and to get rid of HipChat. A large majority had already moved their own team over.

Can't say I'll be sad to say goodbye to HipChat, it worked well for the 6 years we had it, but Slack is superior in many ways (other than price...).

Slack is best of the breed - all history search, easy code blocks that i cannot yet figure out how to in Hipchat, pictures, files.

Electron is big and bad, is it phoning back to Google? but I can understand the savings.

Hipchat have an UI, that looks like a joke, after using Slack, but on-premises, offline installs are very important for company security.

I guess Slack bought it just to kill it. No offline stuff in 2018, folks.

Ugh, so how do Jira tickets related Bitbucket commits get automatically hyperlinked by ID? I guess they don't.

Slack is unfortunately thought by some people I work with as a replacement for email... When it's almost impossible to discuss certain things in a chat app, and it's search is just not as good, and it's organizing messages almost non-existent.

Has Slack fixed the problem with bots spamming people yet? I used to be a member of a lot of channels for various projects but then a wave of bots started hitting all of them spamming various scams or trying to impersonate accounts so I had to leave because I couldn't have my inbox flooded with nonsense and the signal-to-noise ratio was too high.

Microsoft Teams isn't successful because it's a great product, it's because their sales team goes into corporate environments where they're already using Office 365 and offer Teams for free as an integrated extension to the rest of the suite.

Big companies aren't choosing between Teams and Slack, they're choosing between Teams and email.

Are they really this scared of Teams? I don't even really see them as true competitors, they are going after different customers. It's kind of odd to me. Maybe they believe Google is going too enter the space soon, that would change things if it were bundled with GSuite and then Teams is bundled with O365.

There's always Cisco Webex Teams. I actually kinda like it, although I do work for Cisco. Unfortunately I have to keep it, Slack, and Jabber open on my laptop so I can communicate with anyone anytime (/sarcasm). On my phone I only have Webex Teams which is great when I'm away from my computer.

How is that legal from a competition law point? Slack is the dominating actor in office chat how can they buy Hipchat?

https://en.m.wikipedia.org/wiki/United_States_antitrust_law

  Taking out a competitor is good for Slack, said Butterfield: “There’s fewer choices for people.”

What a statement! This is why I dislike Slack as a company and as much as I hate Teams (have to use it at work), I have no problem with it if the choice is Slack or Teams.

I love it. Finally a CEO being direct and honest instead of "synergy blablabla" when the reality is "we're taking out a competitor".

I really hope that this results in a combination of the two's best features. Slack is so nice and polished and runs well as a standalone app, and Hipchat has some really nice features (like channel re-ordering in the sidebar) that I'd love to see brought into Slack.

I remember working at a company several years ago where they used HipChat. Slack was just up-and-coming and I remember wondering why it even bothered to compete since HipChat did a fine enough job. Interesting to see how Slack has evolved and that Slack is absorbing HipChat.

I feel like the outages and backend infrastructure issues at HipChat were a major factor in its being overtaken by Slack. Don't know how open Slack is to discussing this, but I'd be very interested in a side-by-side comparison of the two architectures.

HipChat was a great tool 3 years ago. Atlassian left it to wither on the vine. Really too bad, as I enjoyed its simplicity.

Also, data export is great, sure, but what I really want is someone to re-setup all our build and monitoring notifications in Slack :P

For those considering an alternative, there's an alternative made by an Indian startup (https://flock.com) that's pretty popular out here.

It's much cheaper than slack.

Slack is still to expensive :/ this merge will not help.

What we need is self hosted app like Rocket Chat, which is not the best software on the market but it's the best solution for new companies to start with something inexpensive.

What's out there in the way of white-label or integrated slack alternatives? My non-tech staff are very confused by these modern UIs and ideally I'd like something I can embed into our intranet laravel site.

Keep an eye on https://level.app/ if you're interested in self-hosted chat and/or are tired of the interruptive nature of Slack.

Can you use self host slack?

To my knowledge no. That is going to be an issue for current users of Hipchat Server/Data Center.

I've seen a private Slack instance at SAP, so it seems to be possible for big corps..

Maybe it'll be a good opportunity to push for a self-hosted Matrix homeserver...

You can self host mattermost, which has been working well for us so far.

https://mattermost.com/

There is an open source alternative to Slack that can be self hosted called Rocket Chat: https://rocket.chat/

The CEO of Slack really said that the acquisition was good because "there's [sic] fewer choices for people"???

Imagine the CEO of any non-tech startup company saying this in a Bloomberg interview.

I really didn't like Stride but couldn't put my finger on why not. A lot of shortcuts from Hipchat didn't migrate across but I could live with that, something just felt off...

I'm not thrilled to see further consolidation, but frankly I'm not surprised in the least -- Hipchat is an utter dumpster fire.

News of chat companies buying and selling your chat should strike fear into the hearts of their users. Use open protocols.

This is an incredibly good move by Slack, even more so after the recent announcement from MS with the Teams free version.

Github merger has sent the vultures to pick apart Atlassian before they lose all enterprise market share to Microsoft.

used both, hipchat and slack. both underwhelmed me. I still don't understand the hype around them, both provide their full functionality only in the browser, their clients having quite a few deficits. zulip. mentioned in another thread, looks promising, don't know if it can keep its promises

"hip", "slack", "chat", "buying" - makes you wonder...

Seems like they are shutting down HipChat...What about existing customers?

Great! How many cooperate chat applications does the world actually need?

Rev must be good, save on tax buy a useless company.

Time to set up an IRC server again then. Sigh.

What's the point of Stride again?

Are they also going to buy Discord?

It's really easy, the first one to support multiple chat windows will win. That and ctrl+enter to send message.

tl;dr: Atlassian discontinues HipChat, sells some important HipChat's IP to Slack, and is concentrating on a better Slack integration.

Atlassian wins again.

huge opportunity for Mattermost and Rocket.Chat folks

Shame all three are terrible products. How hard can text chat be?

One of the things that have surprised me is the lack of a good slack alternative from one of the large companies like Microsoft or Google.

Now, before someone tells me about Teams and Hangouts, they need to realise that Slack/Teams/Hangouts all are glorified Yahoo! messengers but slack is the only one that seems to have a sweet spot where people are comfortable using it.

RIP hipchat, piece of crap

Woah, this is huge. Atlassian is really going for the "everything a tech shop needs" gold.

The exact opposite, Atlassian is selling and retreating.

I see it as a step towards integrating more (or in this case better IMO) things into their ecosystem. Consolidating Hipchat with Slack is a step toward that.

Atlassian is selling the defunct Hipchat to Slack.

If thats what was happening, Slack would be migrating over to Hipchat.

Just for the record, I surveyed a dozen Hipchat users who used it all day in late 2016 for software development. They had zero complaints about using Hipchat.

My opinion of the Hipchat web client at the time was that it worked fine (no complaints from me.)

I believe we were on the free tier, so that was a great deal.

A new Eng. VP wanted to seem hip, so he switched us to Slack "to ensure we were using the best tools possible."

Nobody said that Slack was better or added any features that were worth mentioning.

Slack offers quite a few features over HipChat that make it a nicer platform to communicate on, particularly for discussions of a technical nature. Things like easy message editing & markdown formatting make it easier to paste scripts, log messages, console outputs, etc.

HipChat was fine as a bare-bones text chat. Slack is a pretty clear winner when it comes to a collaboration platform.

Mid-to-late 2016 was the peak of periodic outages in HipChat (like, several hours per week, which is a lot for a core messaging platform), which was when we threw in the towel and switched to Slack.

At the time, Slack had the feature of "you can log in", which teams really liked :)

https://status.hipchat.com/uptime?page=10

Reply on news.ycombinator.com