Hacker News Reader

Comment by solatic | Hacker News Reader

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.

View on HN

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

It's perhaps a mix of services, migration/import assistance and possibly a discount to our commercial version.

Would such a package be interesting?

For anyone who'd like to discuss outside of HN, please feel free to mail us at info at mattermost.com

Hi,

Off topic question and hopefully not perceived as mean:

Why don't you type your email address with an @ ? Wouldn't you expect the higher conversion rate to outweigh the mostly theoretical increase in spam emails? Or is there another reason?

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

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

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

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

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

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

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

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

I'm pretty sure it's spam.

I found a link, but it only has a README

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

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

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

Impeccable timing.

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

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

Recommended. And, a lot cheaper than Slack which is insanely expensive ($72/user/year) - of course it is not free as it takes up AWS server resources and DevOps time, but we control all our data and security now.

> We tied it into our AD

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

98% likely that they do.

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

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

I understand you need to have different features for the different packages, but I think this is a feature that should be available for smaller businesses. The g suite is affordable for small businesses and startups, and I doubt it is particularly difficult to implement, so I suggest including it at a lower price point.

For me it’s not even worth continuing the trial without it.

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

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

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

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

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

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

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

But there are technical challenges. Asking for help from open source community to see if we can work together to find an outstanding solution: https://medium.com/@mattermost/help-with-open-source-hipchat...

> Slack doesn't have an on-prem option. Microsoft Teams doesn't have an on-prem option. What are enterprises supposed to use, RocketChat? Matrix? With no clear migration path?

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

[1] https://mattermost.com/

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

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

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

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

That said, even though it works as advertised the product is not perfect. The Mattermost UI is bare bones and some things like conversation threading are implemented poorly.

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

We ship new improvements monthly, so if you're on an older release you could quickly add a lot of features: emoji reactions, GIF selector, custom emojis, Slack-compatible keyboard shortcuts, hashtags, slash comments, Slack-compatible integrations, etc.

I, for one, would like to see normal package upgrade process - atleast for debian-based distros.

I really don't like the current way of "copy old directory somewehere, copy a new one and replace some files from the old one". That is very painfull and this process does not really invoke a lot of confidence.

edit: typo

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

I should be clear, my own UI complaints are minor, but I want to acknowledge that people expecting a 1:1 copy of Slack won't exactly find it. Mattermost works well for us, but I recognize that an enhanced UI with tight media integration must be important to many people, otherwise Slack would not have become as popular as it has.

Threading is really the only gripe I have personally - I don't like how it works, and I don't use it much because of that. But then I also don't have any real observations about how it could be improved either, and not using it (and basically operating as if it's IRC) is a perfectly fine solution!

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

For instance, I try to search for "pass" hoping to dig out the password someone pasted and it shows results containing words like "wordpress" and "css" that petty much buries the actual matches even if they're somewhere way down in the result.

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

a) When you hit "Refresh" on your browser, do new messages appear?

b) Do you ever get blue bar message reading "Please check connection, Mattermost unreachable. If issue persists, ask administrator to check WebSocket port."?

If so for either of these, here's a solution you can send to your IT Admin: https://docs.mattermost.com/install/troubleshooting.html#ple...

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

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

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

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

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

Approx how many users?

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

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

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

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

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

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

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

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

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

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

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

1. The contact list interface lacks in a couple obvious ways. At the top there is an "Unreads" list, except there is a different unread list depending on which Team you're in. Except maybe it's not different, because unread Direct Messages will always appear in Unread, but unread Channels will only appear in their Team. There's also no option to sort anything contact-related: you have to have your Channels at the top (Public, Private), then your Direct Messages, subsorted alphabetically. (In particular, you can't sort by "most recent", so if you're chatting with 5 people during the day and you have 40 people in your DM list up, good luck finding them after they're marked as read.)

2. There is a keyboard shortcut for "Switch Channels" (Command-K), which you can use to send a DM to someone—but you can't use it to send a DM to two people at once (ie. typing Command-K+"alice" sends a DM to Alice, but typing Command-K+ "alice, bob" does nothing).

3. It's incredible that the native client will mark you as "Away" when you're working on your computer if the Mattermost app is not in focus.

4. I guess this is hard to get around given that there are slash-commands, but if I had a dime for every time I tried to paste a path and Mattermost said "Command with a trigger of '/home/shivatron/foo' not found...", I'd be a rich man.

5. Speaking of paste, I'm glad the message character limit got increased from 4000 to ~16k in 5.0. Does it offer to automagically truncate like Slack, or do I still have to delete some characters and try again in a loop until the message sends?

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

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

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

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

Disclaimer:  I'm from Flock ( https://flock.com ) . It’s currently rated the #1 slack alternative on PC Mag(https://goo.gl/eGZqH8). We've also created a tool to help you quickly import all your team data from HipChat to Flock in case you're interested in trying us out. Please let me know if you have any queries !

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

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

Hiding enterprise pricing is quite common for many SaaS companies.

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

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

Who knows if that had any influence on their success?

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

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

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

It's the only way to run a business.

Everyone has different needs, different existing environments, different service expectations+++

So you can't effectively stick to one price for the "large" tier. Given the differences in complexity and capacity consultants are needed. Startups can't build in-house service teams - the economics are misaligned. Not that you can get away from consultants if you buy from Salesforce, Oracle, SAP, or IBM...

Plus there are issues in terms of pricing and domain expertise across different industries - Federal, Education, Health.. legal issues in what your pricing can be and serious issues around their compliance environment means you need different teams of people to serve different verticals.

If you really need HA you are going to call anyways to negotiate. No one puts 15000 licenses on a credit card.

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

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

Since there aren't that many true enterprises that will allow you to test public prices like you can with consumer and SMB products, you have to go private.

The political dynamics you mention apply to developer pull products but you can easily fix that by calling or sending an email. In many Enterprise cases you want to talk to a VP or CXO for a full deployment and the free and medium offers cover the developer pull demand. If you really don't want to talk to sales AND you can spend $500k+ a year, you're a very rare case.

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

Yes. But one can easily find creative solutions.

Why not communicate using a made-up or real life anonymized case-study? Example: For <n> people organization, with an environment of type <description>, it typically costs <$x> per user. To be really effective give 2, 3 such example scenarios.

Potential customers would be more than happy to extrapolate from this data to start their internal discussions.

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

s/extrapolate from/fixate on/.

Seriously, even made up "anchors" for potential enterprise pricing have a tendency to really severely mess up purchase negotiations--for both the vendor (losing them sales when the customer says "it's going to cost four times the example number for a company our size because we need it to integrate with our bespoke, ancient CMS/IAM solution? Hard pass!") and the customer ("this was supposed to be a productivity adder, but since it won't integrate with our bespoke, ancient CMS/IAM solution at a price we can afford, we'll have to train everyone on new processes and duplicate data/access credentials all over the place, making it a time waster and security hole.").

Number of employees and environment type (whatever that means) are not indicative of enough common scenarios in the large-enterprise space to be used to automate pricing decisions.

That's not a statement in favor of opaque pricing or service-provider-highway-robbery; just an observation of the real complexities of big (and often old), unique businesses.

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

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

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

There is a replacement homeserver (https://github.com/matrix-org/dendrite) but it's not done yet.

Also, client support is awful. The only one I can reasonably tell a non-technical user to use is Riot - but that's somehow more resource hungry than the Slack desktop app. There are good ones, but they are either only for technical users (weechat) or are extremely barebones (nheko, quaternion).

Disclosure: i work on Matrix.

We're basically doing nothing but fixing Synapse's performance problems currently, and improvements are on the horizon. We're late because we got sidetracked fixing flaws in the protocol, but as of the last few weeks we're back on perf again. So far we've sped up /sync by 2x and reduced CPU by about 20%, but the RAM improvements should land over the coming weeks unless we have further distractions.

Meanwhile, on Riot, we're busy landing performance fixes which should make it much less resource hungry than Slack. These are literally landing as we speak: https://github.com/matrix-org/synapse/pull/2970, https://github.com/matrix-org/synapse/pull/3331 etc.

Why is you current solution so ressource hungry?

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

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

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

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

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

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

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

It's actually not as bad as I remember (time made me think it's worse than it really is) - it's really only large rooms that feel slow. Oops.

I just guess the whole thing doesn't feel responsive. Messages sent take a while to sync between different clients, etc.

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

Unfortunately the whole world seems to be heading the wrong way with cloud based "everything as a service" where you control nothing. If the provider or cloud goes down you have nothing. Even if they just take your keys you have nothing. It's quick and easy to setup and convenient but you're basically a hostage.

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

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

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

You don't necessarily have to fork it, just the possibility of the fork changes the game. It means that the original maintainer cannot shut you down. If enough people deem a fork useful they can work together.

Of course there's a cost associated with it. But how much is it compared to the risk of someone shutting a core element of your business down? You have to evaluate.

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

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

Those who really want to do on premise, will find their way to one of several niche products in this space. But I don't think any of these players will grab a lot of market share. Ultimately anything run on site is going to be expensive to support and why bother when you get cloud based offerings. Compliance issues can be addressed in the cloud as well.

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

Absolutely. Depending on how an organization manages its own IT security, data can even be more secure in the cloud than it would be on premises.

Decent providers like Atlassian invest in their IT security and employ dedicated security experts, something that can't be said of all organizations that host their software on premises.

However, I think in some cases being able to run specific software on premises is still a valid concern. Compliance is only one possible reason. Being able to easily access your data outside of the vendor's software might be another.

While they can be addressed, alleviating compliance concerns often is no easy task either, especially if your organization has to comply with laws and regulations from different jurisdictions. For example, I know of one organization where developers are allowed to use most Amazon services but are explicitly forbidden to use Amazon SES because that service currently is only available in a region that's technically outside (EU but not the same member state) of the jurisdiction the organization is in.

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

It depends on what an attacker is after.

For the average mid-sized shop that's probably true. However, it's usually larger organizations that worry about storing data in the cloud.

For these organizations and attacks specifically targeted at one of them, I suppose that in order to access vital company data both social engineering and hacking an internal system are much more effective attack vectors than gaining access to a third party system.

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

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

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

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

In order to attack an on premise application that is safely behind a firewall in a private LAN, one would have to come up with more creative, staged attacks (such as DNS rebinding or blind XSS attacks).

So, put simply, whereas the attack vector of a cloud based service is basically "the internet", this isn't usually the case with on premise deployments, and therefore they are inherently safer, or at least much harder to attack.

On top of that, cloud based services are usually multi tenant environments, so the assets to gain there are huge. One serious hole in such a service (be it Slack, logz.io, Github private repos, New Relic, etc.) will probably be a disaster.

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

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

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

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

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

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

Mail us at info at mattermost.com? // and this is an open invite to any HipChat users who want to keep data under IT control.

Regarding importing from HipChat, while it is tricky as the data is within HipChat's VMs and not documented, we can potentially work with you to move over smoothly.

The good news is if you switch to Mattermost we run as a single Linux binary with MySQL or PostgreSQL, so using us you have 100% access to your data as well as the source code to understand everything we do with the data.

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

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

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

It's Java so runs just about anywhere, and with even relatively low resource allocations, you can support a large number of concurrent chats and group sessions. Plus, since XMPP is an Open Standard, you can use any XMPP complaint client of your choosing.

Cisco embeds Openfire in a few of their enterprise products already (including Finesse), so you might have used it without even knowing.

The IgniteRealtime community is pretty active and new releases come out regularly[2].

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

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

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

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

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

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

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

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

No good web front ends?

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

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

Over the past years I used 'Pidgin' as my desktop client, but it was not were I wanted it to be so I was actively looking for alternatives. Dino looked very promising on paper (supported XEPs) but they lack basic stuff like systray support (at least the last time I checked it out).

For a long time Gajim wasn't any better than Pidgin, but earlier this year they released their version 1.0 which added support for some more XEPs most importantly MAM (enables proper history synchronization between clients). Since that release I switched to Gajim and stopped looking for alternatives ;-)

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

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

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

Also, I don't like the fact that it's person based whereas mattermost (and IRC) are group based that also allows person based chat.

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

The writing's been on the wall for HipChat for a long time; e.g. the user experience has been stagnant for many years (e.g. they never added emoji reactions). And even back in 2013, every HipChat customer I've encountered was unhappy or at best unenthusiastic about the product. So we've seen plenty of folks migrate from HipChat to Zulip.

I expect most enterprises will end up on one of the open source Slack alternatives (Zulip, Mattermost, Rocket.Chat, etc.). Frankly, they should have been using one of them anyway. If you care about a really high level of security, you want to be using well-maintained open source software. The well-maintained part is obvious, but the open source piece is really important too: It's a lot easier for white-hat hackers to find and report security bugs in software with access to the source code, and so there will be fewer that haven't been found and fixed yet.

You certainly don't want to be using a PHP app that's had over 700 confirmed security bugs found by external people (https://hackerone.com/slack) -- you can be pretty sure there are more being introduced every week.

I'll add that I expect to see more proprietary on-premise products that are the stepchild of a SaaS product disappearing over the coming years. It's a lot harder to ship software for the on-premise use case, especially if you have engineering culture used to just shipping for a single installation in the cloud (which almost everyone who works on proprietary software is). If you have the right processes and toolchain, it doesn't have to slow you down (and I don't feel it does for Zulip, with our amazing developer tooling and 98% backend test coverage), but very few organizations succeed at this. I've certainly heard some incredible horror stories from famous Silicon Valley companies about teams of engineers spending months on making a fork of a SaaS product shippable for each on-premise release.

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

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

If you divide the amount they've paid out in bounties by the number of bounties paid, and compare with their bounty tier rules, it's clear that a lot of the vulnerabilities that were reported in Slack are relatively severe.

(And I agree bug bounty programs are great; we also use HackerOne)

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

It is about Zullip being open source.

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

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

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

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

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

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

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

That being said, it’s unfortunate that OSS in many areas lags behind proprietary software in so many different areas, and it’s clear that for many different business use cases properietary cloud services are going to be more cost effective than OSS. As the deployment and ops aspects of software becomes more automated and simplified, I think this might begin to start shifting back in favor of OSS though.

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

You can always make the argument that for this reason we should only write our own internal tools and use OSS. However, it is just as easy for an OSS project to be abandoned or neglected. Often times enterprise contracts will have a source code escrow clause that provide the enterprise with the source code in the event of a shut down (the same capabilities as a fork & take over maintenance anyway).

We don't actually know the plan for HipChat On-prem yet (do we?). Slack and Atlassian are both known for being customer centric so they will probably follow what Facebook did with Parse. Open source the entire thing, sunset the operations and development over the course of a year or two with minimal security updates/patches and no feature dev. This could be what the investment from Atlassian was tagged for... to make sure their customers are taken care of while most migrate to Slack.

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

Yes it does, the thing is you have to talk to them to get it and it costs about 10 times as much as on-prem HipChat.

The company I previously worked for switched to RocketChat for this reason (Slack asked ~100K vs HipChat ~10K). RocketChat is free but you'll have to manage it yourself.

Wickr CEO here as well.

My team is happy to welcome all HipChat users to the Wickr Pro platform. Unlike on Slack or elsewhere, your collaboration flows are end-to-end encrypted so no 3rd party including Wickr has access to your team data.

We’re delighted to offer 100 free seats for HipChat teams looking for a secure team collaboration alternative. Your teams can spin up a Wickr Pro SaaS private network in minutes, free to trial for 30 days with flexibility to extend.

Test drive our end-to-end encrypted messaging, secure channels, team/project rooms, file sharing for up to 5Gb, video conferencing/calling, screen sharing and enterprise-ready admin controls including SSO.

Get started here: https://wickr.com/the-best-alternative-to-hipchat/

If you need ON-PREM deployment, let my team know here, they can help you seamlessly navigate your transition from HipChat: https://wickr.com/products/enterprise/ and we’ll get you on-boarded.

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

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

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

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

We might have to revert to talking. Aahhhhh!

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

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

Wasn't too serious

But ...

For distributed companies: email for async communications, phone for sync. If you need to bother someone immediately you might as well have a high bandwidth audio (or even video) call.

Setup an old faishoned IRC server?

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

Or matrix/riot?

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

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

Happy to help!

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

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

If I'm not connected to Slack, or even a member of a Slack channel - I can connect/join the channel and be able to get all of the history back to the beginning of the channel (or whatever Slack's limitation is).

This makes it very easy to jump into the middle of a conversation and not worry you've missed some important context.

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

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

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

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

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

BNCs provide a semblance of persistence. But the real problem with IRC is smartphone persistence, I think irccloud is the only service that solves this. But alas, it isn't free.

So can this be solved for free? Is it even a good idea to solve it?

thelounge is an web based IRC client with persistence like irccloud, except that thelounge is open source and self-hosted.

https://thelounge.chat/

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

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

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

If your browser supports web push spec, yes!

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

As others already pointed out, that requires technical skill and fiddly configuration.

It also doesn't help with the specific scenario of jumping into a channel you've never been in before, and being able to get all the history of that channel.

I frequently have to jump into the channel for another team, provide some input around whatever the current issue is, and then I generally leave. I don't care to see/read about whatever that team normally does. With Slack, that's dead easy - join channel, I can scroll up and see the rest of that conversation, then talk a bit, and get out.

There's also a ton of other features, like threading, editing message in-place, and persistent file attachments that either arn't supported, or require some kind of custom implementation - or depend upon IRCv3.

We also make heavy use of various integrations - our customer support team gets pinged in-channel when certain events happen in their support platform, which has Slack support built in.

Our deployment tools notify teams that need to be aware of new releases and links to resolved issues/new features.

So, yes, we could cobble together something that does all of these things - but this is a major undertaking.

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

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

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

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

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?

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

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

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

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

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

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

I'm guessing it's highly likely that one of the reasons for the acquisition is to make Hipchat the on-prem version of Slack, or at least create a path to that goal. Why does everyone here assume they will shutter the product? Slack has been promising self-hosted chat for years.

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

It'd be a lot less work to fork Slack and make it work on-premise than do something with HipChat. And that's saying a lot: forking Slack to make it run well on-premise would likely be an enormous project.

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

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

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

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

Nayego is trying to hard build a HipChat-like client+server that is open source and based on XMPP. https://nayego.net/ you can subscribe if you want to see a preview.

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

> As a result of this partnership, Atlassian is discontinuing all real-time communications products, and we are working with Slack to provide a migration path for Stride and Hipchat customers.

They provide dates for shuttering everything. Stride and Hipchat Cloud are shuttering Feb 2019. The latest version of Hipchat Server will be supported until June 2020.

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

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

> as the two products merge.

The 2 products aren't merging, so far as I am aware. Slack is buying Hipchat and then promptly discontinuing support for it. It's primarily a move to eliminate competition, not to acquire technology.

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

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

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

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

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

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

Microsoft Teams has on-prem support.

source?

> What are enterprises supposed to use?

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

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

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

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

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

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

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

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

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

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

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

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.

welcome to 2018

Obv IRC bro

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

> Slack doesn't have an on-prem option. Microsoft Teams doesn't have an on-prem option. What are enterprises supposed to use, RocketChat? Matrix? With no clear migration path?

Ahem:

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

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

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

Look at it this way: IBM uses Slack. That means that 1. they researched the security threat model and were okay with using it for their own internal data; and 2. they managed to convince all their clients that those clients' internal data, and those clients' customers' PII, would be fine being passed over Slack. That's a pretty large argument, in my mind, for the idea that there's nothing about Slack that disqualifies it from even the crustiest dinosaur of a corporation's requirements. To mangle a phrase: "Nobody ever offended a conservative regulator by copying IBM's choices."

Or do you have security requirements that IBM—in its professional-services interactions with a whole ecosystem of clients, including banks and government agencies—doesn't? If so, maybe you need something on-prem.

Even then, though, you realize that you can just not put the critical stuff directly into Slack, without much impact on your workflow, right? If you're e.g. an investment firm, doing BI and quantitative analysis over tons of data, you can still talk over Slack while keeping the actual data to your Intranet. When you want to refer to the data in the chat, you paste the link to the (Intranet-hosted) data into the channel. Slack can't visit the link, but you can. Isn't that enough for... pretty much any use-case?

Reply on news.ycombinator.com