
Story of Mattermost: Open-Sourced Competitor to Slack - ankitkumar98
https://breakoutstartups.substack.com/p/breakout-startups-23-mattermost
======
pietroglyph
The open-source Mattermost _intentionally_ lacks a couple of pieces of basic
functionality to push you to pay, like the ability to stop regular users from
deleting channels, and no way to set a reasonable password policy that
requires more than 5 characters.

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

[https://github.com/mattermost/mattermost-
server/issues/6320](https://github.com/mattermost/mattermost-
server/issues/6320)

[https://github.com/mattermost/mattermost-
server/issues/5935](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.

~~~
sneak
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.

[https://github.com/mattermost/mattermost-
server/blob/master/...](https://github.com/mattermost/mattermost-
server/blob/master/utils/license.go)

~~~
Operyl
I believe they store the enterprise specific code in another git repo that has
to be checked out, for one (from reading their Makefile).

~~~
sneak
The binaries they release (including that code) are MIT licensed according to
their readme, which means that modifying those should also be no problem.

~~~
Operyl
This is true, you could probably edit out the publickey and then generate your
own license pretty easily.

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

~~~
duskwuff
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.

~~~
jrochkind1
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.

~~~
duskwuff
"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.

~~~
jrochkind1
Yeah, that seems right.

------
newsat13
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?

~~~
kfrzcode
Be the change! [https://github.com/mattermost/mattermost-
server](https://github.com/mattermost/mattermost-server)

~~~
Maxious
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.

[https://github.com/mattermost/mattermost-
server/issues/6320](https://github.com/mattermost/mattermost-
server/issues/6320)

------
jjeaff
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.

~~~
arminiusreturns
Did you do any integrations for voice chat?

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

~~~
arminiusreturns
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).

~~~
dbrgn
Jitsi is WebRTC as well :)

------
sjburt
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.

~~~
it33
Thanks sjburt, Mattermost CEO here. We have 800+ upvotes that agree with you,
here a link to the feature proposal forum post and open tickets on this:
[https://mattermost.uservoice.com/forums/306457-general/sugge...](https://mattermost.uservoice.com/forums/306457-general/suggestions/10975938-ios-
and-android-apps-should-allow-multiple-server)

Anyone interested in contributing to the work, we’d welcome your help

~~~
saagarjha
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?

~~~
it33
Ticket is unscheduled, work is open source, if you're interested in
contributing please comment on the ticket and the team can discuss:
[https://mattermost.atlassian.net/browse/MM-11067](https://mattermost.atlassian.net/browse/MM-11067)

On hiring, yes, we're hiring too, that's perhaps the most committed route to
take: [https://mattermost.com/careers/](https://mattermost.com/careers/)

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

~~~
neumann
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!

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

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

------
bob1029
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.

~~~
andybak
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.

~~~
bob1029
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.

~~~
saagarjha
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.

------
maxpert
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](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.

~~~
indigochill
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.

~~~
dijit
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.

I really dislike teams.

------
subsaharancoder
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.

~~~
it33
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

~~~
bubba1236
don't waste ur time they're pushing chime hard at Amazon lol

~~~
it33
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.

------
zer00eyz
This space is downright awful.

20+ years ago corporate IT was concerned about the phone on my desk (how
quaint).

They put one there on the back of a PBX.

They put in a system that was LOCAL for local needs and accessed the public
network when it needed to.

It worked because it was built on the back of a proven standard (telephone).

We don't have a working chat standard, and it shows and we need to fix it.

~~~
davidw
> 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.

~~~
ergothus
> 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.

~~~
e12e
> 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?

~~~
mrmuagi
> Email has hefty overhead per message.

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

~~~
e12e
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.

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

[0] [https://slack.com/help/articles/203457187-Customize-
message-...](https://slack.com/help/articles/203457187-Customize-message-and-
file-retention-policies)

~~~
RockIslandLine
When I worked as a stock trader, all of our chats were logged as a matter of
legality.

------
mikece
I like that Mattermost is written in Go and can deploy on-prem with Docker.
Those are two huge points for MM over Slack IMO.

~~~
tcbasche
Why does what language it's written in matter? I like Go too but I'm genuinely
curious

~~~
it33
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.

------
lillesvin
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).

~~~
shric
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.

~~~
mgbmtl
I use [https://riot.im](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.

------
j88439h84
Riot seems like a good option these days.

~~~
ian-bateman
Riot / Matrix is also open source, has integration with Slack, Gitter, & IRC
out of the box, and is self-hostable entirely for free.

------
tptacek
_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.

~~~
athenot
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.

[https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCol...](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/spark/hybridservices/datasecurity/cmgt_b_hybrid-
data-security/cmgt_b_deployment-guide-for-hybrid-
data_chapter_00.html#concept_74088EF79823B0DD92298C21924E6EC3)

------
jetru
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.

~~~
jasonblais
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!

Pull request with an open test server is available here:
[https://github.com/mattermost/mattermost-
webapp/pull/4132#is...](https://github.com/mattermost/mattermost-
webapp/pull/4132#issuecomment-566993406)

------
asah
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.

~~~
it33
Thanks for wording it so much more concisely and clearly! Love your post,
sharing it here: [https://github.com/mattermost/mattermost-
server/issues/6320#...](https://github.com/mattermost/mattermost-
server/issues/6320#issuecomment-567051983)

------
gmenegatti
Rocket.chat is also a very nice alternative and supports more use cases. We
use it internally and also as part of our product.

~~~
oso2k
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.

------
gaogao
> The company was founded in 2011 as “SpinPunch, Inc”, an HTML5 game engine
> developer.

Neat that both Mattermost and Slack have the same origin story of game
developers building an internal chat app and then pivoting to that.

------
gregf
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.

~~~
bathtub365
Why does it matter what it’s written in?

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

~~~
spookthesunset
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.

~~~
shantly
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.

------
virtualpotato
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.

~~~
slig
For $20/m ($5 for a droplet and $15 for a managed DB instance) you can have
that peace of mind on DO.

~~~
sjy
Paying $15/month for a managed database is not self-hosting.

~~~
slig
One would still have the fun of maintaining the application server updated.

------
alias_neo
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.

~~~
askafriend
The "$work" notation could be mistaken for the Slack stock ticker. The "$" is
how you commonly denote stocks, and "WORK" is the ticker for Slack.

~~~
jamie_ca
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.

------
mikece
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](https://www.atlassian.com/partnerships/slack)

~~~
jjeaff
Just for clarity, Hipchat users were strongly encouraged to move to Slack
because slack purchased Hipchat from Atlassian.

~~~
jnwatson
Only because Atlassian abandoned HipChat after trying to replace it.

------
yulaow
My team uses it since a year, it works flawlessly for what we need.

~~~
it33
Mattermost CEO here, thanks yulaow!! Our contributors love comments like this,
hugely appreciated,

------
pyrosome
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.

~~~
saagarjha
The Mattermost source code is AGPL. Fork away!

------
Tharkun
I like Mattermost. My only gripe with it is that it's a bit of a pain to
upgrade. Would be nice if they were to automate the upgrade procedure.

~~~
the_icelander
Check out the Kubernetes operator, which handles zero-downtime upgrades as
well as blue/green deployments and canary builds:
[https://github.com/mattermost/mattermost-
operator](https://github.com/mattermost/mattermost-operator)

------
sircastor
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...

~~~
AzzieElbab
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

------
secfirstmd
I'm a big Mattermost fan but it really needs end to ends encryption. Also the
Android mobile app is pretty weak.

~~~
Andrew_nenakhov
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?

~~~
the_icelander
Not for business, but if you want to get your friends on a chat server it
would be easier if they knew you couldn't see everything they said.

------
jiberwarrior
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

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

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

~~~
e12e
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"?

------
aidenn0
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?

~~~
theamk
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.

------
moedersmooiste
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.

~~~
jasonblais
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/](https://mattermost.com/nonprofit/)

------
bblpeter
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.

------
shmerl
It's not using Matrix? What's the point in making an open source however non
federated IM service?

~~~
detaro
Many companies using such a system wouldn't even want federation, and it adds
a bunch of complexity.

~~~
shmerl
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.

~~~
detaro
Because then you're bound to the common protocol and it's development process,
which is a waste if you have no intention of using federation.

~~~
shmerl
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.

------
alexnewman
The days of free as in sabotage are over. Linux broke it.

------
mderazon
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

~~~
moron4hire
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?

~~~
stormbeta
RIP Inbox. Still a drastically better UI for a lot of users than Gmail is.

~~~
bishalb
It was terribly slow/heavy though. Although the Gmail hi isn't much faster
either. I think outlook/office365 email has a much faster and better ui.

