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:
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.
This is, fundamentally, the Open Core business plan, which Mattermost is executing quite successfully. You get all the marketing benefits of being "open source", but few IT departments will use your software in production without buying the enterprise license, so you get most of the revenue you'd have had if you were closed source.
Folks have different perspectives on Open Core. It's definitely a lot better from a freedom perspective than proprietary software, so I don't want to be too down on it. But it isn't really FOSS, and I think the difference is important, which is why Zulip is following the commercially more difficult path of 100% FOSS. Even obviously enterprise features developed entirely by our paid team, like SAML authentication are FOSS, and our plan is for it to remain that way forever.
It's commercially more difficult because it means right now we have users at governments and Fortune 500 companies and whatnot who've reached out to tell us they how much they love Zulip, but nonetheless aren't paying us anything. On the flipside, Zulip has been very successful in building a large community of volunteer major contributors (some handy stats are in our release blog posts, e.g. last week's https://blog.zulip.org/2019/12/13/zulip-2-1-released/). I don't think that would have happened had we taken Mattermost's aggressively Open Core approach..
I really hope this model works out for you, I absolutely adore Zulip. At my company, we have the option of self-hosting, since you've made it so easy, but I intentionally keep us on the free plan so we can start paying when we can afford it, to support you.
Zulip is one of the few pieces of software that I think are unquestionably worth their price (some others being Gitlab and some sort of SIP provider, e.g. OnSIP).
The password policy was added to Team Edition back in June, 2018.
>Mattermost isn’t any kind of a competitor to free-tier Slack
Mattermost isn't intended to compete with Slack's free tier.
The open source version of Mattermost is focused on software builders and operators who want a flexible, open, collaboration platform that works with their tools and workflows. Here's more on Mattermost Chatops as an example: https://mattermost.com/blog/introducing-mattermost-chatops/
Very often we're deployed in high security environments and private clouds where internet-based services can't easily go.
I can't really tell for the github issues you posted what was done about these two issues.
I don't really feel like reading all that just to figure it out.
Did you resolve both of the issues brought up by OP or not?
(Answering: "The password policy was added to Team Edition back in June, 2018.", isn't the same as answering, "the free tier allows passwords of length >5 characters.")
As I’m reading it, Mattermost (as source) is released under the AGPL, which makes it both legal and ethical (indeed, they have explicitly consented to allow you to distribute modifications) to stub out all the license checking and enable all of the enterprise functionality without any payments, tracking, or phone-home.
It seems to me this is the point of free/open source software: anyone can improve it and make it more functional and distribute those improvements. The first logical improvement, to me, is removing the unnecessary license checks that disable useful features of the software.
The binaries they release (including that code) are MIT licensed according to their readme, which means that modifying those should also be no problem.
It is legal and ethical to remove the parts you don’t like, but that doesn’t mean you shouldn’t pay for it. You’re not required to, but if you find it useful you could consider it a donation.
Regular users cannot delete other people's posts and channels, but they can indeed archive any public channel.
I run a mattermost server for a Free Software project. We have over 2000 users, but around 300 monthly active users, 100 daily. I worry about it sometimes, but trolling in our community is pretty rare.
> Mattermost (and specifically their CEO, who is vigorously replying to messages on this thread, but probably won’t engage with this one) [emphasis mine]
Aside from being wrong, this seems needlessly argumentative and rude.
In my experience, the competition is pidgin slash outlook communicator slash whatever brain dead enterprise messaging app. Not slack (or hipchat or...). Mattermost has seen a lot of adoption atthe Big Dumb Corps I’ve seen.
That’s my take on the market at least. I’d buy stock in it if I could.
The open-source version also lack any data retention option, meaning that your only option is to let the database grow indefinitely; you can manually delete stuff from the db, but last time I've checked that was not recommended.
Deploying Mattermost is not ideal, as the server requires write access to its JSON configuration file and will overwrite it from time to time, which makes using any configuration manager pointless: after upgrading mattermost you have to fetch the "updated" configuration file from your server and import it back into your configuration manager (and since it's JSON you might get different key sorting and indentation offset).
Despite the above I like Mattermost and I've been regularly using it for more than 1 year, basically for free.
In 5.10 Mattermost added the ability to move the configuration to the database, which solves the issue of having a config.json file. This also has the advantage of versioning your configuration in the database which makes rolling back changes very easy.
If there is enough interest, we at polyglot.network can add those missing functionalities and maintain that fork. We have already done the same for certain other OSS software as enhancing open-source software for paying corporate clients IS our business model.
Another one, if you want your free local instalation to be able to push notifications to your mobile app it needs to go through their http (non-https) proxy. At this point this might be more damaging than not providing the option at all.
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 controversial opinion: This isn't really open source. When major features like permissions and access controls are stripped from the "community" version of a software package, it starts looking more like a feature-limited demo.
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 say "We don't have (or use the) locks on our doors at our physical individual offices, but that doesn't mean any of us would go into someone elses office when they aren't there and trash everything on their desk. And it's not a problem. What makes electronic resources different?" [I know HN audience will now give me an exhaustive list of what makes electronic resources different; please don't bother; I know this approach doesn't always work. With physical offices either].
But I agree with you that that level of feature-crippling makes me want to all it more like demoware than open source.
"Everyone is an admin" might be usable for some small teams, but it makes the software absolutely unusable for any sort of public project -- like open-source developers, or public communities. It really makes it clear that the primary purpose of the "team edition" is to drive sales of the commercial product, not to be usable in its own right.
It works well for companies where there’s typically recourse in company policy to deal politics and bullying.
For communities, especially those that are open, this model often fails as soon as one bad actor comes along because there’s often no recourse against bad behaviour.
Unfortunately for Mattermost, it’s communities that are less likely to be able to pay, and more likely to be affected by this policy. That just feels like poor policy making.
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?
Laptops and physical property are one thing. But your digital empire of customer data is another. Encryption, MFA, inactivity based locking, access controls, and the principle of least privilege helps ensure that when something inevitably does happen, the blast radius is contained.
I don't really care if someone were to smash the hell out of the office. Laptops are locked. Data is encrypted. That's why in fact we have insurance.
But a disgruntled or even careless employee could irreversibly damage an enterprise by letting happen (or deliberately causing) a data breach. All because the org didn't want to bother "dealing with" access controls.
Way more likely that someone presses that delete button in a temporary tantrum or by mistake than a coworker randomly trashing someone else's office (there are telling signs after all).
It's also way easier, cheaper and practical to prevent the first example than the second one.
Your employees may not be the problem. But their accounts with brute-forced passwords or shared credentials will be a problem once a 3rd party finds out.
Of course it's more useful, it's more useful to team members and to malicious users alike, but it's not useful for passing security audits and certifications.
> 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 ?
> Let's remind that Open Source fundamentally means _no expectations_.
No. Open Source, as defined, is about what the end user is allowed to do with the code they have. That’s it. What you describe is common, but not inherent. There are plenty of exceptions, like if you get Red Hat, you’ll get to have plenty of expectations, and Red Hat is still Open Source.
Please stop the ancient FUD about Open Source means having no support.
When I say open source means no expectations of support I obviously talk about the license the software comes with, not the overall idea and goals that are common in the open source world.
You want support! Great, it exists and can even provided by multiple different actors, with or without expected quality of service, and that's great! But that is not included in the license, you have to find another arrangement on the side. Maybe you can ask nicely and they will do it for free, maybe they'll ask you to pay them in beers, maybe they'll ask for a specific contract detailing everything. Same goes with features, you can ask for new ones but that is not part of the license. That's it, that's all my message was about.
Right, open source, like all software, has a variety of vectors of usability and suitability. Purposefully leaving out features weakens it along some vectors - especially the "I want to modify software I run in production" vector.
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?
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.
They're doing it wrong. There are many successful, profitable companies making open source products with a subset of the features that their commercial offerings have. These guys are intentionally crippling the open source offering. It's practically a bait and switch.
The right way is to release an open source product that is full-featured and robust, and upsell things like support, managed hosting, and the kind of plugins and addons that primarily appeal to enterprise customers (although increasingly the latter are indistinguishable from advanced small users).
It's worse than that, expectation are different and actually doing disservice to the whole open source ethos. I recently heard a couple of regular users talking and equating Free Software//Open Source with Freeware, I didn't bother correcting them because from their perspective the difference is meaningless. Only us geeks care enough, but not enough to go and fork it.
Thanks for highlighting this. It's a ticket from two years ago and this thread is a good opportunity to share more of the context and intention of how we think about Team Edition vs Enterprise Edition.
Also, I don't know if the ticket title is highly accurate--a non-admin can't delete any channel:
1) There is no "Delete Channel" in the UI only "Archive Channel"
2) A non-admin cannot archive any channel, only channels of which they are a member.
3) A non-admin archiving a channel they created is not really an issue, so this ticket is really about a "Non-admin can archive a channel which they are a member of but didn't create" which we've seen can be more helpful than harmful--when someone leaves a team and their out-of-date channels remains anyone can go and archive them without having to find an admin and make a request.
The current wording sounds like non-admins can delete private channels, channels on different teams, channels they're not part of, etc. and in my mind it's not the case. But perhaps other people have a different read?
I think the concern here is a pre-emptive rage-quit of channels. A team member is aware they are about to be let go, and decide to archive every channel they are a part of on the way out.
What controls are in place to prevent this from happening in the Team Edition?
Archiving a channel in Mattermost just sets a flag in the database. Once the bad actor is removed a simple query can restore the channels they archived. Something like: `UPDATE Channels SET DeleteAt = 0 WHERE DeleteAt > [some timestamp]`
There's also a CLI command to restore the channels. While this won't keep it from happening it should get things back to normal fairly quickly.
Wow this is crazy. So the free edition of Mattermost has even less access control functionality than Facebook Messenger? Disappointing.
It seems to me that "open source" is now being used as a marketing label for what used to be known as "shareware" or "trial". You get a trial version of the software (but where you can see the code) and the big essential features you need to pay for.
Open source no longer means what it used to mean.
And for the CEO to join in that ticket discussion and say "yeah it's a bug - there shouldn't be channel admins at all in the free version" basically confirms this.
Don't complain it's missing features! Make them yourself ... but we'll just steal them if they're better than the paid version because hey, open source!
Not a great comment, in my opinion. He does nothing to address the artificial neutering of the community edition, especially when compared to all the open source products that Mattermost uses - as the blog post author's response sets out.
Why is artificial neutering unethical? What’s wrong with it? Change the code yourself or pay the guy. 99% of software only gives you the second option.
When I checked mattermost a year ago, the mattermost opensource edition had no basic permissions/access control. Any user could archive any channel. I have seen many teams fall into this "trap" only to find this basic restriction later. We since moved to Rocket.Chat. Is this still the case?
Keybase is.. not ready for prime time. It's pretty janky, channel discovery is a pain as is spam, and it's still got that weird crypto half-baked nonsense.
Access control is intentionally missing from the open source "team" version:
> Team Edition is "virtual office" where a team works together as trusted colleagues. It means people can walk anywhere they want, and move the furniture if they choose.
> I need to ask this ticket be closed since it's not a bug
> You're of course more than welcome to fork as well.
But would Mattermost accept a PR that cuts into the differentiation on "advanced access control" of their enterprise product? https://mattermost.com/pricing/
Open source is only as powerful as the community's willingness to maintain a fork.
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 hours. Mattermost recovers and reboots flawlessly every time.
I had similar needs. I don't like that telemetry is on by default and you can only disable it by manually editing the config JSON (whilst service's stopped). I have encountered bugs in past versions but nothing recent stands out. Having full control of our data, unlimited history, slack-compatible integrations with 3rd party notification services and our own, easy upgrades, and no downtime when Internet's out (in-office server) has been great. Overall a positive experience.
Cool, thank you both. I think WebRTC or Jitsi are closest to what I would be looking for, as I want to keep it open source, but I appreciate the Zoom and other integrations for how they could be useful to business.
You guys might consider Mumble/Murmur integration, I think it could be a great addition, as it was my favorite voice app before Discord took over everything (still is).
I'll add that the only issues I came across were from a few users who didn't like the mobile client as well as Slack. I would chalk most of that up to them simply being used to Slack.
But I think Mattermost could still use a little bit more polish (as pretty much all software could) when it comes to the clients. I hope you guys don't lose focus on that. I would much rather have a progressively better user experience than one more widget integration that most won't use anyway.
The biggest problem with Mattermost is that the mobile client cannot connect to multiple teams. You can add the beta client and connect to a second team, but more than two teams is impossible. This may be a function of living in the Bay Area but I'm on 4 or 5 different Slack groups for various communities.
All but my employer would be in great shape to switch to Mattermost but it's just not possible. Some have switched to Discourse but it's not great for real-time communication and people have a hard time with the UI.
The ticket you linked to said the feature is “planned”, so I’m not sure what you mean when you say you’d welcome help. Are you working on this internally (and as such this is essentially a “we’re looking for mobile engineers”) or are you soliciting contributions from the open source community to work on this?
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!
The Rust core dev teams are using Zulip extensively. It must be going well enough or they'd have moved onto something else. Instead, adoption has grown.
I absolutely love Zulip. I use it for a company team and it's been amazing. The stream model where you can zoom in is extremely convenient for catching up with messages and we love how well everything works.
I love Zulip but the concept of topics is repelant for (lazy?) users.
When you chat on a channel (Slack, Mattermost) and people start fragmenting the discussion into several topics that interlace... Ugh! I yet have to meet people that would at last utilize Threads.
> When you chat on a channel (Slack, Mattermost) and people start fragmenting the discussion into several topics that interlace... Ugh! I yet have to meet people that would at last utilize Threads.
Slack threads are an utter abomination. I'd rather they removed the feature entirely; they're harder to keep track of than the linear stream of a channel (which is saying something, because the chronological, linear stream is already pretty bad for ongoing discussions)
I've tried both and imo mattermost has the edge when it comes to hooks and integrations. It's also insanely flexible with the configuration options it gives. The one thing I don't like about zulip topics... Not really my thing...
Zulip topics are the best implementation of chat threads that I've seen yet. You can view all of them simultaneously like a regular chat room, or focus down on one. You can mute either a single chat topic or an entire stream (channel). In most chat systems, if I don't read the messages within a day, I'll never bother reading the chat history because I have no idea whether there's anything relevant in it. In contrast, I can open the Rust Zulip once every few weeks and see if there were any interesting topics.
And if you're really sure you don't want to use topics, you can always just make a single "general" topic in your stream.
We went Skype => Slack => MS Teams => Mattermost for our developers. If Teams wasn't such garbage at basic things like markup and pasting screenshots, we might still be using it for everything.
I had no real concerns with Slack from a development perspective. We simply wanted to try a unified messaging platform for the whole enterprise (our non-developers much prefer Teams/Skype for some reason). That experiment failed for our developers, so we now maintain 2 stacks - Teams for company-wide communications, and Mattermost for developer-intensive communications (or anyone else willing to teach themselves how to use a new thing).
Mattermost has proven to be an incredible solution for our development duties. I just installed it directly on a EC2 t3.small instance and we've been using it for about 9 months now without any pain points to speak of. I literally haven't touched that machine since I turned it on day 1. To be fair, we are <10 developers, but we get pretty heavy with the screenshots and json/code dumps throughout the day. We did make some compromises with authentication in favor of expediency of deployment, but it's really not a big deal for our developers to keep track of their LDAP vs their mattermost credentials. If someone complains enough I'll spend a few hours to hook up LDAP too.
So - non-developers resisted Slack or Slack-like things?
That's interesting. I'm a developer but I find it easy to empathize with non-developers because I hate any tech orthogonal to the actual task at hand that requires a learning curve. I usually find that other things have pushed that thing out of my brain by the time I have to use it again.
Unlike most developers I'm no fan of Markdown (I can manage links and list formatting in a WYSIWIG editor without needing to reach for the docs. I hate reading docs).
I've got the hang of Slack but I tire of teaching new adopters the correct etiquette and usage that means they don't overly interrupt those of us that have tuned their notifications. Or teaching people how to ensure their messages aren't missed entirely.
I share some of your resentment for having to learn new things to engage in what is arguably a trivial activity at this point in time - sharing (formatted) text or other media with your teammates. This is probably a factor in why many of our users prefer "simpler" approaches... At least from their perspective. One would argue markdown is simpler and faster than using any MS Word-style interface if you are experienced in its syntax and rules.
Learning markdown is pretty easy for many developers, and for some it becomes 2nd nature when typing into things that support it on a regular basis: Git[Hub/Lab], Slack, Mattermost, WhatsApp (partial support), etc. The value-add as you put additional markdown-enabled platforms into your workflow is pretty substantial. I don't have to do a mental context switch every time I go between editing a GitHub issue comment and typing some code block to another developer in Mattermost.
You can create some really nice looking README.md files if you spend a little extra time with things like headings and quote/code blocks. I believe there are several options (one hosted in GitHub's API if you prefer GFM) for taking MD files and generating high-quality HTML or PDF output.
I'd conclude by saying that markdown documents are much easier to source control. Taking a diff of a docx or a pdf is going to get you nowhere. A diff of a markdown file might as well just be a diff of any arbitrary plain text document. The syntax itself has a very small footprint, so you are looking at mostly just plain text minus 5-10% overhead on the markdown.
Slack doesn’t actually do Markdown; it’s just a little bit ahead of what Hacker News offers. And diffing PDFs and Word Documents is possible, but annoying: you need a custom diff tool for it that you integrate with Git.
In our company we are the test team for MS TEAMS. Short but honest. MS TEAMS is a real mess. I have no idea why MS let this software going public like this. Does anybody think that's a good piece of software?
Love the fact people are adopting Opensource solutions but corporates won’t budge. I think the hardest penetration for anyone right now is Microsoft Teams. Since they started bundling teams with Office they have been able to boast about numbers and actually hurt Slack. I wonder what is roadmap for Mattermost. Shameless plug I myself did an opensource version of a chat server called raspchat https://github.com/maxpert/raspchat which was able to handle almost 5K very active chatters on a Raspberry Pi Model B (Just 512 MB of RAM). My original dream was to build a drop and run server on cheap raspberry pi for local areas but man has to feed his family and I had to make a tough choice. It’s harsh IMHO out there to get attention and then convince folks to develop integrations for you. I hope this space doesn’t endup with duopoly and products like Mattermost take off.
Awesome work on raspchat! And thanks for the kind words.
Often we see users and customers have both Microsoft Teams for Office365 users and Mattermost as the "developer's choice" given the open source code base and flexibility in high security environments.
Per the article, the market is very large, and there's many different user segments to serve. Therefore there should be multiple winners here, in my mind. I think this category is only just starting.
In my org we have Teams and Slack (and Skype for Business!). Corporate (and our one token diehard Microsoft fanboy) gave a weak effort at pushing Teams, but everyone was already on one of the other two so for us Teams is just sitting on our computers like an appendix that's useless but also just enough effort to cut out that it stays in.
I have the inverse. The only thing _everyone_ is on is teams. Slack is too expensive and introducing yet another chat program is not going to be met with anything other than resistance.
My response to someone insisting on using only Microsoft Teams is: What if Teams goes down? How is the IT team going to coordinate bringing it back up? Email? SMS?
Uber currently uses Mattermost but will most likely move to Slack.
During my 2 years at Amazon, the SFO based Prime Now team used Mattermost but we were eventually forced to move to Chime a pitiful example of a chat client.
Mattermost CEO here, if Amazon is open to it, I’d love to see if there is a “Better together” story across AWS, Chime (meetings, voice, video, screen sharing) and Mattermost (developer, Ops and SRE workflows and integrations). We’ve heard the same from different Amazon teams looking to accelerate developer productivity
True, but everywhere else they are pushing Teams hard for general users.
Mattermost is already certified on Aurora, we work with S3, it's available in AWS Marketplace--if there's a dev team at Amazon interested in an open source alternative to Slack that runs natively on AWS infra--potentially connects with Chime for voice/video/meetings/screenshare it's potentially a healthy thing for everyone.
> We don't have a working chat standard, and it shows and we need to fix it.
IRC works pretty well.
The only thing I sometimes miss is history, but... in some ways that's not a bad thing, and could be added without too much trouble.
Slack has history because Slack wants you to live in it. No history emphasizes that chat is ephemeral and something to tune in and out. Use email or something else for more permanent discussions.
> 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.
I didn't really feel the overhead of email until Gmail switched to their current theme. Now everything feels so sluggish and unwieldy that it really does constitute overhead, in real time seconds.
Whenever I used a native desktop software, like Thunderbird or Opera Mail, I was able to have conversations with people as quickly as in a chat client (and faster than texting, because of a real keyboard)
> 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 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 occur, so as to caution oneself against such usage, a little bit of thought before sending messages is always advised.
Specifically, if I can echo the primary differentiation, all you need to initiate a chat communication is a name and a message, that simplicity works a lot for people. I've used both e-mail and Slack, and a combination of both is great in my opinion, but the comparison can seen by an example message in my workflows (I don't use Slack anymore though):
Slack:
1) Find user/group by name lookup
2) Hi X, QUESTION_TEXT.
3) When done conversation, write outro
E-mail
1) Find user/group by name lookup, if user is not encoded in e-mail alias, query relevant databases
2) Write subject
3) Write intro, message, and outro
From my experience the reply from Slack 2) vs. E-mail 3) is much faster in the former case.
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 both do in parallell and concurrently when busy with more than one snowflake problem at a time.
I'm sometimes shocked at how slowly things get done now, compared to when I worked a support desk in the early 2000s. But mostly I'm just a little sad at the overhead generated by chat.
> 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
I think the crap is related to the amount of effort put into the message vs the medium. Making it easier/harder to send a message MIGHT change the quality, but I'd argue the decay of email over time was due to people failing to put in any effort DESPITE the minimum required.
I recall a coworker back in the late 90s talking about their usenet program, that made them click through a "Warning: What you are about to send will be read by thousands of people. Are you sure you want to send it?" message (paraphrased from memory). He found it daunting and therefore bad, I thought it was properly daunting.
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.
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.
>Use email or something else for more permanent discussions.
That assumes that every discussion which eventually is important enough to be made permanent starts out that way. One of the nice things about a history-keeping chat is that the barrier to starting conversation is low, and the barrier for preserving that conversation is also low (i.e. nil).
That has a double benefit - anything that becomes important is automatically preserved, so you could have tuned it out at the time and later be able to come back to it. There's no need to always focus on a chat if it's guaranteed to saved for later, unlike with IRC, which you can't always risk tuning out.
Nearly every client I work with these days expires their email after N days, where N ranges from 90 days to a year. Even corporate email pretty much has little history any longer, and it won't be long before the chat systems also come under the same policies across most corporates.
I don't quite understand why history is such a big deal for US-based enterprise chat, when the consistent US trend has been to nerf internal communications history.
Not that I agree with this nerfing. It just causes people in my observations to inefficiently store and retrieve items of interest to them elsewhere, mostly into files.
As soon as you update the protocol in any way, then it becomes an incompatible new not-IRC protocol. And if whatever you're building is not going to be compatible with IRC, then what's the point in starting with IRC? You might as well make a protocol from scratch like Mattermost or Slack has done.
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.
Well, IRC sorta as it does group chats. But email? Is there an XEP for that? XMPP can probably gateway to/from email, but XMPP can gateway to pretty much everything in the known universe...
An Email is a message with a subject line and potentially attachments. XMPP has the former in the core, can do the latter with XEP-231 (https://xmpp.org/extensions/xep-0231.html). A message can have one or multiple recipients, just like an XMPP message.
Email is really a simple form of messaging, where you put some content and expect the chain to route it to your destination; pretty much any IM system can emulate it, and XMPP goes a little bit beyond in providing the bits that different an email message from an IM message.
This is one of the reasons I love docker, for personal use it makes experimenting with new projects soooo easy.
Plus I have a simple traefik + compose setup so I can easily have it all automatically routed with a subdomain and https.
I might recommend something more robust for businesses in production but man is it easy. Want to try node-red? Done. Want to destroy - and it's gone, no need to futz around with dependencies.
Mattermost CEO here for a biased opinion. In my mind, the properties of a language can shape the outcome of an open source project.
As an example, when we were starting the Mattermost open source project we were considering a few options for different reasons:
1) Erlang - Real time properties made it nice for a high scale collaboration platform. The trade-off was that it's a really specialized language and there aren't that many people excited to learn Erlang.
2) C/C++ - Really powerful language and can compile to binary format, making install and upgrade easier for admins who don't want to be managing interpreted languages. Trade-off was it was an older language and there's fewer people excited about writing for it, and there can be a fair bit of nuance.
3) Python - Really popular, easy-to-read. Trade-off is things could get tricky as performance and scale needs increase. Also, doesn't support binary format, so more complex install and maintenance options would need to be used.
In the end we used Golang because it had many of the positive properties of Erlang, Python and C/C++ (compiles to binary, easy-to-read with gofmt, real-time support, etc.) and the trade-offs were fewer.
I am guilty of favoriting both go and rust for production deployments for the simplicity (usually a single binary, not a million files of some framework’s and dependencies files). Also it’s my hope that the modern libraries and language safety features and smaller size might be helpful in efficiency and security.
I'm probably going to sound old and grumpy but I've been using Slack for work for 5 years now, plus I've briefly checked out Mattermost and Riot/Matrix, and I've yet to be convinced that they couldn't just be replaced by a fancy IRC client that supports markdown, autoloads images n' stuff.
While they may offer some higher-ups some benefits I don't see anything I'd miss if we moved to IRC, quite the contrary — I could maybe even reclaim some of my RAM and get to choose a client to my preference (which is not an Electron app).
The only reason I haven't advocated replacing Slack with IRC is it lacks a sensible way of keeping history. Everyone either has to keep their client running and connected all the time (usually this is only feasible with tmux/screen on a server), rely on bouncer hacks, or something like IRCCloud which maintains the connection for you but is proprietary and not self-hostable.
I use https://riot.im for IRC for some channels. It stays connected, keeps archives, etc.
For small communities, I recommend Mattermost or Rocket Chat. I used to be a die-hard fan of irssi inside tmux, but seeing how tiny usability issues can really cause adoption issues, I wouldn't even recommend riot.im to less technical people.
>I've yet to be convinced that they couldn't just be replaced by a fancy IRC client that supports markdown, autoloads images n' stuff.
I've heard this so many times I'm surprised nobody has done it yet.
You'd need a client-proxy, or server extension to detect idle desktop clients so you can route messages to a mobile device, for maximum "life work balance."
One more differentiating factor for Mattermost is its extra special focus security. The product offers the industry’s most flexible and secure instant messaging capabilities across all devices.
Isn't Mattermost fundamentally the same thing, architecturally, as Slack? Slack has one of the industry's stronger security teams. I don't see the differentiator here.
I'm a big fan of Mattermost but industry’s most flexible and secure instant messaging capabilities might be a tad exaggerated.
By way of comparison, I will indulge in a shameless plug for Webex Teams: our customers have the option of hosting their own key server, on-premise, under their control. We have no ways of seeing any content in messages: payload and title are encrypted and participants are IDs that are usually federated with their own identity provider.
Decryption happens locally in the desktop/mobile client, after obtaining the right keys. Yes that's more computationally expensive and carries some complexity. But it's a very different model than just building a single big vault of data. And it also works when users in 2 different companies talk to each other, both with their own key servers.
Used Mattermost for a year, and I can attest to it's shittiness. There is a bug during switching channels that pins your view to some random location weeks before the latest post. The result is that switching channel in Mattermost has a 60% chance of requiring you to spend the next 30 seconds scrolling the window to the bottommost-recent-message. Horrible.
Mattermost PM here, I agree that this is not a good experience, thank you for sharing @jetru.
There is development in progress to let you jump directly to new messages when you land on the oldest unread message in a channel. This lets you get directly to the latest message.
I'm not entirely sure if this is the same use case you have, but if you're open to testing the new development and share feedback, we'd love to hear!
My Fortune 500 healthcare company successfully uses Mattermost because the lawyers aren't comfortable with us using slack. It's been great. Thank you @it33 and team.
p.s. we haven't run into the issue 6320 (users archiving channels), for exactly the reasons @it33 described in the issue report. He didn't explain it well, but permissions is a complex rathole, un-archive is a simple workflow for admins and if there's continued abuse, just ban the user.
I completely concur. We used Rocket.Chat (running containerized on OpenShift, our Kubernetes distro) for a time at Red Hat to support the bulk of Red Hat Consulting. Many thousands of messages per minute sustained throughput. All of Red Hat has "restandardized" in the last year but I personally miss Rocket.Chat.
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 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.
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.
Fairly anecdotal but feature breakages usually more common in Node apps than Go, it does "matter:most" for end users. It's not because of Node itself but the sheer amount of npm packages what's responsible for those.
As with mastodon and similar projects - having to deploy, secure and maintain a db server is a big friction point, I wish projects aiming at self-hosting would internalize that and use something like sqlite for small to moderate deployments and would even as go as far as suggesting that it is unlikely to ever be deployed at a scale that a single-writer-multi-reader sqlite service on a decent machine can't handle.
We've been using Hipchat for years at $work. There's very little is say is "good" about it, it was just the best option at the time as it needed to be self-hosted.
Mattermost is being trialled now, pasting code doesn't seem a lot better, but the overall experience is.
As a place that likes Go/Docker it has potential for us.
Thanks for the response, we'll be sure to post anything that looks like a bug! At this point it's likely our operations team simply hadn't configured it correctly (it is a trial and not a production deployment).
The $ dates back to either shell scripting or perl (and applies to PHP as well), and this is a reasonably common usage in tech/programming circles. See also $dayjob.
It's unfortunate that there's a specific terminology conflict in this case.
The article talks about Hipchat as a competitor but HipChat was shut down by Atlassian and HipChat users were strongly encouraged to adopt Slack: https://www.atlassian.com/partnerships/slack
I'm not sure the exact details of the purchase, I just know that a deadline was placed on our HipChat installation at work (it would not be renewed, and only supported until date X).
It seems their ultimate goal was to shut down a competitor, so, with the result being the same, I suppose the specifics matter very little.
Another thing that happened is GitHub acquired both Gitter and Spectrum. Gitter deprecated its mobile app. Spectrum's founder has been working on other stuff at GitHub. Microsoft has Teams so that might have something to do with it.
Does anyone have legal experience and know what the restrictions are to forking of the Mattermost project?
I'm a programmer with experience in backend development and security and would be willing to donate some time to work on developing a stronger community implementation of Mattermost - only I'm not sure what the legally correct way is to go about it. What I'm hoping to find is a FOSS sherpa to help me navigate setting up a new project.
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...
Slack is using cloud/external storage. Many companies have policies against that,making MM is surprisingly popular in banks and such. Personally, can't tell the difference between two
Standard tls between server and client helps against any outside threat. The only threat from which e2ee helps better than tls comes from the server admin.
Now, do you REALLY need end to end encryption to protect yourself from a person running your team chat server?
As some commenters pointed out, the name "MatterMost" might be a crucial thing holding this from reaching the development mainstream as an alternative to slack/teams, which aren't very dev friendly
Well, it's not free (or gratis) is it? It just happens to be included in the azure ad/o365/exchange plans? So, if you're on gsuite, for example - ms teams isn't "free"?
Last I checked, Jabber could completely replace all of these things except there were no good iPhone clients. Anyone know of an even remotely usable iPhone Jabber client?
Last time I checked, you had to have a very specific server/client combo for very basic features like mobile app, offline messages, and multi-device message history. Grabbing a random server or client may result in some (or all) features missing.
That’s why we recommended Slack for the next workplace. No chance to get anything wrong, and no need for backups either.
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/
That’s the problem with Slack — too easy to switch to equivalent or superior alternatives. I suspect this issue will continue to weigh on their stock price.
That might be true for many companies, but I think also that many companies could benefit from federation -- they just don't know it.
It has been standard practise everywhere I've worked that in business-to-business relations, people have to create accounts for each other's Slack networks.
That is ridiculous. Imagine having to sign up for separate email accounts on the email servers of all of your customers. It just wouldn't be acceptable other than in extreme circumstances; you already have an email account -- why shouldn't you be able to email with your customers/suppliers/vendors from that?
But we accept it with IM because we're so jaded by now. Though if federation was a more well understood concept, I'm sure multiple of the companies I've worked at would jump at the chance of not putting its business relations through the pain of registering dozens of accounts to IM with different people.
So run a local server and turn federation off. Like you can run a private e-mail server. Why not use and contribute to the common protocol that does allow federation? I see no point for a FOSS project in proliferating non federated IM protocols, and wasting resources on that, while federated ones still didn't even reach wide adoption.
I view it the opposite way. It's waste of time to reinvent the wheel and not concentrate resources. Federated protocol can be used without federation fine, but not the other way around. For FOSS projects, not doing it is strange, especially when lack of adoption for federated options is still a major global problem.
So I'd question the intent behind this particular project. For those who don't care about openness (like Slack), I'd expect such behavior. But for open projects - not really.
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
It's amazing just how bad Google's UIs are, across all their products. There are two different versions of "archived" in Gmail. Maps hides options for types of routes under a settings menu under a screen fold (rather than toggles when you ask for alternate routes). Basic Android features like "stop a process" moves location seemingly every year. I was so confused by GCP that I just went with Azure and got on with life.
I find Apple's interfaces confusing because I've been a Windows developer for 20 years, but at least they seem to stay consistent. Microsoft is in the middle of completely revamping their settings UI, but I agree with the forgot they are going on and they at least didn't delete the old UIs. WTF is wrong with Google?
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.
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.