Live data from Hacker News

Story of Mattermost: Open-Sourced Competitor to Slack

breakoutstartups.substack.com

131–140 of 248 posts

Re: Story of Mattermost: Open-Sourced Competitor to Slack

#132
post #107

Not a single comment here mention Google's Hangouts Chat I'm not surprised, it's a garbage product. We use it at work since it's bundled for free with GSuite But - The name is just awful, you can't even find it in Google's search since the previous (still live) Hangout chat app overshadows all search results - Integrations and ecosystem around it is non existent - App doesn't see any meaningful updates - The Android…

I stopped using it about a year ago and was quite dissatisfied as well. Kinda thought they’d put a bit more effort to create a good product afterwards but somehow it looks like a low priority thing for Google. I don’t know why, they could be a very solid competitor and maybe even have an excuse to raise GSuite prices.

Google products experience a self-fullfilling prophecy of not getting serious effort put into them because everyone expects Google to kill it in 16 months, so it never takes off with users, so Google cuts the project.

The really goats part is that the engagement levels that Google considers to be "crap" would make any SV startup a darling Unicorn in their next funding round. But compared to making money hand over fist on click-fraud-plagued ads, it just can't compete.

Re: Story of Mattermost: Open-Sourced Competitor to Slack

#133
post #113
post #89

Earlier quoted context omitted.

> Email has hefty overhead per message. I don't think that poster was talking about protocol innards, although kudos for you for having that knowledge, but perhaps they were, but in terms of user experience, slack/group chat is very low cost in terms of requiring any sort of mental pause before sending the message, specifically as a cost for the message itself. So much so, that a type of usage of verbal diarrhea can…

Interesting points. I suspect this is why chat is such a crap, low-throughput form communication; it's trivial for the sender to ship of a half-assed message - and very hard for the receiver to handle low-hundred conversations in a work-day - precisely because few(er) senders take the time to write a short, but dense message - and expect a reply-response dialogue "to quickly sort things out". Which is much harder to…

I'd be interested to see the effects of using a retention policy[0] to discourage the use of chat as a be-all and end-all. IIRC some companies actually do this.

[0] https://slack.com/help/articles/203457187-Customize-message-...

Re: Story of Mattermost: Open-Sourced Competitor to Slack

#134
post #14

I have a small team, but about a year ago, we deployed Mattermost on our K8s cluster using their Helm chart and I have been very pleased with the performance and stability. We never looked back at slack. I have not had to fiddle with the configuration at all since deploying it. It just works. And that is also considering that to save costs, I launched it on preemptible instances which go down usually once every 24 ho…

Did you do any integrations for voice chat?

Hi, Mattermost PM here. We also have other voice, video and screenshare integrations, including self-hosted on-prem and private cloud options. Zoom, Webex, BigBlueButton, WebRTC and more: https://docs.mattermost.com/deployment/video-and-audio-calli...

Re: Story of Mattermost: Open-Sourced Competitor to Slack

#135

Does Mattermost still have LDAP issues? The company I work for was looking for a Slack alternative but in the end decided to stick with Slack because of this.

Thanks moedersmooiste, Mattermost PM here. Would be curious to hear more about your LDAP issues. We have many organizations who have deployed with LDAP, including with group sync to teams and channels.

Those eligible for a nonprofit license can also get the benefits of E10 offering (including LDAP) with special pricing https://mattermost.com/nonprofit/

Re: Story of Mattermost: Open-Sourced Competitor to Slack

#136

Earlier quoted context omitted.

Go will often be faster than NodeJS. It can also be deployed as a binary rather than a blob of Node modules.

Why does any of that truly matter? What matters most is if it meets the needs of people using the product, not what language it is written in nor how it is deployed.

If it's used in a small company, one of the users will also be deploying and administering it and integrating it with whatever else the company has. So things like what it's written in, matter.

Re: Story of Mattermost: Open-Sourced Competitor to Slack

#137
The open-source Mattermost intentionally lacks a couple of pieces of basic functionality to push you to pay, like the ability to stop regular users from deleting channels, and no way to set a reasonable password policy that requires more than 5 characters.

Mattermost (and specifically their CEO, who is vigorously replying to messages on this thread, but probably won’t engage with this one) haven’t responded positively to requests to include these basic features:

https://github.com/mattermost/mattermost-server/issues/6320

https://github.com/mattermost/mattermost-server/issues/5935

As far as I’m concerned, Mattermost isn’t any kind of a competitor to free-tier Slack until these issues are resolved. This exact thing has turned more than one team I’m on away from Mattermost.

Re: Story of Mattermost: Open-Sourced Competitor to Slack

#138

Yeah. But. https://github.com/mattermost/mattermost-server/issues/6320 Non-admins can delete/archive any channel #6320

What's more disturbing than the bug itself is the Mattermost team's response that this behavior is intentional for the free "team edition" of their software, and that "actually, I think the bug is that we should not be showing Channel Admin as a role in Team Edition" (i.e, users of the free edition don't get any kind of access controls, making it impractical to use outside a small group of trusted users). Potentially…

What you're describing sounds similar to crippleware.

https://en.m.wikipedia.org/wiki/Crippleware

Re: Story of Mattermost: Open-Sourced Competitor to Slack

#139

This space is downright awful. 20+ years ago corporate IT was concerned about the phone on my desk (how quaint). They put one there on the back of a PBX. They put in a system that was LOCAL for local needs and accessed the public network when it needed to. It worked because it was built on the back of a proven standard (telephone). We don't have a working chat standard, and it shows and we need to fix it.

We have XMPP for 1 to 1 messaging, IRC for group messaging and SMTP for store and forward messaging.

All are way easier to set up local instances of than setting up a PBX. The difference is that there was a whole lot of money to be made by installing and maintaining PBXes.There was no good way to monetize phone services by advertising or privacy violation. The equipment and trunk lines simply cost too much. Every PBX had proprietary phone sets, but the companies that made them could not get around the fact that the phone trunks were standardized by what was in the end a government enforced standard. So it was an example of forced federation of proprietary systems. It is interesting how well that worked.

We have a weird situation right now where the cheapness of communication is inhibiting standardization. Everyone can afford to do their own thing and fund it using super marginal revenue streams.

Re: Story of Mattermost: Open-Sourced Competitor to Slack

#140

Earlier quoted context omitted.

What's more disturbing than the bug itself is the Mattermost team's response that this behavior is intentional for the free "team edition" of their software, and that "actually, I think the bug is that we should not be showing Channel Admin as a role in Team Edition" (i.e, users of the free edition don't get any kind of access controls, making it impractical to use outside a small group of trusted users). Potentially…

I think you'll find all you need to do is compile with `BUILD_TYPE_NAME=enterprise make`, and suddenly all features appear. Whats peoples moral position on opensourcing the features but not including them in pre-built images unless you pay?

Moral? I'm not seeing one.

I think it's a clever way to support free and open source projects. Free edition is for everyone, trials, demos, etc. Paid enterprise version is for companies that are happy to pay to get some extra value. Build it yourself enterprise version is for people who don't want to pay, people that get less value from the product than the price, hobbyists, etc.

Caddy (a web server) used to do something similar.

Post reply on HN