16 ms·

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 firewa

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.

merlincorey 8y ago
> Slack doesn't have an on-prem option. Microsoft Teams doesn't have an on-prem option. What are enterprises supposed to use, RocketChat? Matrix? With no clear migration path? Mattermost[1], with a clear migration path from Slack, at least. [1] https://mattermost.com/ https://mattermost.com/
- apple4ever 8y ago
  We use Slack now, and are looking to migrate to Mattermost (since we run GitLab already). We don't want to pay the price we'd need to pay to keep Slack, and plus we want to host our own.
  - jawilson2 8y ago
    We moved from Slack to Mattermost, and Mattermost is garbage. Messages are delivered late (by hours), if ever. You don't get notifications correctly. It takes seconds (more than 10 sometimes) to load a page. Sometimes the page goes blank. Much of our office has reverted to email and phone calls for many things that would have worked fine with Slack.
    - JeremyNT 8y ago
      I'll counter that anecdote with an observation that I have never observed any of those issues. In our deployment Mattermost is reliable and I've never heard any complaints like those from my colleagues. It could be a question of scale; we only have probably 50 or so regular users. That said, even though it works as advertised the product is not perfect. The Mattermost UI is bare bones and some things like conversation threading are implemented poorly.
      - it33 8y ago
        Thanks @JeremyNT! Mattermost team here. May I ask which Mattermost version you're running? Also, what features would you like to see? We ship new improvements monthly, so if you're on an older release you could quickly add a lot of features: emoji reactions, GIF selector, custom emojis, Slack-compatible keyboard shortcuts, hashtags, slash comments, Slack-compatible integrations, etc.
        _V_ 8y ago
        I, for one, would like to see normal package upgrade process - atleast for debian-based distros. I really don't like the current way of "copy old directory somewehere, copy a new one and replace some files from the old one". That is very painfull and this process does not really invoke a lot of confidence. edit: typo
        JeremyNT 8y ago
        We're on 4.10.1, so I think we have most if not all of what you mentioned. Thanks for the great open source product! I should be clear, my own UI complaints are minor, but I want to acknowledge that people expecting a 1:1 copy of Slack won't exactly find it. Mattermost works well for us, but I recognize that an enhanced UI with tight media integration must be important to many people, otherwise Slack would not have become as popular as it has. Threading is really the only gripe I have personally - I don't like how it works, and I don't use it much because of that. But then I also don't have any real observations about how it could be improved either, and not using it (and basically operating as if it's IRC) is a perfectly fine solution!
- solatic 8y ago
  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
  - sparkling 8y ago
    Hiding enterprise pricing is quite common for many SaaS companies.
    - solatic 8y ago
      And yet, Atlassian got as big as they did in large part because of transparent pricing. Because enterprise sales have such a long sales cycle, that transparent pricing gave people inside their enterprises the confidence to push for a product they knew their budget could afford, rather than spend large amounts of internal political capital getting colleagues to rally behind a solution that wasn't affordable for them to begin with. It makes adoption more risky and more difficult.
      - davnn 8y ago
        > And yet, Atlassian got as big as they did in large part because of transparent pricing. Who knows if that had any influence on their success?
        qaq 8y ago
        Hmm "everyone" for many "Enterprise" shops the spend on sales team is bigger than on software eng. so one of the reasons Atlassian was always profitable is they didn't have a sales team until they were huge.
        walterbell 8y ago
        This is widely accepted because they did not spend money on an enterprise sales team in their early years, yet saw enterprise adoption.
    - 8y ago
- Arathorn 8y ago
  Matrix also has migration paths from Slack, eg https://github.com/lampholder/concorde https://github.com/lampholder/concorde edit: also https://github.com/Cadair/skill-matrixslack https://github.com/Cadair/skill-matrixslack
  - ReverseCold 8y ago
    The matrix homeserver is... suboptimal. I'm running it for a personal instance (two users), and it's using insane amounts of RAM (4-8 GB) and still managing to lag (even though I gave it 4 cores on a Ryzen 2700X). Forget talking in a matrix.org room, even talking to people on other personal/single user servers isn't fully stable. There is a replacement homeserver (https://github.com/matrix-org/dendrite https://github.com/matrix-org/dendrite) but it's not done yet. Also, client support is awful. The only one I can reasonably tell a non-technical user to use is Riot - but that's somehow more resource hungry than the Slack desktop app. There are good ones, but they are either only for technical users (weechat) or are extremely barebones (nheko, quaternion).
    - Arathorn 8y ago
      Disclosure: i work on Matrix. We're basically doing nothing but fixing Synapse's performance problems currently, and improvements are on the horizon. We're late because we got sidetracked fixing flaws in the protocol, but as of the last few weeks we're back on perf again. So far we've sped up /sync by 2x and reduced CPU by about 20%, but the RAM improvements should land over the coming weeks unless we have further distractions. Meanwhile, on Riot, we're busy landing performance fixes which should make it much less resource hungry than Slack. These are literally landing as we speak: https://github.com/matrix-org/synapse/pull/2970 https://github.com/matrix-org/synapse/pull/2970, https://github.com/matrix-org/synapse/pull/3331 https://github.com/matrix-org/synapse/pull/3331 etc.
      - arendtio 8y ago
        Why is you current solution so ressource hungry? I mean, my 10-active-users off-the-shelf XMPP server (ejabberd) uses about 100MB RAM currently.
meritt 8y ago
> What are enterprises supposed to use? We run Mattermost on-prem. We've been quite happy with it. They have well-defined [1] migration plans for Slack, Hipchat, and others. [1] https://docs.mattermost.com/administration/migrating.html https://docs.mattermost.com/administration/migrating.html
- solatic 8y ago
  "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?
  - detaro 8y ago
    I don't think its fair to blame them on the failure of the solution you picked before, and nobody else will be able to handle better.
    - solatic 8y ago
      I'm not blaming Mattermost for Atlassian's choices, I'm saying, you can't really try to recruit dissatisfied HipChat customers with promises of a supported migration if you can't help HipChat customers de-facto migrate from their old product to your product.
      - lvillani 8y ago
        I read this as HipChat’s own export function having problems handling large amounts of data. I’m not sure how this is Mattermost’s fault.
        Karunamon 8y ago
        I'm not sure what they mean by "export function". Hipchat isn't "an application", it's a bunch of services running on a network of VMs. At the very least, Hipchat includes Elasticsearch and MySQL. Seems odd that they'd rely on any particular Hipchat API when they can rip that data out of the guts of the machine.
__sr__ 8y ago
Setup an old faishoned IRC server?
- __sr__ 8y ago
  There is also Zulip (https://zulipchat.com https://zulipchat.com)
  - dijit 8y ago
    Or matrix/riot?
  - solatic 8y ago
    Zulip actually seems to tick a lot of boxes for us, I'll see about bringing it in and spinning it up on a box. Thanks for the recommendation!
    - codezero 8y ago
      The threading concept in Zulip works really well. I haven't used it for work, but I would love to.
    - __sr__ 8y ago
      Happy to help! Disclaimer: I am not associated with Zulip in any way.
- paranoidrobot 8y ago
  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.
  - bluedino 8y ago
    Persistence can be created the the right proxy/helper and clients
rainbowmverse 8y ago
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.
- solatic 8y ago
  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.
  - rainbowmverse 8y ago
    It will be some time before the ActivityPub ecosystem is ready for the enterprise. I was putting it out there for companies that don't need that level of integration or have people who can build it.
mapgrep 8y ago
Would Keybase Teams fit the bill, with end to end encryption? Or has to be on-prem, even if encrypted, for your requirements? (I don't have any association with Keybase, I've just investigated this product as a Slack alternative.)
- solatic 8y ago
  Has to be on-prem if the networks are air-gapped. KB Teams also has a long way to go to meet feature-parity - channels, integrations, etc.
- floren 8y ago
  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>/
Alupis 8y ago
For on-prem, why not use a free and enterprise-quality XMPP server, like Openfire[1]? It's Java so runs just about anywhere, and with even relatively low resource allocations, you can support a large number of concurrent chats and group sessions. Plus, since XMPP is an Open Standard, you can use any XMPP complaint client of your choosing. Cisco embeds Openfire in a few of their enterprise products already (including Finesse), so you might have used it without even knowing. The IgniteRealtime community is pretty active and new releases come out regularly[2]. [1] https://www.igniterealtime.org/projects/openfire/ https://www.igniterealtime.org/projects/openfire/ [2] https://www.igniterealtime.org/index.jsp https://www.igniterealtime.org/index.jsp
- travbrack 8y ago
  The client-side story of XMPP is pretty bleak, especially if you're trying to get non-technical people to use it.
  - SamWhited 8y ago
    This is why we need specific services (like Slack or HipChat) that are XMPP but maintain their own ecosystem, clients, specific feature sets, etc. Then if you want to use third party clients (eg. for better accessibility, or because your platform isn't supported officially, etc.) you can, but if not you can use their clients. HipChat was almost this way (I used Mcabber with it extensively), but had just enough bits of the protocol that ignored the XMPP spec or were only accessible through a second non-XMPP channel that it was a bit annoying.
    - travbrack 8y ago
      It's a real shame that the industry has forsaken the protocol in favor of walled gardens.
      - nyconyco 8y ago
        We'll be trying to fix that by offering the XMPP "Team Chat" client that is much needed... https://nayego.net/ https://nayego.net/ you can subscribe if you want to see the preview.
rb808 8y ago
Skype for Business, works on prem. Matrix is probably good too. Confluence can be installed on prem already.
- hadrien01 8y ago
  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...
  - Uberphallus 8y ago
    It's so slow and buggy that sometimes it registers clicks I do on the chat window as if I did them on the contact search one and end up sending that funny meme to a multichat I created with 30 I don't know instead of the contact/tab I selected.
- toefraz 8y ago
  SfB is ok for one-to-one or one-to-few communication, but the chats are pure garbage.
- paulie_a 8y ago
  I consider Skype to be a dead product at this point.
quickthrower2 8y ago
We might have to revert to talking. Aahhhhh!
- steve1977 8y ago
  Or - yikes - doing work, instead of just communicating about work.
- gizmo385 8y ago
  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.
  - quickthrower2 8y ago
    Wasn't too serious But ... For distributed companies: email for async communications, phone for sync. If you need to bother someone immediately you might as well have a high bandwidth audio (or even video) call.
cypherg 8y ago
welcome to 2018
it33 8y ago
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.
- apple4ever 8y ago
  Gotta say, I love that the CEO is commenting here.
- SebKba 8y ago
  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.
colordrops 8y ago
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.
- tabbott 8y ago
  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.
  - colordrops 8y ago
    Or they could just leave it as is or rebrand it as Slack enterprise until they build a new version based on Slack.
    - mulcahey 8y ago
      the UI/UX is so different I'd be very surprised if they managed that
      - edwinnathaniel 8y ago
        See SKYPE for Business. replace('Lync', 'Skype') probably...
        nyconyco 8y ago
        Oh Mircosfot's strategy is the weirdest: OCS, Lync, Skype, Skype for Business, Teams, Yammer... People are just lost. Nayego is trying to hard build a HipChat-like client+server that is open source and based on XMPP. https://nayego.net/ https://nayego.net/ you can subscribe if you want to see a preview.
tabbott 8y ago
(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 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.
- AntonyGarand 8y ago
  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.
  - 8y ago
jrs95 8y ago
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.
- grantlmiller 8y ago
  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 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.
nichochar 8y ago
lol you thought boards that make the acquisition decisions give a shit about customers? Welcome to the world buddy, money is everythting
- dang 8y ago
  Please don't post unsubstantive comments here.
  - baud147258 8y ago
    Please don't post unsubstantive comments here.
    - dang 8y ago
      You have a point, but there's little alternative. I wrote about this recently, if anyone cares: https://news.ycombinator.com/item?id=17494243 https://news.ycombinator.com/item?id=17494243
      - baud147258 8y ago
        I was just making a poor attempt at a joke (which fell flat). I appreciate what you are doing and I thank you for your dedication.
frisco 8y ago
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.
- jwsec 8y ago
  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.
it33 8y ago
Mattermost CEO here. We're thinking of offering a special package for HipChat customers who want to stay on-prem using Mattermost. It's perhaps a mix of services, migration/import assistance and possibly a discount to our commercial version. Would such a package be interesting? For anyone who'd like to discuss outside of HN, please feel free to mail us at info at mattermost.com
- deleted 8y ago
  [deleted]
- konschubert 8y ago
  Hi, Off topic question and hopefully not perceived as mean: Why don't you type your email address with an @ ? Wouldn't you expect the higher conversion rate to outweigh the mostly theoretical increase in spam emails? Or is there another reason?
  - TeMPOraL 8y ago
    Higher conversion rate? This is a simple, age-old trick that eliminates most of the low-effort spambots (read: most of them, as there's enough money made there), while letting through any human that is smarter than an amoeba.
- solatic 8y ago
  Hey, I sent you guys an email - looking forward to hearing from you
  - it33 8y ago
    Thanks! Got the mail and responded, looking forward to discussing more.
- brey 8y ago
  Yes, I'd be interested. We're evaluating Slack, MS Teams and Mattermost as a successor to Hipchat. Something to move the needle commercially in favour of on-premise would be helpful in that evaluation.
std_throwaway 8y ago
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.
- rimliu 8y ago
  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.
  - haggy 8y ago
    100% this. As soon as you fork a project, you are now responsible for the evolution of it (even if that's just merging in upstream changes). It puts a large burden on engineering teams to track changes and maintain the fork.
    - std_throwaway 8y ago
      OpenOffice is dead but its fork, LibreOffice, lives on. You don't necessarily have to fork it, just the possibility of the fork changes the game. It means that the original maintainer cannot shut you down. If enough people deem a fork useful they can work together. Of course there's a cost associated with it. But how much is it compared to the risk of someone shutting a core element of your business down? You have to evaluate.
- pjmlp 8y ago
  Because business world discovered it was the only way to actually make money with open source, either by selling hardware or services.
freeone3000 8y ago
Microsoft Teams has on-prem support.
- matteuan 8y ago
  source?
jillesvangurp 8y ago
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.
- BjoernKW 8y ago
  > 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.
  - qaq 8y ago
    They also become much more attractive targets for APT since compromising say Slack is way more interesting than some avg. mid size shop.
flipp3r 8y ago
> Slack doesn't have an on-prem option. Yes it does, the thing is you have to talk to them to get it and it costs about 10 times as much as on-prem HipChat. The company I previously worked for switched to RocketChat for this reason (Slack asked ~100K vs HipChat ~10K). RocketChat is free but you'll have to manage it yourself.
M_Bakhtiari 8y ago
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.
paulydavis 8y ago
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?
derefr 8y ago
> 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?
ezoe 8y ago
The company who insist the on-premises relies on proprietary software? What are they thinking?
aninteger 8y ago
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.
- gizmo385 8y ago
  > 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.
vowelless 8y ago
On the other hand, could this be a signal that slack might be considering offering on prem ?
richardlblair 8y ago
Obv IRC bro (bring on the downvotes. What's karma for if you don't spend it sometimes??)
danny_taco 8y ago
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.
XavierLecomte 8y ago
Hi, I am Watcha CEO. Watcha may be an alternative to check: our solution is based on Matrix and thus can be deployed anywhere. Our added value: UI and specific functions, simple user onboarding, upgrade management... xavier@watcha.fr or visit https://watcha.im https://watcha.im
jwsec 8y ago
Wickr CEO here as well. My team is happy to welcome all HipChat users to the Wickr Pro platform. Unlike on Slack or elsewhere, your collaboration flows are end-to-end encrypted so no 3rd party including Wickr has access to your team data. We’re delighted to offer 100 free seats for HipChat teams looking for a secure team collaboration alternative. Your teams can spin up a Wickr Pro SaaS private network in minutes, free to trial for 30 days with flexibility to extend. Test drive our end-to-end encrypted messaging, secure channels, team/project rooms, file sharing for up to 5Gb, video conferencing/calling, screen sharing and enterprise-ready admin controls including SSO. Get started here: https://wickr.com/the-best-alternative-to-hipchat/ 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/ https://wickr.com/products/enterprise/ and we’ll get you on-boarded.

merlincorey 8y ago

> Slack doesn't have an on-prem option. Microsoft Teams doesn't have an on-prem option. What are enterprises supposed to use, RocketChat? Matrix? With no clear migration path? Mattermost[1], with a clear migration path from Slack, at least. [1] https://mattermost.com/ https://mattermost.com/

apple4ever 8y ago
We use Slack now, and are looking to migrate to Mattermost (since we run GitLab already). We don't want to pay the price we'd need to pay to keep Slack, and plus we want to host our own.
- jawilson2 8y ago
  We moved from Slack to Mattermost, and Mattermost is garbage. Messages are delivered late (by hours), if ever. You don't get notifications correctly. It takes seconds (more than 10 sometimes) to load a page. Sometimes the page goes blank. Much of our office has reverted to email and phone calls for many things that would have worked fine with Slack.
  - JeremyNT 8y ago
    I'll counter that anecdote with an observation that I have never observed any of those issues. In our deployment Mattermost is reliable and I've never heard any complaints like those from my colleagues. It could be a question of scale; we only have probably 50 or so regular users. That said, even though it works as advertised the product is not perfect. The Mattermost UI is bare bones and some things like conversation threading are implemented poorly.
    - it33 8y ago
      Thanks @JeremyNT! Mattermost team here. May I ask which Mattermost version you're running? Also, what features would you like to see? We ship new improvements monthly, so if you're on an older release you could quickly add a lot of features: emoji reactions, GIF selector, custom emojis, Slack-compatible keyboard shortcuts, hashtags, slash comments, Slack-compatible integrations, etc.
      - _V_ 8y ago
        I, for one, would like to see normal package upgrade process - atleast for debian-based distros. I really don't like the current way of "copy old directory somewehere, copy a new one and replace some files from the old one". That is very painfull and this process does not really invoke a lot of confidence. edit: typo
      - JeremyNT 8y ago
        We're on 4.10.1, so I think we have most if not all of what you mentioned. Thanks for the great open source product! I should be clear, my own UI complaints are minor, but I want to acknowledge that people expecting a 1:1 copy of Slack won't exactly find it. Mattermost works well for us, but I recognize that an enhanced UI with tight media integration must be important to many people, otherwise Slack would not have become as popular as it has. Threading is really the only gripe I have personally - I don't like how it works, and I don't use it much because of that. But then I also don't have any real observations about how it could be improved either, and not using it (and basically operating as if it's IRC) is a perfectly fine solution!
solatic 8y ago
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
- sparkling 8y ago
  Hiding enterprise pricing is quite common for many SaaS companies.
  - solatic 8y ago
    And yet, Atlassian got as big as they did in large part because of transparent pricing. Because enterprise sales have such a long sales cycle, that transparent pricing gave people inside their enterprises the confidence to push for a product they knew their budget could afford, rather than spend large amounts of internal political capital getting colleagues to rally behind a solution that wasn't affordable for them to begin with. It makes adoption more risky and more difficult.
    - davnn 8y ago
      > And yet, Atlassian got as big as they did in large part because of transparent pricing. Who knows if that had any influence on their success?
      - qaq 8y ago
        Hmm "everyone" for many "Enterprise" shops the spend on sales team is bigger than on software eng. so one of the reasons Atlassian was always profitable is they didn't have a sales team until they were huge.
      - walterbell 8y ago
        This is widely accepted because they did not spend money on an enterprise sales team in their early years, yet saw enterprise adoption.
  - 8y ago
Arathorn 8y ago
Matrix also has migration paths from Slack, eg https://github.com/lampholder/concorde https://github.com/lampholder/concorde edit: also https://github.com/Cadair/skill-matrixslack https://github.com/Cadair/skill-matrixslack
- ReverseCold 8y ago
  The matrix homeserver is... suboptimal. I'm running it for a personal instance (two users), and it's using insane amounts of RAM (4-8 GB) and still managing to lag (even though I gave it 4 cores on a Ryzen 2700X). Forget talking in a matrix.org room, even talking to people on other personal/single user servers isn't fully stable. There is a replacement homeserver (https://github.com/matrix-org/dendrite https://github.com/matrix-org/dendrite) but it's not done yet. Also, client support is awful. The only one I can reasonably tell a non-technical user to use is Riot - but that's somehow more resource hungry than the Slack desktop app. There are good ones, but they are either only for technical users (weechat) or are extremely barebones (nheko, quaternion).
  - Arathorn 8y ago
    Disclosure: i work on Matrix. We're basically doing nothing but fixing Synapse's performance problems currently, and improvements are on the horizon. We're late because we got sidetracked fixing flaws in the protocol, but as of the last few weeks we're back on perf again. So far we've sped up /sync by 2x and reduced CPU by about 20%, but the RAM improvements should land over the coming weeks unless we have further distractions. Meanwhile, on Riot, we're busy landing performance fixes which should make it much less resource hungry than Slack. These are literally landing as we speak: https://github.com/matrix-org/synapse/pull/2970 https://github.com/matrix-org/synapse/pull/2970, https://github.com/matrix-org/synapse/pull/3331 https://github.com/matrix-org/synapse/pull/3331 etc.
    - arendtio 8y ago
      Why is you current solution so ressource hungry? I mean, my 10-active-users off-the-shelf XMPP server (ejabberd) uses about 100MB RAM currently.

meritt 8y ago

> What are enterprises supposed to use? We run Mattermost on-prem. We've been quite happy with it. They have well-defined [1] migration plans for Slack, Hipchat, and others. [1] https://docs.mattermost.com/administration/migrating.html https://docs.mattermost.com/administration/migrating.html

solatic 8y ago
"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?
- detaro 8y ago
  I don't think its fair to blame them on the failure of the solution you picked before, and nobody else will be able to handle better.
  - solatic 8y ago
    I'm not blaming Mattermost for Atlassian's choices, I'm saying, you can't really try to recruit dissatisfied HipChat customers with promises of a supported migration if you can't help HipChat customers de-facto migrate from their old product to your product.
    - lvillani 8y ago
      I read this as HipChat’s own export function having problems handling large amounts of data. I’m not sure how this is Mattermost’s fault.
      - Karunamon 8y ago
        I'm not sure what they mean by "export function". Hipchat isn't "an application", it's a bunch of services running on a network of VMs. At the very least, Hipchat includes Elasticsearch and MySQL. Seems odd that they'd rely on any particular Hipchat API when they can rip that data out of the guts of the machine.

__sr__ 8y ago

Setup an old faishoned IRC server?

__sr__ 8y ago
There is also Zulip (https://zulipchat.com https://zulipchat.com)
- dijit 8y ago
  Or matrix/riot?
- solatic 8y ago
  Zulip actually seems to tick a lot of boxes for us, I'll see about bringing it in and spinning it up on a box. Thanks for the recommendation!
  - codezero 8y ago
    The threading concept in Zulip works really well. I haven't used it for work, but I would love to.
  - __sr__ 8y ago
    Happy to help! Disclaimer: I am not associated with Zulip in any way.
paranoidrobot 8y ago
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.
- bluedino 8y ago
  Persistence can be created the the right proxy/helper and clients

rainbowmverse 8y ago

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.

solatic 8y ago
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.
- rainbowmverse 8y ago
  It will be some time before the ActivityPub ecosystem is ready for the enterprise. I was putting it out there for companies that don't need that level of integration or have people who can build it.

mapgrep 8y ago

Would Keybase Teams fit the bill, with end to end encryption? Or has to be on-prem, even if encrypted, for your requirements? (I don't have any association with Keybase, I've just investigated this product as a Slack alternative.)

solatic 8y ago
Has to be on-prem if the networks are air-gapped. KB Teams also has a long way to go to meet feature-parity - channels, integrations, etc.
floren 8y ago
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>/

Alupis 8y ago

For on-prem, why not use a free and enterprise-quality XMPP server, like Openfire[1]? It's Java so runs just about anywhere, and with even relatively low resource allocations, you can support a large number of concurrent chats and group sessions. Plus, since XMPP is an Open Standard, you can use any XMPP complaint client of your choosing. Cisco embeds Openfire in a few of their enterprise products already (including Finesse), so you might have used it without even knowing. The IgniteRealtime community is pretty active and new releases come out regularly[2]. [1] https://www.igniterealtime.org/projects/openfire/ https://www.igniterealtime.org/projects/openfire/ [2] https://www.igniterealtime.org/index.jsp https://www.igniterealtime.org/index.jsp

travbrack 8y ago
The client-side story of XMPP is pretty bleak, especially if you're trying to get non-technical people to use it.
- SamWhited 8y ago
  This is why we need specific services (like Slack or HipChat) that are XMPP but maintain their own ecosystem, clients, specific feature sets, etc. Then if you want to use third party clients (eg. for better accessibility, or because your platform isn't supported officially, etc.) you can, but if not you can use their clients. HipChat was almost this way (I used Mcabber with it extensively), but had just enough bits of the protocol that ignored the XMPP spec or were only accessible through a second non-XMPP channel that it was a bit annoying.
  - travbrack 8y ago
    It's a real shame that the industry has forsaken the protocol in favor of walled gardens.
    - nyconyco 8y ago
      We'll be trying to fix that by offering the XMPP "Team Chat" client that is much needed... https://nayego.net/ https://nayego.net/ you can subscribe if you want to see the preview.

rb808 8y ago

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

hadrien01 8y ago
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...
- Uberphallus 8y ago
  It's so slow and buggy that sometimes it registers clicks I do on the chat window as if I did them on the contact search one and end up sending that funny meme to a multichat I created with 30 I don't know instead of the contact/tab I selected.
toefraz 8y ago
SfB is ok for one-to-one or one-to-few communication, but the chats are pure garbage.
paulie_a 8y ago
I consider Skype to be a dead product at this point.

quickthrower2 8y ago

We might have to revert to talking. Aahhhhh!

steve1977 8y ago
Or - yikes - doing work, instead of just communicating about work.
gizmo385 8y ago
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.
- quickthrower2 8y ago
  Wasn't too serious But ... For distributed companies: email for async communications, phone for sync. If you need to bother someone immediately you might as well have a high bandwidth audio (or even video) call.

cypherg 8y ago

welcome to 2018

it33 8y ago

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.

apple4ever 8y ago
Gotta say, I love that the CEO is commenting here.
SebKba 8y ago
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.

colordrops 8y ago

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.

tabbott 8y ago
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.
- colordrops 8y ago
  Or they could just leave it as is or rebrand it as Slack enterprise until they build a new version based on Slack.
  - mulcahey 8y ago
    the UI/UX is so different I'd be very surprised if they managed that
    - edwinnathaniel 8y ago
      See SKYPE for Business. replace('Lync', 'Skype') probably...
      - nyconyco 8y ago
        Oh Mircosfot's strategy is the weirdest: OCS, Lync, Skype, Skype for Business, Teams, Yammer... People are just lost. Nayego is trying to hard build a HipChat-like client+server that is open source and based on XMPP. https://nayego.net/ https://nayego.net/ you can subscribe if you want to see a preview.

tabbott 8y ago

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

AntonyGarand 8y ago
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.
- 8y ago

jrs95 8y ago

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.

grantlmiller 8y ago
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 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.

nichochar 8y ago

lol you thought boards that make the acquisition decisions give a shit about customers? Welcome to the world buddy, money is everythting

dang 8y ago
Please don't post unsubstantive comments here.
- baud147258 8y ago
  Please don't post unsubstantive comments here.
  - dang 8y ago
    You have a point, but there's little alternative. I wrote about this recently, if anyone cares: https://news.ycombinator.com/item?id=17494243 https://news.ycombinator.com/item?id=17494243
    - baud147258 8y ago
      I was just making a poor attempt at a joke (which fell flat). I appreciate what you are doing and I thank you for your dedication.

frisco 8y ago

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.

jwsec 8y ago
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.

it33 8y ago

Mattermost CEO here. We're thinking of offering a special package for HipChat customers who want to stay on-prem using Mattermost. It's perhaps a mix of services, migration/import assistance and possibly a discount to our commercial version. Would such a package be interesting? For anyone who'd like to discuss outside of HN, please feel free to mail us at info at mattermost.com

deleted 8y ago
[deleted]
konschubert 8y ago
Hi, Off topic question and hopefully not perceived as mean: Why don't you type your email address with an @ ? Wouldn't you expect the higher conversion rate to outweigh the mostly theoretical increase in spam emails? Or is there another reason?
- TeMPOraL 8y ago
  Higher conversion rate? This is a simple, age-old trick that eliminates most of the low-effort spambots (read: most of them, as there's enough money made there), while letting through any human that is smarter than an amoeba.
solatic 8y ago
Hey, I sent you guys an email - looking forward to hearing from you
- it33 8y ago
  Thanks! Got the mail and responded, looking forward to discussing more.
brey 8y ago
Yes, I'd be interested. We're evaluating Slack, MS Teams and Mattermost as a successor to Hipchat. Something to move the needle commercially in favour of on-premise would be helpful in that evaluation.

std_throwaway 8y ago

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.

rimliu 8y ago
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.
- haggy 8y ago
  100% this. As soon as you fork a project, you are now responsible for the evolution of it (even if that's just merging in upstream changes). It puts a large burden on engineering teams to track changes and maintain the fork.
  - std_throwaway 8y ago
    OpenOffice is dead but its fork, LibreOffice, lives on. You don't necessarily have to fork it, just the possibility of the fork changes the game. It means that the original maintainer cannot shut you down. If enough people deem a fork useful they can work together. Of course there's a cost associated with it. But how much is it compared to the risk of someone shutting a core element of your business down? You have to evaluate.
pjmlp 8y ago
Because business world discovered it was the only way to actually make money with open source, either by selling hardware or services.

freeone3000 8y ago

Microsoft Teams has on-prem support.

matteuan 8y ago
source?

jillesvangurp 8y ago

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.

BjoernKW 8y ago
> 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.
- qaq 8y ago
  They also become much more attractive targets for APT since compromising say Slack is way more interesting than some avg. mid size shop.

flipp3r 8y ago

> Slack doesn't have an on-prem option. Yes it does, the thing is you have to talk to them to get it and it costs about 10 times as much as on-prem HipChat. The company I previously worked for switched to RocketChat for this reason (Slack asked ~100K vs HipChat ~10K). RocketChat is free but you'll have to manage it yourself.

M_Bakhtiari 8y ago

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.

paulydavis 8y ago

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?

derefr 8y ago

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

ezoe 8y ago

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

aninteger 8y ago

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.

gizmo385 8y ago
> 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.

vowelless 8y ago

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

richardlblair 8y ago

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

danny_taco 8y ago

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.

XavierLecomte 8y ago

Hi, I am Watcha CEO. Watcha may be an alternative to check: our solution is based on Matrix and thus can be deployed anywhere. Our added value: UI and specific functions, simple user onboarding, upgrade management... xavier@watcha.fr or visit https://watcha.im https://watcha.im

jwsec 8y ago

Wickr CEO here as well. My team is happy to welcome all HipChat users to the Wickr Pro platform. Unlike on Slack or elsewhere, your collaboration flows are end-to-end encrypted so no 3rd party including Wickr has access to your team data. We’re delighted to offer 100 free seats for HipChat teams looking for a secure team collaboration alternative. Your teams can spin up a Wickr Pro SaaS private network in minutes, free to trial for 30 days with flexibility to extend. Test drive our end-to-end encrypted messaging, secure channels, team/project rooms, file sharing for up to 5Gb, video conferencing/calling, screen sharing and enterprise-ready admin controls including SSO. Get started here: https://wickr.com/the-best-alternative-to-hipchat/ 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/ https://wickr.com/products/enterprise/ and we’ll get you on-boarded.