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.
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!
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?
> 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
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.
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.
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
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].
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.
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.
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.
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...
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.
> 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.
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?
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).
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.
There are two camps: the we-should-just-use-irc camp, and the we-need-every-feature camp. You fall in to the former, and I would bet that a lot of people here fall in to the former.
However, many people fall in to the latter, and Slack handily beats the competition there. There is also an element of having nice and polished features baked in that appeals to many people. Want it on your phone? There's an app. Want to search? Baked in. Want convenient chat bots? Click a button.
To be sure, all these things are possible in IRC and other lo-fi chat protocols, but getting them set up is easy on Slack. I see this as similar to the argument of Linux vs. OSX. Linux can do practically anything OSX can, but it requires tweaking and setting up. It's a battle of pick-and-choose vs having it all baked in.
> There are two camps: the we-should-just-use-irc camp, and the we-need-every-feature camp.
I'm firmly in the "email should be used for substantive discussions" camp, but ever since we got the bandwidth and CPU necessary for the internet to not be a primarily text-based medium, the illiterates took over and that was the end of that.
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.
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).
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 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.
> 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 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.
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.
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.
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 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).
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.
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.
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.
If by "anti-competitive" you mean all of a sudden there's less competition, then yes it is although that's nothing unique, competing companies merge or make strategic deals all the time. But if you mean "anti-competitive" as in violating anti-trust laws then probably not given the amount of choice that still exists and the apparent lack of monopolistic strong-arm tactics being employed by either side. I'm no lawyer of course.
Edit: Original made it sound like I was suggesting the companies were merging, which isn't the case.
Despite slack being quite popular and truly a good product, Microsoft still has the upper hand. If you have the "Microsoft Suite" you get everything, access to all their products. Slack is fighting an uphill battle against Microsoft and eliminating Atlassian will help.
Dividing those who aren't diehard Microsoft fans won't help.
How is anything aside from legal infiltration going to make the playing field any less competitive? If we're all still playing by the same rules, there is still competition.
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).
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.
- 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
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.
> 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"
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.
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.
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.
Readit News
Slack doesn't have an on-prem option. Microsoft Teams doesn't have an on-prem option. What are enterprises supposed to use, RocketChat? Matrix? With no clear migration path?
Really poor move on Atlassian's part. It would be one thing to sell off Stride, it isn't doing well, work with Slack to have some kind of automated migration made available and let customers flip the switch. Maybe if Slack were to keep supporting Hipchat on-prem, or provide a migration path to a new Slack on-prem product, that'd be fine. But to leave HipChat on-prem customers out in the cold?
What's the next Atlassian on-prem product to get thrown under the bus? Bamboo for sure, it's been unpopular relative to Jenkins almost since its beginning. It's definitely surprising that Fisheye/Crucible get any support any more, or Crowd for that matter. But why not Confluence on-prem too? Do we have to worry that Atlassian will stop supporting Confluence on-prem in eight months because Office 365 keeps gaining marketshare?
Atlassian's continued long-term support for minor on-prem products was one of the signals that said, if you pay up for HipChat on-prem, we'll support you long-term, you'll be fine. Atlassian completely shattered that with this announcement and eroded a lot of trust that enterprises were putting in them. Big shot in the foot here.
It's perhaps a mix of services, migration/import assistance and possibly a discount to our commercial version.
Would such a package be interesting?
For anyone who'd like to discuss outside of HN, please feel free to mail us at info at mattermost.com
See https://news.ycombinator.com/item?id=17622987 (also on HN today) to learn more about how Zulip, or contact support@zulipchat.com if you're interested in our offer.
Recommended. And, a lot cheaper than Slack which is insanely expensive ($72/user/year) - of course it is not free as it takes up AWS server resources and DevOps time, but we control all our data and security now.
Something to move the needle commercially in favour of on-premise would be helpful in that evaluation.
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.
Deleted Comment
But there are technical challenges. Asking for help from open source community to see if we can work together to find an outstanding solution: https://medium.com/@mattermost/help-with-open-source-hipchat...
It seems to get better every few months, which is nice. Doesn’t feel like it’s sitting on its laurels.
Off topic question and hopefully not perceived as mean:
Why don't you type your email address with an @ ? Wouldn't you expect the higher conversion rate to outweigh the mostly theoretical increase in spam emails? Or is there another reason?
Deleted Comment
Mattermost[1], with a clear migration path from Slack, at least.
[1] https://mattermost.com/
We don't want to pay the price we'd need to pay to keep Slack, and plus we want to host our own.
edit: also https://github.com/Cadair/skill-matrixslack
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.
Those who really want to do on premise, will find their way to one of several niche products in this space. But I don't think any of these players will grab a lot of market share. Ultimately anything run on site is going to be expensive to support and why bother when you get cloud based offerings. Compliance issues can be addressed in the cloud as well.
Absolutely. Depending on how an organization manages its own IT security, data can even be more secure in the cloud than it would be on premises.
Decent providers like Atlassian invest in their IT security and employ dedicated security experts, something that can't be said of all organizations that host their software on premises.
However, I think in some cases being able to run specific software on premises is still a valid concern. Compliance is only one possible reason. Being able to easily access your data outside of the vendor's software might be another.
While they can be addressed, alleviating compliance concerns often is no easy task either, especially if your organization has to comply with laws and regulations from different jurisdictions. For example, I know of one organization where developers are allowed to use most Amazon services but are explicitly forbidden to use Amazon SES because that service currently is only available in a region that's technically outside (EU but not the same member state) of the jurisdiction the organization is in.
How can I guarantee the security of my customers data, if it's not hosted on equipment I control?
Mail us at info at mattermost.com? // and this is an open invite to any HipChat users who want to keep data under IT control.
Regarding importing from HipChat, while it is tricky as the data is within HipChat's VMs and not documented, we can potentially work with you to move over smoothly.
The good news is if you switch to Mattermost we run as a single Linux binary with MySQL or PostgreSQL, so using us you have 100% access to your data as well as the source code to understand everything we do with the data.
It's Java so runs just about anywhere, and with even relatively low resource allocations, you can support a large number of concurrent chats and group sessions. Plus, since XMPP is an Open Standard, you can use any XMPP complaint client of your choosing.
Cisco embeds Openfire in a few of their enterprise products already (including Finesse), so you might have used it without even knowing.
The IgniteRealtime community is pretty active and new releases come out regularly[2].
[1] https://www.igniterealtime.org/projects/openfire/
[2] https://www.igniterealtime.org/index.jsp
Also, I don't like the fact that it's person based whereas mattermost (and IRC) are group based that also allows person based chat.
The writing's been on the wall for HipChat for a long time; e.g. the user experience has been stagnant for many years (e.g. they never added emoji reactions). And even back in 2013, every HipChat customer I've encountered was unhappy or at best unenthusiastic about the product. So we've seen plenty of folks migrate from HipChat to Zulip.
I expect most enterprises will end up on one of the open source Slack alternatives (Zulip, Mattermost, Rocket.Chat, etc.). Frankly, they should have been using one of them anyway. If you care about a really high level of security, you want to be using well-maintained open source software. The well-maintained part is obvious, but the open source piece is really important too: It's a lot easier for white-hat hackers to find and report security bugs in software with access to the source code, and so there will be fewer that haven't been found and fixed yet.
You certainly don't want to be using a PHP app that's had over 700 confirmed security bugs found by external people (https://hackerone.com/slack) -- you can be pretty sure there are more being introduced every week.
I'll add that I expect to see more proprietary on-premise products that are the stepchild of a SaaS product disappearing over the coming years. It's a lot harder to ship software for the on-premise use case, especially if you have engineering culture used to just shipping for a single installation in the cloud (which almost everyone who works on proprietary software is). If you have the right processes and toolchain, it doesn't have to slow you down (and I don't feel it does for Zulip, with our amazing developer tooling and 98% backend test coverage), but very few organizations succeed at this. I've certainly heard some incredible horror stories from famous Silicon Valley companies about teams of engineers spending months on making a fork of a SaaS product shippable for each on-premise release.
That being said, it’s unfortunate that OSS in many areas lags behind proprietary software in so many different areas, and it’s clear that for many different business use cases properietary cloud services are going to be more cost effective than OSS. As the deployment and ops aspects of software becomes more automated and simplified, I think this might begin to start shifting back in favor of OSS though.
You can always make the argument that for this reason we should only write our own internal tools and use OSS. However, it is just as easy for an OSS project to be abandoned or neglected. Often times enterprise contracts will have a source code escrow clause that provide the enterprise with the source code in the event of a shut down (the same capabilities as a fork & take over maintenance anyway).
We don't actually know the plan for HipChat On-prem yet (do we?). Slack and Atlassian are both known for being customer centric so they will probably follow what Facebook did with Parse. Open source the entire thing, sunset the operations and development over the course of a year or two with minimal security updates/patches and no feature dev. This could be what the investment from Atlassian was tagged for... to make sure their customers are taken care of while most migrate to Slack.
Yes it does, the thing is you have to talk to them to get it and it costs about 10 times as much as on-prem HipChat.
The company I previously worked for switched to RocketChat for this reason (Slack asked ~100K vs HipChat ~10K). RocketChat is free but you'll have to manage it yourself.
My team is happy to welcome all HipChat users to the Wickr Pro platform. Unlike on Slack or elsewhere, your collaboration flows are end-to-end encrypted so no 3rd party including Wickr has access to your team data.
We’re delighted to offer 100 free seats for HipChat teams looking for a secure team collaboration alternative. Your teams can spin up a Wickr Pro SaaS private network in minutes, free to trial for 30 days with flexibility to extend.
Test drive our end-to-end encrypted messaging, secure channels, team/project rooms, file sharing for up to 5Gb, video conferencing/calling, screen sharing and enterprise-ready admin controls including SSO.
Get started here: https://wickr.com/the-best-alternative-to-hipchat/
If you need ON-PREM deployment, let my team know here, they can help you seamlessly navigate your transition from HipChat: https://wickr.com/products/enterprise/ and we’ll get you on-boarded.
(I don't have any association with Keybase, I've just investigated this product as a Slack alternative.)
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.
As for Microsoft Teams, they don't have to be on premise since all the big corporations that use on-premise only have for the most part adopted Microsoft 360.
Our added value: UI and specific functions, simple user onboarding, upgrade management...
xavier@watcha.fr or visit https://watcha.im
It'd be a lot less work to fork Slack and make it work on-premise than do something with HipChat. And that's saying a lot: forking Slack to make it run well on-premise would likely be an enormous project.
> As a result of this partnership, Atlassian is discontinuing all real-time communications products, and we are working with Slack to provide a migration path for Stride and Hipchat customers.
They provide dates for shuttering everything. Stride and Hipchat Cloud are shuttering Feb 2019. The latest version of Hipchat Server will be supported until June 2020.
The 2 products aren't merging, so far as I am aware. Slack is buying Hipchat and then promptly discontinuing support for it. It's primarily a move to eliminate competition, not to acquire technology.
We run Mattermost on-prem. We've been quite happy with it. They have well-defined [1] migration plans for Slack, Hipchat, and others.
[1] https://docs.mattermost.com/administration/migrating.html
They're kidding, right? That's a well-defined migration plan?
It should be simple enough, since you're operating on a negligible scale when it's on premise.
Dead Comment
(bring on the downvotes. What's karma for if you don't spend it sometimes??)
Ahem:
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?
This is a step in corporate IT that I really cannot fully understand. It seems that every company//startup has to use slack nowadays to pretend to be cool again.
Everytime I have a serious conversation about the productivity gains or losses of Slack though, it is pretty clear to me that it is more disruptive than helpful. It fosters a "Always on" culture, where irrelevant chats are exchanged publicly to advertise how much work is being done. If you shut down Slack and appear as Offline people assume you are not working.
It also seems to me that now that Slack became the norm for communication, I almost don't receive well written emails with well-argued technical discussions anymore. Everything is now a "Chat" that dilutes the technical discussion because it needs to be responded "directly".
I would expect 2018 to be the year where people start questioning the utility of "Slack everywhere" and not blindly jump on the Slack bandwagon because that's what great startups do.
When used properly (not lazily), Slack is a great place to organize communication between teams. At worst its Skype with a way better UI...what's wrong with that?
* it has a history I can actually search. Skype used to have this, but removed it when they rewrote it in Electron. !@#$ you to whoever at Microsoft decided to get rid of that; I used chat history search every day as part of my workflow.
* it has an API/plugin ecosystem. Admittedly, that's a walled garden so it's a double-edged sword. But for businesses that's awesome. Skype used to have an API but that's been deprecated. Conjecture: from abuse?
* it has security. I can log on to a private Slack and know that the people in there belong there. I can search for people on Slack and know that I'm communicating with who I intended to communicate. On Skype, you search for your coworker by typing in their name and you end up finding some other person instead. Hope you didn't just reveal corporate secrets to China.
Slack doesn't come without its own set of gripes, for sure. Let me enumerate some of them:
* Information density isn't configurable. I want a teeny tiny font. It's better than what Skype has become but still not as configurable as chat clients from the 90's
* Resource hog. Seriously, we've gone so far backwards it's appalling. Chat clients from the 90s didn't need anywhere near as much memory or CPU as Electron does and they were just as functional (sans audio/video/link preview).
I'm sure there's others but I'm tired
However, many people fall in to the latter, and Slack handily beats the competition there. There is also an element of having nice and polished features baked in that appeals to many people. Want it on your phone? There's an app. Want to search? Baked in. Want convenient chat bots? Click a button.
To be sure, all these things are possible in IRC and other lo-fi chat protocols, but getting them set up is easy on Slack. I see this as similar to the argument of Linux vs. OSX. Linux can do practically anything OSX can, but it requires tweaking and setting up. It's a battle of pick-and-choose vs having it all baked in.
I'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.
If I want high latency, high bandwidth, there's email. If I need low latency, high bandwidth, that's an in person whiteboard session or a video call.
That does mean I think Slack is overhyped... but that also means I think Slack does something valuable. Just maybe not as valuable.
1. No markdown support and half-assed code highlighting support. 2. No (real) message editing. 3. Silly parenthesis based emoji.
Its search is better than Slack’s; its performance is better than Slack’s; its integrations are better than Slack’s; its client memory and CPU usage are better than Slack’s (whether in a tab or as a real, native app); its group video chat is better than Slack’s (does Slack even have video chat integrated, with screen sharing?). Most importantly for us, its price was 4x better than Slack’s all while offering better features, performance, etc. The only thing it didn’t win out on was hype. (It should also be noted that HipChat could also be bought in a self-hosted configuration, which allowed for HIPAA compliance, something that Slack won’t even bother competing on. I didn’t need it, but hey, it matters to some people.)
Slack is an overpriced distraction monkey. They’re selling it like it’s the whole enchilada, but it’s a damned feature bullet. I personally cannot wait until Slack is dead, because it’s the worst chat service I’ve ever used (and I love full-featured integrations).
Now, I have to find a replacement for HipChat that won’t cost us US$200 per month for our office (if we pay a year in advance, more if we don’t).
I challenge you to consider whether your perspective applies to the 99% of people who use Slack that are not developers writing software. For those people, email is often not a place where well-argued discussions happen. It's usually a place where chat-like communication happens, slowly, and in an ill-fitting interface. For non-developers, let's take a operations associate for example or a logistics manager, or someone else whose job is to coordinate and communicate frequently, Slack plays a very different role than it does for devs.
Unfortunately for you, and others like you who don't like Slack, if 99% of your company wants to use it, you'll almost certainly get pulled in. Unless your department or team explicitly opts-out, you'll get pulled into the same platform the rest of the company is using.
This isn't to say you're wrong -- just to say that we must not judge the hype around Slack, or it's clear successes, as a fad if we're only judging it based on the experiences of the kinds of people who frequent HN.
Not sure what it is about HN assuming software devs are somehow intellectually and professionally superior to others.
So, the tens of thousands of teams paying for Slack either aren't having serious conversations or have decided the opposite. Here are some things I think you are undervaluing about team chat:
- It replaces many meetings and phone calls that are more interruptive. - It helps distributed teams with legitimate needs for casual collaboration. - It reduces an enormous cost of people being blocked waiting for email answers to simple questions that could not be anticipated.
The disadvantages of team chat can be avoided by discipline, but the benefits above require an assistive tool.
While we are at it, if you can't distinguish Slack from other team chat solutions, here are some things I think you are undervaluing:
- ease of onboarding for teams and individual users - scalability to large, active teams - Enterprise IT management - automatic refunds for inactive users - integration and third party app community - Dev community supporting custom integrations - strong mobile and desktop experiences
All of the above are super important for companies adopting, even though they're not about the core channel-messaging interaction you experience day to day. None of the alternatives check all of these boxes, and only teams is close.
I'm a dev at Flock, and an ex-user of Slack in my previous company, I hardly miss anything Slack had that isn't there on Flock!
If you're looking for a product built by top MIT engineers who spent years thinking about how to make chat actually productive, check out Zulip. I'm one of those MIT engineers, and I agree that Slack is a huge waste of time, for precisely the reasons you describe (here's our attempt at explaining how Slack wastes your time: https://zulipchat.com/why-zulip/, and how Zulip solves those problems; there's more on our homepage).
The fact that Slack is, in most organizations, either very low-traffic or a waste of time is why we don't market Zulip primarily as "open source Slack" -- it really is a different product, designed to be amazing for a large, distributed team doing a lot of communication, without things becoming overwhelming.
If you don't believe me, read this awesome cartoon by one of our users: https://twitter.com/b0rk/status/986444234365521920
(As another reason for Slack's success, I'll also add that a lot of "Slack clone" products are pretty buggy; everyone underestimates how much work a high-quality chat experience is. Check out https://zulip.readthedocs.io/en/latest/subsystems/markdown.h... and https://zulip.readthedocs.io/en/latest/subsystems/events-sys... if you want to learn about the complexity of a few of the more interesting challenges.)
But the flat thread model is still limited, particularly for complicated topics even a thread starts having the same problem as a channel where there is too much going on; have you thought about tree-structured threads, or some way of branching threads when there is a bunch of discussion happening on different topics?
I haven't really used Slack much, but one of the other places with lots of space for improvement in Flowdock was search, and Slack does seem to be investing there significantly, and I hope Zulip is as well.
When Slack is down for a few hours, I know start-ups that feel it in the gut.
As a social tool, Slack is one among many, but social tools for work are becoming huge because they enable passive knowledge transfer. Employees can spy on others' conversations to see who knows what and that knowledge makes companies more efficient.
Something's lost and something's gained in living every day, but Slack isn't a fad and it's not going anywhere.
Slack didn't invent those qualities. It's not unique in that regard.
What Slack does do better than most is provide a half decent interface for real time chat amongst groups of people. Personally I'd prefer vanilla IRC because I'd then get to chose my chat client but in terms of official clients go by, Slack is better than most (though that's really more of a criticism about Skype, email, etc than a compliment to Slack. I mean how is it that so many collaborative tools have such poorly designed UIs?)
The rest is a cultural problem that exists will all communication channels (including email). Ask people to be mindful and not use @channel all of the time (you can disable @channel if it is abused). Ask people to keep their chats to relevant channels. e.g. Daily interesting links do not belong in #general, please keep it to #random. Stuff like that.
Also, encourage people to move long complicated topics to a thread (to not annoy everyone in the room). Or ask them to compose a larger email or wiki page on the topic.
There's like 3000 people in there. Sometimes shitloads of conversations are happening at once. The people that refuse to use threads aren't cool, they're just co-opting literally the entire channel for just their conversation.
I see it as a forum, where you browse threads and click into the ones you want to discuss in. I guess other people see it as a bloodless Colosseum, may the loudest win.
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.
Hipchat did this amazingly well. There was a strong guarantee that a notification would be delivered - either email or app.
I don't think a lot of others do it well. It seems that everyone is mucking about threads and UI and emojis.
Its one of the best marketing coups in recent history and I'd love to see more analysis on how it was pulled off.
I parachuted into an org which had a not-great email culture and took up Slack as a replacement. It was amazingly great.
As an early employee of a startup, I remember the day we had to setup the initial infrastructure. For the majority in the room, Slack was an absolute requirement. They didn't wanted to have the ability to chat, they wanted to specifically use Slack, like a badge of honor.
Steward Butterfield pushed private beta invites to his well connected Silicon Valley social media friends, who then imposed it in their startups because “it’s what everyone else is doing, it’s going to revolutionize communication”. Rinse, repeat.
Source: a social media ninja wizard friend of Butterfield worked in the same startup as I did in the private beta days. I found it to be yet another internal chat app at the time, but my CEO drank the kool aid right away.
* You can respond in a delayed manner and not appear rude.
* Complex stuff can be previewed before submission.
* The subject and thread organization adds more fine-grained control than you usually get with Slack channels. The #team-name channel might have discussions on several topics at once, not all of which affect you, and no easy way to filter them. On a message board, it's easy to break out a new thread even if people are subscribed to it by default.
* Slack search is ugly because you come back two months later and have to pull the info out of a tangled discussion with unrelated stuff in the middle.
And part of the hype might be how easy it is to add emojis and have a little fun. It's important, too.
This past year at Inbox Awesome, one of Slack's team leads asked the audience how many there used Slack. Of the 300 or so people there, around 75% raised their hands. Next he asked for a show of hands on how many people felt that Slack made them more productive. Not a single person raised their hand. It's on video at around 17:30 here:
https://livestream.com/accounts/9197973/events/7910977/video...
• Gchat was effectively deprecated
• AIM is gone
You might be surprised how many companies now use Slack that have NOTHING to do with IT an/or software: everything form PR agencies to manufacturing.
I wouldn't be surprised if half of Slacks user base is now people who were using Gchat or AIM. All the major players who offered free chat basically got out, and Slack was kind of the cheapest cross-platform alternative. Even at the end of it's life million of people still used AIM daily for work, and then it suddenly went kaput.
And with respect, you cannot speak to any culture other than the few you've been a part of. I can say with some authority that this is not a problem at my workplace.
The reason IM has proliferated is precisely because it's instant and usually targeted. Email is a pain in the ass and usually serves as a dumping ground for irrelevant messages. If your culture demands that you treat a fundamentally asynchronous tool as synchronous, that's a problem with your culture, not the tool.
I see it as something similar to the rise of open-spaces. Now there is a backslash against it because people finally realize that it was overhyped and that open-spaces are maybe not always that good.
Regarding emails, I disagree with you. It is still my go-to channel for deep technical discussions on difficult subjects on which you need to reflect. With emails, I have no pressure to respond directly. When I respond, I will write multiple well constructed paragraphs where I explain why I would do this or this technical choice. Emails are archived easily and can be reread and referenced later.
Slack is a dumping ground of irrelevant messages, the opposite of your experience.
I would not hold my breath.
There's one side of it that's less organised then a proper email chain. There's the other side that replaces the physical water-cooler and allows people to join public conversations they'd otherwise not be aware of.
IRC is great and I am using it for 14+ years already. It's stable, fast, efficient and secure with lots of options. I've written a lot of IRC bots in many languages because protocol is so easy and every language have library/bot for IRC that can be easily expanded with your logic/code.
Before there was a cloud and big data, we used IRC for handling distributed services as high availability central orchestration to which many services/servers connected that had IRC bots running on them. We had control over many machines and services from IRC channels, with full authorization/authentication, logging channels, you could run commands on one server or on many same time, you've seen real time error reporting or when node went down.
It worked great and still works great.
I used to run IRC on the server in the screen session, but this is unusable on mobile. And setting up properly was a total PITA.
Slack is great. I don't need to waste time writing bots because all of the tools I use already have simple integrations: GitHub, Box, DropBox, Intercom, etc. Doing all of that within IRC is a pain. For example: responding to an Intercom conversation from within Slack. I can set up Slack for an org in literally minutes. With IRC? Not literally minutes.
Deleted Comment
A lot of conversations which happen in a workplace revolve around these tools, and have updates in one place not only save time but also encourage conversations around these updates.
Disclaimer: I work for Flock, an alternative to Slack. We are currently rated as #1 slack alternative on Product Hunt and PC Mag.We have a import tool so that you can import all of your data from HipChat on to Flock.
IRC, MSN Messenger, AIM, and Yahoo Chat were definitely used by both groups. None of them required a lot of resources to run.
This is once again entirely up to the business that deploys it. We use Slack and punish people who use Slack as a project management tool; we have Basecamp for that.
It comes to setting boundaries and consent, which is something en vogue in the 21st century and something I guess a lot of humans didn't get trained on when they were young.
But yes, the thing I hate is the expectation that I'm monitoring it or have notifications firing. Notifications are off all the time. If you need to tell me something important either email me or come and tell me. Slack is not the place for that.
I like Slack as a chat product, but it's very far from a productivity tool. It's often a productivity nightmare that operates to interrupt deep productive creative work.
Slacks API and number of systems with built in integrations blows the competition away.
Sure phpbb is a little clunky but at least I can use it as a knowledgebase.
Newsgroups were far better than phpbb :), and they were more easy to search IME.
I am regularly Cc'd into conversations that have 10 or so people and multiple topics lasting a week.
Deleted Comment
Search is pretty good too
Dead Comment
Anyone can buy a pair of pants. Look beyond the functionality to understand why people do things. It can be social signaling, wanting to be part of a crowd, or dozens of other reasons.
My wife is an architect. She made me see this.
Wait a second... what's the alternative to pants?? :p
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.
Similarly, I personally find the bundling->anticompetitive argument very unconvincing, especially given G-suite and other players in the cloud office space, especially in this context as atlassian's business model "rhymes" pretty heavily.
(As always disclaimer all opinions are my own, etc etc)
I 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.
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.
Edit: Original made it sound like I was suggesting the companies were merging, which isn't the case.
https://www.youtube.com/watch?v=z6K8PZxyQfU
https://www.youtube.com/watch?v=UUzvo4HwojU
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.
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).
Anticompetitive practices aren't illegal though. They are only illegal if a company has a monopoly or has significant market power.
Now, the question we have to ask is is Slack a near monopoly in it's marketspace? Maybe. I could see the argument go either way.
> Slack will pay an undisclosed amount over the next three years to acquire Atlassian’s HipChat and Stride products
Like if my neighbors and coworkers and friends use Slack, I'm not sure if they're a proxy of the entire market.
The reason I say that is because there are other apps that do similar things that hail from Microsoft, Google and Facebook.
Then the retort goes: well they don't do integrations and aren't as developer focused as Slack and Hipchat.
Then, naturally, wouldn't that incentivize those other apps already in the market to build out those features, and do it better?
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.
- 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!
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.
- 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.
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.
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.
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.
This!
It’s really an organizational problem, not the tool.
[1] https://clubhouse.io
Dead Comment
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.
Strange quote.
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.
https://sheenaiyengar.com/the-art-of-choosing/
And it's very good for the company, as they don't need to do as much competition with HipChat so they can slow down innovation and raise prices. Win, win.
It's 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.
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.