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.
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.
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.
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 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.
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.
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 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.
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.
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.
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.
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.
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.
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).
> 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'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 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 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.
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.
>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.
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.
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.
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/
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.
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.
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.
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.
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?
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.
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.
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.
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.
"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.
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.
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.
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.
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).
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.
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!
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.
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.
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.
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.
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?
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?
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.
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.
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.
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
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
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.
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?
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?
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
247 comments
[ 6.3 ms ] story [ 261 ms ] thread> 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.
https://github.com/mattermost/mattermost-server/issues/6320
Open source is only as powerful as the community's willingness to maintain a fork.
Very straightforward and easy to set up.
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.
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.
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)
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.
I do miss GIFs, but eh.
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!
Alternate perspective: they never left Lync/Communicator - it's just been rebranded.
Not entirely accurate. It's was bought by Slack, and then shut down.
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.
Where either of these what you were interested in?
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).
Fantastic! Thanks for sharing back--comments like this are super motivating for everyone working on the project,
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.
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.
It's unfortunate that there's a specific terminology conflict in this case.
Would love to squash the bug for you, open to filing an issue?> https://github.com/mattermost/mattermost-server/issues/new
We used to send bug coins just for release candidates, but if you find a bug in production you get one too now: https://www.youtube.com/watch?v=7D6FJsdE_aY
Best regards to the team.
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.
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.
[1] - https://github.com/thelounge/thelounge
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.
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)
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.
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.
[0] https://slack.com/help/articles/203457187-Customize-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.
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.
No, it sucks.
No reason you couldn't update the protocol to improve some things if you wanted to invest in it somewhat seriously.
https://ircv3.net/support/networks.html
And it does work right now, pretty well, for a lot of people, even if it could be better, which was the original thing I was refuting.
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.
The Linux Kernel was built via email.
You can say you don't prefer it, but plenty of people have built some very big, complex projects via email.
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.
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.
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.
Those eligible for a nonprofit license can also get the benefits of E10 offering (including LDAP) with special pricing https://mattermost.com/nonprofit/
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.
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.
demoware
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.
Until one day, when you have some sort of incident, and it will have become very worth your while to "deal with" access control.
It's also way easier, cheaper and practical to prevent the first example than the second one.
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.
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.
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 ?
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.
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.
No license includes anything like that. That’s not what a software license is.
The usual term for it is “Open Core”, and is a legitimate, if frowned upon by many, practice:
https://en.wikipedia.org/wiki/Open-core_model
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.
https://en.m.wikipedia.org/wiki/Crippleware
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 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!
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.
I've shared a reply on the ticket here: https://github.com/mattermost/mattermost-server/issues/6320#...
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?
What controls are in place to prevent this from happening in the Team Edition?
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.
[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.
disclaimer: co-founder of cloudron.io
Now, do you REALLY need end to end encryption to protect yourself from a person running your team chat server?
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.
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.
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.
only if you haven't tried slack.
easy. they didn't:
https://twitter.com/msquinn/status/1179874609899827200
https://venturebeat.com/2019/11/21/microsoft-teams-giddy-gro...
MSFT decided that one clear way to increase their share price is for their new product to run at all times for everyone.
That’s why we recommended Slack for the next workplace. No chance to get anything wrong, and no need for backups either.
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
Not for long, as it's been killed and is now moribund.
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.
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?
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.
Anyone interested in contributing to the work, we’d welcome your help
On hiring, yes, we're hiring too, that's perhaps the most committed route to take: https://mattermost.com/careers/