Live data from Hacker News

Story of Mattermost: Open-Sourced Competitor to Slack

breakoutstartups.substack.com

91–100 of 248 posts

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

#91

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…

> Potentially controversial opinion: This isn't really open source.

I know you were looking for this but I don't agree. Let's remind that Open Source fundamentally means _no expectations_. No expectations of support, no expectations of features, not even expectations of goodwill. Whenever a company complains that this or that open-source software doesn't work as expected and should do this, we all shout in chorus "this is open source, take it or leave it". This is exactly the same case here. I know it's frustrating because the feature exists in a fork that happens to be run by the same people, but that is exactly what is permitted by this license.

Does anyone here complain that SQLite isn't _exactly_ open source because they don't ship their full test suite in the open source package (https://www.sqlite.org/th3.html), even though each release passes it ?

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

#92
post #32

I been a mattermost user for two years, can't say enough good things about it. Love that it's written in go. We run ours with very little resources and it still chugs along.

Why does it matter what it’s written in?

It really doesn't, but was helpful for me when I had to patch a few issues.

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

#93
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…

[deleted]

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

#94
For a while we used Mattermost at my office. At the time we had a handful of startups in our incubator. Eventually we ended up switching to Slack. I don't think it had to do with anything other than momentum and popularity of Slack, in spite of Mattermost accomplishing the same thing with virtually the same interface, people just liked and wanted to be on Slack...

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

#95
post #84

What about zulip? They seem to fare well in terms of features against slack and mattermost.

After trying all, I prefer zulip over all (including slack). It is very polished, functional and easy to write extensions for! It is slightly annoying that I feel like none of these will last a decade and wonder why we couldn't have stuck with XMPP or an extended standard and figure out federation, privacy and enterprise. Unfortunately, outside of tech, everyone is moving to Teams!

> Unfortunately, outside of tech, everyone is moving to Teams!

Alternate perspective: they never left Lync/Communicator - it's just been rebranded.

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

#96

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.

Usually easier to administrate & upgrade than a mess of script files & packages. Especially if you're not in whatever "scene" that junk's from (e.g. you're an iOS developer, mostly, not a Javascript person used to dealing with npm crap, or a Python person used to PIP crap, or a Ruby person used to gem crap, or whatever crap it may be). Download file for correct arch, run file. You can confidently use it even if you're not familiar with Go at all. Even if you hack on it and make your own builds, the deployment story's nice & simple because deployment target images or VMs or devices usually don't need anything but the binary and maybe a service definition file or startup script of some kind (which everything else also needs anyway, so not like that's any worse). No having to make sure npm's installed, then use it to install some native package that needs to build some C deps for the given environment, set the right Python environment, check the Ruby version, none of that junk.

[EDIT] In short, I guess, the nice thing about running services written in go is that, unlike a lot of other popular ecosystems, you actually can forget about what it's written in, more often than not.

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

#97
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 app is so crappy I don't even know when to begin. Try initiating a conversation with some person by searching them. Or try sharing something from Android to a channel only to realize you cannot search for the channel in the list - Api to write bots is pretty badly designed - When you edit your message you cannot mention people anymore - Deleted GSuite users just keep floating around as ghosts

I give this product a year top before it is canned

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

#98

Earlier quoted context omitted.

I think "all team members are admins" is more usable than you think it is; I generally do this for many cloud services on most of my teams even at my day job; it's just not worth spending time dealing with access control, setting it up, and then someone who can't do what they need to do for their job cause you didn't give them enough access, or the only person who can do what needs done is on vacation, etc. I often s…

> it's just not worth spending time dealing with access control Until one day, when you have some sort of incident, and it will have become very worth your while to "deal with" access control.

So, at your workplace, do you put unpickable locks on everyone's individual office door and enforce a policy that all doors are locked when not occupied (or heck even when occupied), so you won't have to "deal with" some insane coworker trashing someone elses office? How about tracking of who is in the bathroom when, with camera monitoring, so you can deal with it in case someone smears their poop on the walls?

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

#99
post #54

Could anyone elaborate as to how Microsoft Teams overtook Slack so quickly?

It is free (bundled with office 365). Lots of places prefer to save a few dollars per person and loose hundreds in productivity.

Same is true for Google Hangouts Chat and you don't see anyone using that...

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

#100
post #68

Earlier quoted context omitted.

> Use email or something else for more permanent discussions. I don't actually agree with this. Email has hefty overhead per message. Chat allows for faster and easier communications, which does NOT mean you can't have a history. Indeed, history and search is the real selling point of Slack for me. Everything else Slack has over IRC is trivial and not worth abandoning the standards.

> Email has hefty overhead per message. Chat allows for faster and easier communications I'm not sure I understand. Are you talking about the SMTP/LMTP format, or clients or what? If anything email lacks overhead - a proper thread meta data field that actually works across implantations (in-reply-to is a start, but not enough). It's not like "xmpp overhead" made gräll unusable, is it?

I didn't mean technical overhead, I meant presentational overhead.

Email was fine, nay, great, for people to have extended group discussions in, so long as everyone was willing to follow some rules. Then Outlook plus the Eternal September came along and now everyone is reinventing quoting repeatedly (and poorly). Branching is a whole thing (or mostly, not a thing when it needs to be a thing). And we don't even need to discuss what happens to HTML in emails.

Chat allows for fast questions, fast responses. This makes it harder to have lengthy or broader discussions in. Neither of those, however, says that chat has to ephemeral while email is lasting, which was the point I was responding to. If you want chat+history, you can't swap out chat with email and say "there, now you can have a history" - you just changed a LOT of things.

Post reply on HN