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

It's the only way to run a business.

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

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

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

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

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

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

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

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

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

Yes. But one can easily find creative solutions.

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

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

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

s/extrapolate from/fixate on/.

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

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

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

Hiding enterprise pricing is quite common for many SaaS companies.

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

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

Who knows if that had any influence on their success?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

edit: typo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Approx how many users?

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

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

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

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

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

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

Disclosure: i work on Matrix.

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

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

Why is you current solution so ressource hungry?

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

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

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

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

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

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

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

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

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