Hacker News new | comments | show | ask | jobs | submit login
Slack Is Buying HipChat from Atlassian (bloomberg.com)
1006 points by uptown 18 days ago | hide | past | web | favorite | 709 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.


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


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.


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.


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.


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


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


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.


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


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


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.


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


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.


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.


Impeccable timing.


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


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


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.


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.


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.


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.


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.


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.


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


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


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?


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.


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.


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.


Approx how many users?


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


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.


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


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?


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.


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


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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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.


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.


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.


No good web front ends?


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.


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


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.


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.


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.


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


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.


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


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


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.


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


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.


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.


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.


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.


Setup an old faishoned IRC server?


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.


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.


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.


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.


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


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


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?


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.


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.


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.


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.


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.


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.

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


Microsoft Teams has on-prem support.


source?


[flagged]


Please don't post unsubstantive comments here.


Please don't post unsubstantive comments here.


You have a point, but there's little alternative.

I wrote about this recently, if anyone cares: https://news.ycombinator.com/item?id=17494243


I was just making a poor attempt at a joke (which fell flat). I appreciate what you are doing and I thank you for your dedication.


welcome to 2018


Obv IRC bro

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


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


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.


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.


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.


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


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


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


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


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


[flagged]


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


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


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.


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


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.


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.


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.


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.


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


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

> The problem I think most people run into with the realtime discussion is failing to document the outcome of the meeting -- and that of course goes into a ticket or long-term docs. A meeting with no notes or outcome might as well have not happened.

I definitely agree here. This falls under the heading of 'things we used to know as a society that we've forgotten.' Every meeting should have an agenda, even it's just a single agendum 'discuss $FOO,' and every meeting should have some sort of minutes, even if they're just 'discussed $FOO, decided to pursue course $BAR.'


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


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


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!


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


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


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


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


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.


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


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


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.


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.


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.


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.


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.


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.


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.


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.


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


> 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 don't see any compelling reason to adopt IRC. It does nothing that I care about that Slack doesn't do. If Slack completely implodes, I would search for Slack alternative. If IRC really was my only option, I'd use it just long enough to write a basic alternative myself that replaced or extended IRC w/ the features I really want.


For one thing, an IRC client doesn't pin a core of my cpu at 100% and consume half a gig of ram...

(But I realise I'm well out on the losing end of this argument, even in groups of old-school hard core technical friends/colleagues, I've been given the "crazy look" when suggesting we just use irc for chat... )


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.


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


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.


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.


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.


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


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.


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.


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.


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


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.


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


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.


> IRC hasn’t changed much in years.

https://ircv3.net/

It's changing a lot for some time now.


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.


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


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


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


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


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


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


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.


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.


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


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


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


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


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.


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


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


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


wow, this looks really really really good


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.


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.


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.


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.


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.


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


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.


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


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.


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?


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.


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


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


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.


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.


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.


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


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


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.


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


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.


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


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.


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.


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


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


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.


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


You could use znc.


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?

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.


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


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.


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


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.


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


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.


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


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.


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.


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.


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.


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.


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.


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.


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


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

Search is pretty good too


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.

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: