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.
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).
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.
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.
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
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...
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.
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.
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.
> 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.
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
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.
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.
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.
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.
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 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."?
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/)
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.
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.
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?
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.
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.
Also, client support is awful. The only one I can reasonably tell a non-technical user to use is Riot - but that's somehow more resource hungry than the Slack desktop app. There are good ones, but they are either only for technical users (weechat) or are extremely barebones (nheko, quaternion).
We're basically doing nothing but fixing Synapse's performance problems currently, and improvements are on the horizon. We're late because we got sidetracked fixing flaws in the protocol, but as of the last few weeks we're back on perf again. So far we've sped up /sync by 2x and reduced CPU by about 20%, but the RAM improvements should land over the coming weeks unless we have further distractions.
a 10 active user Synapse should use about 1GB max, so unsure what’s up with the earlier post. The reason it’s currently so much heavier than XMPP is that resource usage scales with the size of rooms being participated in, not the number of connected users - and we aggressively cache those rooms in RAM. However, 100MB is a much more sensible target and we’re busy optimising to try to shrink things down.
Maybe you want to see the preview of our work in progress? https://nayego.net/ Open Source, real Open Standards, mature technology, decentralised/federated/distributed, and a great UX.
Fit for orgs with external partners, providers, customers, freelances, remote and home office workers...
I might have missed something, but your website doesn't provide much information, and I've been unable to find any elsewhere (only an empty GitHub repository).
edit: btw, the number of comments you've made in this thread to “sell” your solution is… abusive?
This shows one strength of open source where you have the option to fork and maintain your own solution in the case the project heads the wrong way.
Unfortunately the whole world seems to be heading the wrong way with cloud based "everything as a service" where you control nothing. If the provider or cloud goes down you have nothing. Even if they just take your keys you have nothing. It's quick and easy to setup and convenient but you're basically a hostage.
Forking and managing has a cost associated with it too.
If your own DC burns down you also have nothing.
There is no "wrong way" just a different ways to evaluate risks-benefits and choosing whatever works best for your case.
100% this. As soon as you fork a project, you are now responsible for the evolution of it (even if that's just merging in upstream changes). It puts a large burden on engineering teams to track changes and maintain the fork.
OpenOffice is dead but its fork, LibreOffice, lives on.
You don't necessarily have to fork it, just the possibility of the fork changes the game. It means that the original maintainer cannot shut you down. If enough people deem a fork useful they can work together.
Of course there's a cost associated with it. But how much is it compared to the risk of someone shutting a core element of your business down? You have to evaluate.
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.
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.
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.
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
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.
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].
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.
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 ;-)
Suggestion: Have a tour of the product that doesn't require a signup. If I don't want to give you my email address, I'm left to use my imagination based on your description.
Servers seem solid and there's also ejabberd but what about clients? I want clients that are stable, cross platform and does push notification and last time I checked, there were none.
Also, I don't like the fact that it's person based whereas mattermost (and IRC) are group based that also allows person based chat.
(I lead the Zulip project, one of the main open source alternatives to Slack.)
The writing's been on the wall for HipChat for a long time; e.g. the user experience has been stagnant for many years (e.g. they never added emoji reactions). And even back in 2013, every HipChat customer I've encountered was unhappy or at best unenthusiastic about the product. So we've seen plenty of folks migrate from HipChat to Zulip.
I expect most enterprises will end up on one of the open source Slack alternatives (Zulip, Mattermost, Rocket.Chat, etc.). Frankly, they should have been using one of them anyway. If you care about a really high level of security, you want to be using well-maintained open source software. The well-maintained part is obvious, but the open source piece is really important too: It's a lot easier for white-hat hackers to find and report security bugs in software with access to the source code, and so there will be fewer that haven't been found and fixed yet.
You certainly don't want to be using a PHP app that's had over 700 confirmed security bugs found by external people (https://hackerone.com/slack) -- you can be pretty sure there are more being introduced every week.
I'll add that I expect to see more proprietary on-premise products that are the stepchild of a SaaS product disappearing over the coming years. It's a lot harder to ship software for the on-premise use case, especially if you have engineering culture used to just shipping for a single installation in the cloud (which almost everyone who works on proprietary software is). If you have the right processes and toolchain, it doesn't have to slow you down (and I don't feel it does for Zulip, with our amazing developer tooling and 98% backend test coverage), but very few organizations succeed at this. I've certainly heard some incredible horror stories from famous Silicon Valley companies about teams of engineers spending months on making a fork of a SaaS product shippable for each on-premise release.
To be fair, there are tons of very low severity vulnerabilities disclosed on HackerOne and this does not mean the application is vulnerable. Slack is definetly not vulnerable because it is written in php and you can pollute an iframe on their career website.
Having such a program in place is actually good for the application security as it does get audited by tons of hackers thanks to the monetary rewards.
I agree it's theoretically possible to write a secure project in PHP, but it's very difficult, especially if you're hiring people like crazy.
If you divide the amount they've paid out in bounties by the number of bounties paid, and compare with their bounty tier rules, it's clear that a lot of the vulnerabilities that were reported in Slack are relatively severe.
(And I agree bug bounty programs are great; we also use HackerOne)
It is not about the language is it... I don't think there is so big difference between php and python. Besides Slack is most probably using whole lot more tech than php.
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.
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.
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.
If you need ON-PREM deployment, let my team know here, they can help you seamlessly navigate your transition from HipChat: https://wickr.com/products/enterprise/ and we’ll get you on-boarded.
We 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>/
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.
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.
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).
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. :)
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?
> 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.
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.
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?
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.
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.
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.
> 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.
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.
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.
"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'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.
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.
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.
> 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?
* 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 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.
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.
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.
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.
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..
> 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.
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.
> 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.
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
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.
> 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.
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 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.
_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.
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.
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.
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...)
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").
> 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.
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.
> 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.
I hear you! I've been using the Internet most every day since 1988, and am still occasionally struck by the amount of resources seemingly straightforward programs use these days.
Re: Slack resource utilization: I'm not passing a value judgment as much as expressing confusion over multiple claims I've noticed about Slack utilization that is far, far greater than anything I've seen.
I had this problem with Slack. I switched to using it within Chrome. I can't be sure why it performs so much better that way (Chrome throttling it?), but it does.
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.
That's nice for you personally, but how does running an inhouse bespoke IRC server have anything to do with whatever line of business your company is in?
IRC is just a particular implementation of chat. The only thing keeping it relevant is the several hundred thousand people currently connected to servers.
Within a more defined context, such as work communication, adoption network effects become irrelevant. You can just build your own system and set everybody up to use it.
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.
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 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.)
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.
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.
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?
> 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!
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.
I don't think it is a simple problem. Much like TODOs, everybody has their opinion about how a chat app should behave. Zulip seems fine, but it's not that unique either, there is also Twist and I can imagine that many of the other competitors do too. Note that Slack has threads too but they are different, Google Chat also has threads but they are not named.
I 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).
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)
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.
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 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.
> 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 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.
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:
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 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.
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.
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).
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:).
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.)
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.
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.
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.
I absolutely cannot see why people still recommend IRC today for work use. It can pretty much only do text for the moment you're online and no we don't have time (money) to hack IRC to meet our needs.
Not inline, but you can share link to the image or send it to other person/persons via DCC directly, that's what you do on IRC.
> Can you rapidly search the history?
Sure, no problems with that, all the channels we use are logged and ready for advanced search.
> Can you customize alerts?
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.
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.
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.
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]
>> 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 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.
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.
Am I the only one who sees this as anti-competitive? This is basically collusion - Atlassian agreeing not to compete in chat in return for a payment from Slack. It almost seems like we're intent on making literally every mistake we made with traditional businesses, but with electronic products.
I mean this without being tongue in cheek, but Teams itself is anti-competitive. It's a horrible product which is basically only in use because it's bundled into Office 365. Absolutely nothing in Teams is not done better in other products, including Microsoft's own products such as Skype for Business or plain old Skype.
Business chats in general are just completely incongruent with what users are expecting from end-user chats like Telegram or WhatsApp or Messages. Even Google has fallen far behind with regards to Hangouts, and Allo is not a good answer either. From a business perspective, I get why businesses choose Teams or Allo, but the actual products have usability as an incidental feature. With both major players, the chats are just there to ensure that Slack cannot/will not grow, same with other programs such as Discord. It's a revenue stream that is yet untapped, and soon Microsoft and Google will come calling for their payment from Businesses.
FYI, as a Microsoftie, (so I really have no horse in the teams v skype/lync debate) I find teams to be FAR better than skype. I'm on a half-remote team, and when we have to interface with groups that preferr skype, it always seems more frictional; I even was joking to my peers today that in teams we are more prompt+get through+done with meetings even faster than our in-person versions. It has rough edges that I trust engs are looking into, but I raise an eyebrow at the assertion that skype does it better, outside of integration scenarios which are rapidly improving. (And I used to use skype as the primary method of communication between my breakdancing crew a decade or so back, and used slack more recently for another job, I simply don't see Teams being as far behind as you imply.)
Similarly, I personally find the bundling->anticompetitive argument very unconvincing, especially given G-suite and other players in the cloud office space, especially in this context as atlassian's business model "rhymes" pretty heavily.
(As always disclaimer all opinions are my own, etc etc)
> Absolutely nothing in Teams is not done better in other products, including Microsoft's own products such as Skype for Business or plain old Skype.
I haven't tried Teams yet, but I struggle to imagine how anything could be worse than the current state of Skype for Business and still function even minimally.
(Disclosure: I work at Microsoft but not on Teams / Office)
I've used Slack for 2+ years, hipchat for ~1 year, Discord for gaming for years, and now Teams for ~1 year. For work, I like Teams best.
In my mind the most significant, perhaps the only significant, difference between Teams and the rest is the threaded-by-default approach. It was hard to get used to at first, but this make it so much easier to keep track of different conversations that would otherwise overlap. In my mind, it's the best of both chat and email. Slack kind of does this but it's not nearly as seamless. You have to hover over the small reply icon and most of the time people don't do this. In Teams, you are forced to use threads and I think it is a good thing. Teams definitely has its quirks but with the velocity of improvements I've seen, most have already been fixed and I'm optimistic the rest will all be ironed out before long.
I don't even include Skype for Business in this comparison because in my mind Skype for Business is in a completely different category. It doesn't do the same things. And I can't think of another software product I dislike as much as Skype for Business / Lync.
1) It constantly minimizes for seemingly no reason (at least once a week).
2) The "Teams" and "Chat" menus are separate. They're in the same window in Slack, and that just makes sense.
2.1) The "Teams" menu won't list more than 4 channels per Team by default. If you want to open a channel there you have to open the menu or favorite everything. I know this can be fixed by good sanitation by Team admins but Slack's way of doing it encourages it automatically.
3) Can't invite outside users like you can with Slack.
4) The chat history is so short it has to load after maybe 10 lines when scrolling up.
5) The "thumbs up"/message menu covers the message when hovering over it so it's impossible to highlight a message to copy/paste starting from the right to the left. You can go the other way but I never have until Teams.
6) Updates take forever to release! I've googled issues that MS staff note as "on the docket" for adding but months later it's still not added.
7) I frequently don't see the toast/popup notifications for some reason. I don't know what's going on there and it could be me but I don't remember it happening when I used Slack at work.
8) When it updates it shuts down without notification.
9) This might be the Android "work profile" in play but if I get a call or sometimes even a message the Android notification will not go away until I restart my phone.
I mean, Slack isn't perfect but I didn't have any complaints about it except that the call functionality would disconnect randomly.
re toast/pop ups, it’s SO frustrating that they don’t use the OS built in notifications framework! doesn’t respect DND and plenty of other integrations because of this ridiculous decision
I didn't know they had a desktop app. I only use it in a web browser and on my phone and I don't think they have those issues. Maybe you should give those a try?
This list contains the majority of my and my teams' complaints about Teams. For us, the big issue is that historical data is near impossible to dredge out of Teams because of the aforementioned scrolling issue. Search is universal and cannot be limited to a single user, and also is fairly literal, meaning you can't really search for something that So-an-So posted awhile back about X, unless you know the exact content of X.
Bookmarking exists, but you can't link to public bookmarked chats.
5 is a surprisingly frustrating one for us as the exact way it occurs is simple: Someone messages you, then right away attaches a ticket number, for example, which appears on the second line. The context menu will obscure this number completely, and only if there is enough whitespace on the line to double click to "Select All" can you select it.
Teams gives incredibly limited access to the calendar, insomuch that you can only go a few days back and forth, not a week for example, and you can't block out your time via Teams (i.e., add just an appointment time for yourself, since you need to add someone else to the meeting)
The mobile client seems to be absolutely the only application that decides there is a low internet condition, despite every other application on my phone fetching content happily and freely (Outlook on Android likes to do this too and refuse to fetch message content, frequently requiring a force quit of the Application to recover from and the Application becomes completely unresponsive)
Back to the Desktop app, it's also quite slow just in general, moving between Team Chats is very sluggish whereas other chat programs handle this in a snappy and graceful manner. File uploads are very awkward, and the fact that dragging and dropping a picture from a browser uploads it as Sharepoint content instead of as just inline (like other messaging clients) do is just a bit asinine. To have to first drag it to the desktop, then attach the file is just another annoyance.
All in all, for me it's just comparing what Teams offers to what something like Telegram offers, and it's night and day between the two. Most of the time in our org, as soon as you're past the acquaintance stage with someone after discussing an issue on Teams, you ask to be allowed to talk with them on Telegram instead.
For the actual chatting part of a chat program, it's really bad. For internal video/calls, it's not too bad (though our experience trying to use the Web-version to make a video call was an exercise in Microsoft frustration, as we found out that we basically had to use Edge if we wanted to use the Web Version to do it, and even then it didn't work). Nevermind that a Safari Version has been promised from months at this point without any delivery.
To me Teams feels like Microsoft saw that there was revenue in locking clients into their chat eco-system, but didn't have a product ready, so they decided to release Teams and just get everyone onboard. My cynical take is that soon they realized they didn't have to compete if they bundled Teams with their Office packages and called it a Slack Competitor; suddenly, the decision was pay for something like Slack, or a "Slack Competitor" you already bought.
I will give Teams this thought, their bot integration is very nice. I think Telegram does it a bit better, but we do make very good use of the chat bots for basic automated updating and information distribution.
Same here. We just started using it and everyone really likes it so far. Much better than Skype. I've tried Slack and didn't really care for it. I realize MSFT is mimicking the Slack style in Teams, but I just didn't really actually want to use Slack. But Teams seems like something I want to use.
If by "anti-competitive" you mean all of a sudden there's less competition, then yes it is although that's nothing unique, competing companies merge or make strategic deals all the time. But if you mean "anti-competitive" as in violating anti-trust laws then probably not given the amount of choice that still exists and the apparent lack of monopolistic strong-arm tactics being employed by either side. I'm no lawyer of course.
Edit: Original made it sound like I was suggesting the companies were merging, which isn't the case.
Slack's competitors include Google, Microsoft, and Facebook. You can say that all of those companies have terrible products if you want (Hangouts, Teams, and FB for Work), but all have been positioned to act as Slack alternatives.
I don't think Slack is worried about looking anti-competitive in that crowd.
Despite slack being quite popular and truly a good product, Microsoft still has the upper hand. If you have the "Microsoft Suite" you get everything, access to all their products. Slack is fighting an uphill battle against Microsoft and eliminating Atlassian will help.
Dividing those who aren't diehard Microsoft fans won't help.
How is anything aside from legal infiltration going to make the playing field any less competitive? If we're all still playing by the same rules, there is still competition.
Using collusion without knowing what it means... Businesses make business deals all the time. If I had a company that made an inferior product and wasn't able or willing to invest time and resources to improve it, you know sure as hell I'd look to sell that product IP off before my competitors take all of my marketshare anyway and my company gets nothing for years of pre-existing work.
That's a sensible business move that lets them allocate resources to their strengths. To believe it's some kind of secret or illegal deal is pretty naïve. It's obviously not a mistake either - Hipchat is technologically behind other products on the market, and Atlassian has other core products that are doing really well (JIRA, for example).
Depending on how you define "immediately". This is from the Atlassian FAQ:
The end-of-life dates for each products are below:
Stride: February 15th, 2019
Hipchat Cloud: February 15th, 2019
Hipchat Data Center (v3.0): June 22nd, 2019
Hipchat Data Center (v3.1): September 26th, 2019
Hipchat Server (v2.1): December 8th, 2018
Hipchat Server(v2.2): May 30th, 2019
Hipchat Server (v2.4): June 30th, 2020
Okay, so given that Atlassian has a clear and direct reason to develop a competitive chat application, presumably they'll embark on producing a new solution and marketing it to their customers as a competitor to slack? I'm not sure I buy it.
Right, because everyone knows the second law of business is that the number of competitors in a market can never decrease over time.
Jokes aside, how is this anti-competitive other than trivially reducing the number of total competitors? If 4th place wants to give up in the race, should all of their work be in vain? AFAIK a product like Slack doesn't require tons of up-front legislation preventing new entrants in the race. Competition in this domain is very much alive, regardless of what a few big kahunas decide to do.
I've never really gotten into any of Atlasssian's products. It seems like they make tools for managers with bolt on functionality for engineers (which may be why I never caught onto their products). I hope this is good news for Slack, but as a software engineer today, Atlasssian's products are not the first ones I would recommend in any category.
I run the Atlassian stack for my company, so here's some thoughts on this:
- Jira is pretty bog-standard these days, huge installed base. It's a bit weird to administer, and not as powerful in many ways as I'd like (especially compared to a more flexible system like ServiceNow). However, it's entrenched and a lot of people like it.
- Confluence is a top tier wiki. I actually find it very nice to work with, both from an editing, organizing, and also an API standpoint. It's much nicer than MediaWiki or Sharepoint for this purpose, and though it's not ideal for collaboration on MS documents, it's still very solid for working on shared documentation.
- Bamboo is a decent build system. It's lagging behind Jenkins in terms of integrations and support for source-controlled declarative build stuff, but for teams that like to point and click it works well, and the support for parallel builds, branch builds, etc. is all much easier than it is in Jenkins.
- Bitbucket is a reasonable choice for on-prem Git hosting. I prefer GHE, but if you have the rest of the Atlassian apps, there are some integrations that are nice, and it's not terribly expensive, so if you have ops familiar with running Atlassian apps it may be a good choice for you.
That's about it. Not something I love, but definitely not something I hate. Their support is also quite good, and guided me through a painful upgrade of a stack that my predecessors had left neglected for five years with no patching. Can't complain about that!
Every engineer I met dislikes Confluence. Engineers who write most of the documentation don't like using Confluence which lead to out dated, subpar and incomplete documentation.
In my org, I noticed this and created a github repo to push documentation in Markdown. I created initial version of docs and now every engineer in our team uses it because they know markdown, appreciate version controlled docs and can use whatever editor they want to. This repo is now filled with quality documentation for most of our stack and operations.
I don't care for Confluence at all. It feels engineered to death (as does Jira, for that matter)—it can do everything, but nothing well. I've been trying to organize my team's Confluence space but I'm constantly confused by the software which seems to be working against me.
I think my issue with Atlassian software is that it feels so unopinionated—they've added every option and customization because they have such a large enterprise customer base with unique needs—and the result is that it becomes byzantine and unfriendly because it can do _everything_.
I'm an engineer and love Confluence + Gliffy. Writing fully interlinked documentation with illustrations and tables and styling is much easier than with any other tool.
I'll second the love for Confluence as an engineer. Easy to use and navigate imo. Hate JIRA with a passion though, at least the two implementations I've use have been exhausting with fields and options.
I'm an engineer and I like Confluence, especially compared to any other options. And doubly compared to markdown (although I concede I'm probably the only engineer who dislikes markdown)
We've been working on an open source solution for this, if you're interested - markdown or wysiwygy based editing with a hosted option – http://getoutline.com/
Confluence's editor is truly awful. I've spent 15 minutes just trying to remove superfluous newlines -- it's maddening. If you do something like {{fsck}} to create a bit of monospace text, it's totally unclear if there is a space after the text, or there isn't, due to the way the reverse video section is larger than the actual text. God help you if you accidentally backspace into the monospace section, everything you type after that is monospace. It's extremely frustrating.
I wouldn't be surprised to learn that many folks when faced with the prospect of updating a document using the Confluence editor will instead just find something less terrible to do.
I often write my entire document first using the old style Confluence markdown, and when done I import it into a new Confluence page. You can't take an existing document and convert into markdown, but if you are the only person working on the document this is a workable approach.
- Jira is tolerable. Many of the more essential features are only available as plugins and many of them feel like ugly bolt-on hacks (looking at you, Insight) to the point that Atlassian won't even investigate your problems unless you replicate them without plugins. But my largest complaint about the system is how dreadfully corporate and boring it feels to me in a very abstract sense. Jira is the least fun I can have with computer.
- Confluence's search is abysmal; fgrep would do a better job. The markup language could use improvement but it's not that awful.
- No comment on Bamboo and Bitbucket. I'm not a developer.
Can you explain why you feel this way? I've felt nothing but frustration using Confluence internally. It seems to continually get in the way and have an obtuse and unintuitive way of doing things.
> (especially compared to a more flexible system like ServiceNow
Oh dear god no. Our company runs mixed Jira and Service Now, and for all Jira's disadvantages, at least I can get a link. to a ticket. To you know, reference or share. Without explaining the awful UI for where people need to put the ticket number in if they want to see it.
I'm in a company which uses the full atlassian suite (on premise) and I find your comment is a very good summary. I always see people complaining about jira on the internet, but in real life, everyone I know seems happy with it, I have no idea where that come from. Maybe it depends on your admin and/or the size/culture of the company
Whenever someone passionately hates Jira my go-to line is "your Jira instance can only be as good as its admin."
IT departments in charge of installing and upgrading Jira don't tend to bother with optimizing it, and most companies don't have dedicated Jira admins.
So you either have a motivated employee that will moonlight as an admin and figure out how to make it better in their spare time, or you just end up using all the defaults, which most projects probably don't need.
Jira was great, ~15 years ago. It was a tool that actually helped development, especially with the GreenHopper plugin
Now almost the entirety of its functionality is to help various middle managers track things that are important to them, while continuously making development slower. Manager 1 wants to track Metric A? Add a drop down. Manager 2 wants to track Metric B? Add a new form to fill out. And tie them all together with workflows so that you can't do your work and mark it as complete until all the boxes are checked and fields are filled.
Those that haven't experienced this probably just haven't worked in a medium or large corporation.
> Those that haven't experienced this probably just haven't worked in a medium or large corporation.
So true, though I expect that of the HN crowd (given it's hosted by YC).
Everytime I hear someone praise Jira, I think "Do you have more than 100 people using the same instance?" Middle manage needs charts and reporting, and that's Jira's strength. It's an absolute disaster to use on a daily basis.
We chose Pivotal Tracker over Jira because we didn't need all that stuff, and PT fit fairly well with our existing workflow. But... is the ability to do those things really a disadvantage? Seems more like a problem with the way these medium/large companies work than with the tool itself. If Jira didn't exist I don't think they'd use something like Pivotal and just do without all the tracking; they'd just have something ad hoc and unwieldy cobbled together instead.
> Now almost the entirety of its functionality is to help various middle managers track things that are important to them, while continuously making development slower.
Amen to that! Both as a user and a developer in the atlassian ecosystem, the experience is like you're 2 decades behind simple basic features with astronomical implementation effort. "Enterprise" has never gotten a negative connotation within atlassian walls it seems.
Stick to github issues or similar. Whatever is closer to the real work and gives you the biggest bang for the buck. Not the most wet dream. You do not need a gazillion of workflows and checks and stories and epics and boards etc. "Keep it simple, stupid"
What I like is to specify dependencies. Unfortunately, the simple ones (Github, Gitlab, Trac) don't have that feature.
The Jira we use at work has gone overboard. There is too many ways to specify and people are confused. For example, we have "blocks" (B cannot be finished without A closed) and "follows" (B cannot be started without A closed).
I would also recommend this. I've been using it for a while and it's amazing. Tightly integrated into version control, great team/project/task management, code review tools, great command line integration though arcanist.
An opinionated workflow of collecting from a development team and its customers potential future efforts, estimates of the cost and value of those efforts, prioritizing based on those estimates (maximize expected value, minimize expected cost), scheduling & forecasting efforts based on a sound statistical model (e.g. estimation error).
You can accomplish most of that with Phabricator[1], except for the forecasting efforts. As for the forecasting; I worked at Amazon which had a dedicated JIRA engineer and that was the best I've ever seen JIRA being run and used. In my time there, I never saw any manager predict anything consistently accurate over the course of a long project with it without actually talking to engineering.
JIRA promises armchair management, but I've yet to see those tools actually work. That being said, you may be a better JIRA user than anyone I know. JIRA has always be promoted as a tool from the top down, never from the bottom up.
JIRA's problem is it's too configurable and popular with folks who are into prescriptive authority, so it absolutely can be worst tool you've ever used, and frequently will be.
They changed the headline to "Slack Is Buying HipChat" from "Slack and Atlassian Team Up to Take on Microsoft in Chat Software". The latter still survives in the URL.
The "team up" makes it sound ridiculous, like some sort of cabal is being formed -- the team up here is like when I team up with a cheeseburger to take on hunger.
Could also be a reporter misquoting. Reporter says, “how do you respond to someone who says this creates fewer choices for people?” CEO: “There’s fewer choices for people, but they are better than choices.” Boom, first half is the money quote.
I agree completely, that's a terrible statement for an executive to make and PR should have stopped that. But on the other hand, I can almost see the logic in it. I'm making a huge leap here, but I remember back in the early 2000s, I had some friends who used AIM. I had some friends who used MSN. I had some friends who used ICQ. I had some friends who used Yahoo. These different chat services were really all exactly the same, the only difference is you can't chat between AIM and MSN. I don't care which chat service "wins", I just want all my friends using one so I don't have to sign into fifteen different services just to communicate.
In that situation, Adium or Trillian or various third party clients were basically required if you had any sizable group of friends. Just standardizing on one chat platform would have been better than everyone making their own, since they weren't really competing to make anything better. They just existed, and all did exactly the same thing and were incompatible with each other.
The question is, does Slack differ from Hipchat differ from Teams in any meaningful way, and does Hipchat disappearing actually make a difference when Slack exists? I honestly don't know the answer.
> I just want all my friends using one so I don't have to sign into fifteen different services just to communicate.
If only the different services would be able to talk with each other, you wouldn’t have to get your friends to all switch to one of them. But, here we are, a decade or two later, and interoperability is still nonexistent.
And it's very good for the company, as they don't need to do as much competition with HipChat so they can slow down innovation and raise prices. Win, win.
It's true that individually most people are happier without a choice, but when you take them away you end up cutting out whole chunks of people. What if the thing that went away was accessible to people with certain types of disabilities and the new thing isn't? What if the old one wasn't a public company but the new thing is and now they have to comply with U.S. export laws and you were perfectly okay using it in Iran before but now can't? etc. There are a number of cases where most people won't want a choice, but by giving them what they want and removing one you hurt a lot of other people.
This reminds me of Aaron Levie’s recent take on Kara Swisher’s podcast - on how enterprise software is going to be either about Microsoft (jack of trades) or about a collection of smaller companies (specialists in their fields) integrated with one and other. Slack and Atlassian focusing on what makes them great and working together makes a lot of sense
Levie is wrong. His personal bias is showing: an over optimism that Box can survive as an independent long-term. It's going to be Microsoft and other giants. There's no scenario where Slack remains an independent company, for the exact same reason there was never a scenario where Github remained an independent company. It'll be surprising if Slack is still independent three years from now.
It's perpetual consolidation in enterprise, nothing has changed about that in decades. Microsoft eats Github. Atlassian eats Slack (or some other company does). Maybe Atlassian is the next Oracle, or maybe Oracle or Salesforce or SAP or Microsoft eats Atlassian.
The one thing every scenario has in common: the little fish don't stick around and cooperate, they all get eaten and merged into ever larger companies. Nothing can stop that process, all the little fish have shareholders more than willing to sell when the big price comes in from the giants.
PeopleSoft, Siebel, Sun, MySQL, Great Plains, Sybase, Business Objects, Ariba, SuccessFactors, Concur, RightNow, Taleo, MuleSoft, Demandware, ExactTarget, etc etc
It's the same thing going on over and over again. The little fish never stick around. Box will end up in someone's stomach just the same as the rest.
What big corp wants to own the liability of Mailchimp? The minute you crack down harder on customers using spammy email lists, the revenue picture changes dramatically.
The big fish (Google, Amazon, Facebook, Microsoft, Apple) will continue to buy smaller companies until governments steps in and breaks them up in an anti-trust suit. The EU will lead that charge. The writing is on the wall.
if the EU just wants to fine the big tech companies out of existence, then the big tech companies will just stop doing business there. The EU cannot break those US companies up. If disproportionately large fines (e.g. the fine Google recently paid) continue, the tech companies will just leave - which may be what the EU wants, but it also seems that the EU is pretty bad at creating technology companies
It hurts to think about how much brainpower is being spent worldwide, over and over for decades, by busines customers and competing developers, on......
sending text.... from one computer to others.
I have this nightmare where I wake up in the year 2045 and am still reading about yet another chat app being released that’s incompatible with the hundreds of others out there.
Interesting. I worked at a healthcare tech startup last year and the reason why we had to use Hipchat is because the self-hosted Hipchat Server was HIPAA-compliant and Slack does not have a HIPAA-compliant self-hosted option. Have no idea what they're going to do (or anyone who needs to comply with stricter regulatory guidelines that prevents use of cloud-based messaging apps).
Shameless self-promotion: We (Trillian) just received HITRUST certification, provide a BAA, and offer both a SaaS variant and the self-hosted Trillian Server product, both of which run over our own open IM protocol. We're not exactly a Slack/Hipchat clone (having been around for 18+ years, we're more of a traditional IM and group chat solution with some modern stuff like an API, chat bots, and federation capabilities) but have been getting great feedback in the healthcare space with our business offering. More: https://trillian.im/uses/hipaa-compliant-texting/
Am I correct that you're pretty much focused on just the IM/chat side of things rather than all the calendar/phone/build system/coffeepot/refrigerator integrations that Slack seems to talk up?
We think integrations can be great, and offer a few of our own right now (a proof-of-concept /weather command and a deeper integration with Global Relay for some of our fintech customers, for example). That being said, we're being careful about integrations and making sure they're more than just novelties that do nothing but move email notifications into a group chat. Our primary focus is lean and mean instant messaging, the good old contact list + presence (with ICQ-era fun like invisibility allow lists!), speed (being one of the last few companies offering a desktop chat client written in C++ that chugs along without using 2GB of RAM!), and strong administrative controls. Secondary to that is our focus on integrations that bring clear value to our customers. I expect we'll add more good ones this year!
HIPAA compliance doesn't mean anything unless they're willing to sign a BAA with their customers' organizations. Perhaps they're signing BAAs now, but in the recent past (~6 months ago), I asked and they weren't signing them.
What options are left for self-hosted chat systems with comparable features? We've been using self-hosted Hipchat at our company and there is zero chance we will ever use a cloud solution.
When did you last try Zulip on Android? I agree it was pretty much unusable in 2017, but everyone who actively uses it agrees it's improved a lot in recent months (I use it every single day, and have a good experience using it to get my work done). The mobile apps remain our top engineering focus area, since they're certainly far behind the desktop experience's level of polish, but we've generally stopped hearing new users describe them as "unusable".
I should also mention that Zulip's threading model makes the experience of replying to a conversation when you get back to your computer feel great, which isn't true for any other chat tool. You don't have to be glued to your keyboard/phone in order to communicate effectively or avoid missing out on participating in important conversations, and I can't emphasize enough how much better this makes life.
That doesn't eliminate the value of mobile (as I said, this is our top focus area right now), but it's a big part of why people love Zulip today, despite the mobile experience being way behind the desktop experience.
Did you tried Movim? It's a web based XMPP platform.
* Self-hosted (simple web application), a Docker image is available, Debian package incoming
* Chatrooms and one to one chat with file sharing, embeded pictures, administration, discoverability, message editing, archives management, synchronisation between devices
* Post publication in Communities and personnal accounts
* Compatible with XMPP transports and services like Biboumi to bridge it with IRC
* Responsive so it fit on your desktop and your mobile (the UI is also fully in sync between your devices)
For example when a company acquires another, your workflows will be broken, you are forced to move and learn the new tool and you have no control over YOUR OWN data at all.
I haven't looked at them in a while but I believe Mattermost is still offering self-hosted options and I believe they still market themselves as a slack alternative.
HipChat had some major uptime issues. I have friends who experienced whole day outages at their companies.
I hear a lot of people on HN say it was "Just IRC" and I'm always surprised by that. If IRC was so compelling then why didn't it take off? Why did Slack have a meteoric rise? It can't be for no good reason.
I think the answer is that the interface fluff they added is actually extremely important and valuable. They made it dead simple, and fun to use for EVERYONE. My limited experience with IRC was honestly not great (please don't kill me, I'm sorry). Where is the mobile app? How do I get notified when I'm not online? What is EFNet/Freenode/etc? I use a slash command and paste my password in plain text to login? I can't just paste an image?
Social apps are extremely difficult to get right. People seem to discount "silly" things like Emoji reactions. Honestly it DOES sound silly to say this, but it really is a great way to express and communicate. This is especially true for our large and diverse team. It also cuts down a TON of message spam ("Congrats!", "Yay!" etc)
My Linux user group used to hangout in IRC until 3 or 4 years ago when little by little we stopped joining the channel. Some of us tried IRC clients for smartphone and it was a lousy experience.
Until one day someone created a Telegram group. Now we are all there, the conversation might not be as fluid as IRC, each is in their own timezone, but it is there.
Scrappy founder here. Telegram crushes it for low latency, instantly synched desktop/mobile flexibility, easy topic channels and groups, and trivial bot API. I've not seen anything do what it does as perfomantly.
For code, wiki, and issues, it's self hosted Gitea. It's a dream to fire up thanks to Go and SQLite, and users forget you're not at GitHub.
Nothing more than those two plus email needed here, yet anyway.
Yes, IRC I think finally "failed" once persistence went from "nice to have" to "need to have" feature. Yes, you can work around this if you are a top 20% techie who enjoys that stuff, but most don't.
Mobile basically made the "all clients synced from anywhere" a necessity, and then lack of IRC client development for things like rich media hurt to boot.
>If IRC was so compelling then why didn't it take off
Define 'take off'. It was quite popular in the 90s and early 00s, but not in comparison to say AIM or ICQ for example. But where are those two networks now ... and IRC is still there.
People seldom seem to acknowledge this, but software apps go through fads just like everything else. Slack won because it was the new hotness and it was able to get the network effect snowball. Especially in the beginning, small things matter a lot, and Slack was pretty polished right out of the box.
IRC's main issues in my opinion are a lack of integrated file/attachment handling (you can't just post that meme GIF in a channel without finding someplace to upload it first) and hideous clients. If there were more free clients like the Colloquy Mac client I still use even though it basically has been abandonware for almost a decade, I think IRC would have had an easier time getting traction.
Indeed so, if judging in a reference frame of gross oversimplifications and dismissing importance of details.
I hate Slack, the client, the cloud lock-in.
But I think they and those in between of golden IRC times and them did refine team chatting experience.
Speaking of my own experience: it's now easier to follow discussions and way easier to form more complex messages (mostly thanks to markdown) that convey your point. Just some things of the top of my head.
> Indeed so, if judging in a reference frame of gross oversimplifications and dismissing importance of details.
I'll admit, re: IRC - yes, that's a stretch and ignores details. It's more that Slack managed to kick Hipchat's butt so thoroughly that really surprised me.
As someone who uses both Slack and HipChat on a daily basis, I am very happy to see that HipChat is the one shutting down. The "cute" features that Slack adds aren't worth much individually, but the overall user experience is much better on Slack than HipChat.
Gosh, I hope there will be a #MovingToMattermost movement coming. This feels like a dangerous move to me, and bad for the market, competitiveness, and users. One more thing the tech world does not need right now, is even further increasing its reliance on a single service (and even more so one with a mediocre track record of uptime).
Customers with HipChat installed on their own servers will be able to use it for an extra few months or as long as two years, depending on the version.
Slack and Atlassian will make it easy for customers to move, but they won’t be forced to switch, Butterfield said.
So they are not forced to switch, but if they don't then their chat will cease to work?
Well, thanks to this today I learned that Microsoft had a product called Teams. I didn't see anybody using it but I saw plenty of people using Slack. Maybe is Team addressed to big companies? My customers are all medium or small.
Does anyone here have some experience using Teams? Is it really in competition with Slack?
I use Teams at work. Rumor has it that we are switching (back) to Slack, and I cannot wait. Teams is terrible. The UI is sluggish, and the UX is unintuitive to the point that it almost feels intentionally confusing.
Teams is a shitty version of Slack but it’s bundled and included with Office 365 which almost every big business licenses. Free is a hard offer to refuse.
Teams at the moment is mostly used by massive companies, as Slack is really built for smaller teams. I like Slack, but it is very unreliable. I am constantly disconnected, have messages never sent. This is not on the free version, it's almost inexcusable in the amount of times it happens.
I used it in two different jobs, both with paid plans (and obviously different internet services) and both have had the same disconnection problems. Maybe it's a regional issue? I'm around Nashville/Atlanta. I have had multiple instances of someone asking me why I haven't replied only to see a message marked as "failed to send" because of a disconnection. This is multiple team members too, not just myself.
We have both HipChat and Teams at work, with my team using HipChat. My team ran an experiment to move all conversations and collaboration to Teams for a trial period. That trial period ended with everyone feeling very frustrated that they spent more time trying to figure out WHERE things were going on in Teams rather than the content of actual collaboration efforts. Teams has a horrible design for threads, and is ill-suited for the type of rapid-fire communication of a highly vocal team. I dread having to go back to that product and will be pushing either Slack or Mattermost as a migration path from HipChat Data Center.
I use Teams in a small, half-remote team within a large company (50K+ employees). It's been great in comparison to the other option available to us, which is Skype for Business.
The huge advance of Teams is that you get it in a package if you buy Office365. Otherwise it is a chat app similar to Slack with less ready made integrations.
Well, I wouldn't say Slack is a superior product necessarily. Stride had some really great ideas, like focus management and designating decisions out of discussions.
What bothers me the most with the current on-premises chat solutions is the lack of a true alternative for jabber/xmpp with OTR (or equivalent e2e encryption) support.
I honestly hate that in 2018 there is no way to move away from Pidgin/Adium if you want to keep this functionality.
OTR hasn't aged very well (it doesn't support asynchronous communication, multiple parties or multiple clients per party). For XMPP there is OMEMO, which is gaining traction (and is based on the Signal ratchet), but like with OTR, the forward secrecy it provides might be unwanted or even forbidden in corporate environments where you have retention policies in place. E2EE is great for private chats over an untrusted cloud provider, but really not a priority in enterprise environments.
Matrix / Riot is not there yet, but is improving UX-wise. The flipside is that the popularity of the Matrix.org homeserver has caused scaling/performance issues lately (having a distributed/federated protocol is only easy to scale if you actively encourage users to diversify their homeserver choice). Still though, despite three teething issues, I genuinely think it's the most promising. E2E is working better than it was anyway.
Although it reduces competition in short term, it’s likely to give more competition in the long term by creating a strong competitor to Microsoft.
And based on the numbers in the article, it seems like Atlassian had less than 4% marketshare (Slack expects single digit growth - and assuming they have around 50% of the market)
This deals seems like the last step before a full - and in competitive terms logical - merger between Slack and Atlassian.
>Although it reduces competition in short term, it’s likely to give more competition in the long term by creating a strong competitor to Microsoft.
That's pretty dependent on which way Slack decides to go in terms of facilitating large Enterprises' needs for absolute control of and visibility into communications platforms. Monitoring and governance of Slack is, at present, a goddamned nightmare. The third party tools that currently exist are, in my experience, somewhat unreliable, and all of them are crippled by the fact that Slack's API drastically limits visibility into the platform. I've worked with more than one very large Enterprise customer with special compliance needs whose Slack instance(s) are one foul-up away from having a regulator rain down fines/sanctions, and in every case Slack is pretending like the issues don't exist while my customers shove their head in the sand. And compliance aside: the Slack API doesn't even have methods in place to deal with things like emoji-react trolling on read-only announcement channels, and a plethora of other little features required to control toxic and obnoxious behaviors.
I love Slack to death, but it's not an Enterprise product yet.
You can reduce this a huge amount by simply using it in a tab in a browser. When I'm travelling I use it this way, as it eats much less battery - I just pin a tab.
an example -- i currently have 3 workspaces on my slack client (on linux) and it's currently using 500mb of RAM, which is insane for a chat client. the only thing using more ram is firefox with literally 25 tabs, including gmail's inbox and pocketcasts playing a podcast (~1gb).
So I observe that lots of team chat users seem lost and don't what to do anymore.
The problem with alternative Open Source team chats attempts is that they are just another silo, or walled garden. Instances do not talk to each other. A private island cannot join continent. Even within the same organisations plenty of incompatible team chats are used competitively, fragmenting the workforces.
We propose to fix all that with Nayego: https://nayego.net/ Nayego is an open source team chat under development, that has a world-class UX, and that is federated/decentralised/federated like email.
Nayego wishes to address the organisations that are open and extended, where teams are working together with other internal teams, and with partners, customers, providers, but also freelancers, and remote and home office workers.
Nayego is and will remain free/open source and open standard (XMPP, SIP, WebRTC). If you wish to register to the preview, please go to: https://nayego.net/ We will do our best.
You have several potential customers here telling you what they expect to see on a landing page when considering your product. If you’re this stubborn about listening to non-customers who are telling you exactly how to get them into your sales funnel, it gives the impression you would care less about their needs and suggestions regarding the product itself once they become customers.
Listen to your ideal customers, then regurgitate it back to them. If screenshots are not enough, how about a video? Discuss the pain points you’re solving, and show how you solve them. Maybe embed a chat session on the page and let me chat with a bot to feel why it’s better, but do something so I take your product seriously.
No, but you can get a good idea of it. If your UX is as "world class" as you claim then I would expect you'd want to show it off as a main selling point.
Giving me nothing but a bunch of marketing fluff on the home page makes me immediately lose interest.
Your landing page takes five hundred years to load.
If you cannot do well such a simple thing as landing page, how do you have any courage to promote your actual product, which is much, much more complex than a single page?
If anything, all your marketing pamphlets are now working against you, not increasing confidence in your product, but rather decreasing it.
Perhaps you should do your best first, then hijack threads with shameful self-promotion?
No. Hipchat had an on-prem option. In fact, I'm kind of stunned to see that the blog post on Slack's website doesn't mention the on-prem version at all. Given that on-prem was one of the differentiators that Hipchat had against Slack (and one of the reasons that many companies stuck with Hipchat, even though Slack had more features), the lack of discussion around the on-prem version seems like a huge mistake.
Hmm mentioning it would probably be a bigger mistake. If they say anything they'll have detractors and proponents, by staying silent it allows them to prep & bleed off users who MUST have onprem.
All in all I would guess that slack will probably retain more than 80% of users, which is pretty good.
Well in that case I hope MS gets a second wind like it does for VSCode. I use IntelliJ daily since I use a lot of the bells and whistles, but VSCode is great and also runs on Electron. It seems that there's a lot of things MS is doing right with the tool that Slack can't or won't.
Microsoft is the only company I've seen that can actually get any performance out of Electron, and even then it's still a resource hog. In their favour, though, VSCode is written exclusively for Electron, unlike many of these apps which are essentially SPAs lightly reworked for a non-browser.
Wow. Atlassian is really on the way down, giving up on such an important and strategic part of the business. They've given Stride not even a year to try to compete.
Guess they'll always be the JIRA company.
Congrats to Slack to winning the Enterprise Market!
Stride was launched last year. I guess it didn't get much traction then if they gave up on it in less than a year. For consumer it is of course bit sad to see the 800lb gorilla just keep growing and eating up competition, but I can see how this makes sense to at least Atlassian; they are getting better Slack integrations, and possibly other partnership benefits for what seems like essentially free. Not sure how much this move will benefit Slack (the company, not the product), but maybe they'll absorb few more customers this way. Although I imagine many Hipchat/Stride admins will be reevaluating their choices instead of just jumping blindly to Slack.
I was curious whether or not the Sride project was failing. We were about to do a migration once some key integration things were done; doesn't look like they'll finish those.
What bothered us the most with HipChat was their lax security model. Any file uploads in HipChat would be uploaded to an S3 bucket and opts for security via obscurity [1] as opposed to proper authentication.
This forced us to send sensitive material via email as opposed to directly via HipChat.
As a Hipchat user, I welcome this decision. I was not happy with using Hipchat at work for a number of reasons including
* No inline syntax highlight
* No edit of message (apparently I've seen some do this but I never figured it out)
* can only attach one image at a time
* Message fails to send then after some retries, sends multiple times
It's great that I won't have to use it again. However I'm a bit surprised that atlassian is discontinuing Stride given that they have launched it relatively recently.
I don't know if Stride was losing out to Slack, or if it was losing out to the FOSS competitors like Rocket, Mattermost, and Zulip. I've found Rocket and Mattermost to work well for small teams (no experience with medium or big deployments).
With the FOSS alternatives plus the more fringe competitors like Ryver, Glip, and Twist, plus related tools from Dropbox, Basecamp, etc., it's hard to see there being a market for Stride.
Tangentially related, recently Google pushed an ad for chat.google.com my way (in a Gmail popup no less). It seems they made a Slack competitor, it sort of uses Hangouts for one-on-one chats but its own thing for groups (and groups from Hangouts don't show up there) and broke Hangouts in Gmail since then (some conversation where the other person wrote the last message shows as unread the next time I open gmail).
Non-tech people like Facebook (et al). Understandable. Hell, tech people like Facebook.
Because of the social graph, understandably, I get it. You can't fight the compartmentalization of our previously open Internet, I guess.
Or maybe, at least developers know better.. ?
Turns out no. What annoys me to no end is when developers willingly crash right into this "electron react"-whatever hipster bullshit cause its "cool". We had IRC _thirty_ years ago. Slack is not cool. Sure, upgrades are in order for IRC. But it works. Slacks evaluation is so laughable. Obviously it is because of its data - that it won't share.
Anyway. We should know better. We should not willingly put everything into slack or hipchat or whatever. Why would we?
Ease of X, I guess.
Give me an api where I can sync all my stuff locally and, you know what, fair enough, go nuts, but these guys build their businesses based on holding on to their data like vultures (no surprises there) . Understandably. I just thought tech savvy people would know/do better.
Anyway, that's my two cents. I feel like a minority.. Now get of my lawn.
This both sucks and is great. Sucks for me. Hopefully will be great for Mattermost and Matrix.
For HIPAA compliant shops Slack is a non-starter. Mattermost will hopefully get a lot of corporate $ now. I wish Matrix's dendrite[0] golang replacement homeserver was finished and in better shape. I'd much prefer to go the Riot/Matrix route, but it doesn't feel ready for prime time yet.
HipChat Server was SPOF but could be made to be HIPAA compliant by hoisting their AMI out and encrypting the base image.
I literally was at the tail end of hacking Hipchat Data Center to be fully HIPAA compliant and HA using Vault, Consul (+locks), Terraform, scaling groups and friends. I was so excited about getting to blog about it. sigh
Looks like I'll be re-engaging Mattermost. Last time I looked their E20 pricing was like 4x more expensive per user than it was costing for HipChat DC. Hopefully they finished their HipChat importing option.
Hey, can you elaborate a touch on the lack of HIPAA compliance with Slack? Some folks on my team seem to think it's compliant - and I'm not finding true hard answers either way (ignoring the BAA side of things)
Slack showcases the HIPAA logo on their security page, but upon closer inspection - https://slack.com/terms-of-service/supplement#healthcare - you'll see that unless you've signed a separate agreement with them, you acknowledge that Slack is not HIPAA compliant and that you are not to send them any PHI. My guess: they are signing BAAs for grid customers only (so the logo isn't a lie) and making them pay handsomely for the pleasure.
As I shamelessly disclosed upthread, we (Trillian) offer a HITRUST certified, BAA-backed solution for healthcare organizations that comes in SaaS and on-prem variants. More: https://trillian.im/uses/hipaa-compliant-texting/
Our Corp IT requested engineering to Pilot Google Hangout Chats as we already have GSuite. Turns out that Slack is the most expensive enterprise application that IT owns. It is more expensive that GSuite, although it provides a specific utility, while GSuite has emails, spreadsheets, docs etc. etc. That doesn't really sounds sustainable.
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.