Call only in DMs is a massive step backwards!

[Tampa]

I get that you all want people to move to the licensed plans to make back the money from all the capital investment, but actively paywalling existing features without actually upgrading them is disgusting practice. It's a sure-fire way to get users to not upgrade their installations or even downgrade them. Trying to force small teams to hand over hundreds per month just for communications is a great way to drive them back to the competition. You want to paywall stuff? Make it worth it! You want to sell licenses? Scale them properly with team size and revenues. Otherwise, there goes the userbase, which by the way contributes to your success through open source, so maybe have a bit of respect towards them!

[glouton]

I can not agree more with @Tampa

We're a tiny team of 3 with one third of the members who doesn't like Mattermost already and with whom I'm struggling to explain that it's great.

Now this...

[steccas]

I agree, this is really shameful

[rtfm98]

I totally agree. It's a shame to restrict already existing (!) features for users without valid license! I'd get it if this was a restriction from the beginning of Mattermost Calls, but this is total crap. This won't help you to reach your goal of getting more paying customers. Indeed, they will just migrate to other solutions as soon as possible.

To claim group calls are a feature that aren't used so much as calls in DMs shows, that you don't know what most of your users are doing the whole day.

I'm really disappointed.

[novo-github]

Is there any alternative for this? I tried jitsi-plugin before, but is not available in 'official plugins' anymore. Its not the best, but a work around.

[Tampa]

@novo-github You can stay on v9 and even roll back from v10 still, though you may have to nuke the plugin manually so it installs the previously packaged version. Outside of that, the harder approach is to fork the plugin and reverse the changes, which means maintaining a fork and manually deploying it each version change to make sure it stays fixed.

Been a couple days since this went up. Over on reddit the discussion also ended with the supposed CEO offering to hear comments, but not saying anything on what's going to happen. I suspect they'll be just waiting it out and ignore the complaints as is tradition. So if any of you folks want this actually reversed, make sure to keep putting them on blast for it.

After all as they say themselves "We are open to feedback and share our ideas constructively and respectfully." So maybe some of the higher ups can chime in as to what the thought process was behind this abomination of a decision: https://mattermost.com/about-us/

[Nyralei]

I totally agree with this. Also this sets a precedent and who knows what else will be paywalled.

[markatk]

This is such a disappointment. We are a small team using mattermost because we use gitlab. Removing an already implemented feature for free users "in order to focus supportability and quality on licensed servers" does not make any sense. How does it impact licensed servers by blocking an existing feature for unlicensed servers (which do not get support anyway).

I think this will be the decission to drive us away from mattermost. If we need to pay to get the minimum featureset we need to work we will ultimatly choose a competitve product which offers way more features for less money.

I really do support the open source movement and I am willing to pay for software but not like this. There is so much potential and many missing features and opportunities to bundle features in licensed servers for good reasons. This is not the way to convince me to pay.

[Tampa]

Seeing as there seems to now be radio silence, which is probably an attempt to let the whole thing blow over, how about this.

https://gist.github.com/Tampa/090bb7ff89c0e15a4570b6c4d9de7736

Anyone with some experience in golang can probably verify if this will work or not, or could just test it. Reversing just the commit that made the change might be enough. Kinda surprised there hasn't been a public fork yet, but that's probably the next step here.

[codingPotato21]

Extremely frustrating, Its a big step back. Someone might make a fork if it's possible or even maybe a new plugin that is similar in functionality.

Currently, we updated to V10 but using the old calls plugin version which is working just fine for us so far. However, we cannot update to a newer plugin version so it might stop working when we update mattermost in the future.

[novo-github]

Following @codingPotato21 's thought , I went ahead and downgraded the mattermost.calls plugin. In steps, I have disabled and removed the latest mattermost.calls plugin from the SystemConsole, enabled 'plugin Uploads' from config file, uploaded the plugin package from https://github.com/mattermost/mattermost-plugin-calls/releases/tag/v0.29.2 which is <1.0.0 with breaking changes. This seems to give back the group calls feature, but I am still not aware of the drawbacks. Hoping for a fix soon.

If I think back, there was a jitsi plugin, that enabled voice and video calling. Can't find it at the moment, but worth a try. I'd hate it if I have to use Zoom / Teams plugin for this :|

[mikebakke]

I've "sold" Mattermost for a long time to others as a great solution. As I typically make 1:1 calls this is not in itself a deal-breaker but confirms the direction of travel together with the removal of core support for boards (after incessant nagging to install it in the first place). Seems pretty clear enshittification is firmly on the menu here now. I've been evaluating a switch to Matrix for some time but have held off as it's more "flakey" and "amateur" with excessive complexity from the e2ee but I've now found a very palatable fork of that (Conduwuit) which is a breeze to deploy and does support group calling and (most importantly) threads. I'm waiting to see if Matrix V2 - due "soon (tm)" will remove the rough edges - if so, then I have a viable alternative (until they too jump the shark). As an aside - the stated reason for removal from team-edition is blatant spin.... If you're going this direction then at least own it instead of gas-lighting.

[Judx]

Totally agree with @Tampa and others here. Paywalling existing features without actually enhancing them feels like a cash grab, especially for small teams that rely on open-source contributions. Any change not to do this?

[ados8]

Mattermost has been doing this for a while.
They announced OpenID/SSO for all Mattermost editions then it never came out for free edition.
They decided to quietly not release it likely because it made the paid LDAP integration bypass able.
I would return to Rocket.Chat the moment they stopped forcing MongoDB but they won't.

[lexo-mfleuti]

As small business we only need core communication functions. Why not create a cheap package for small businesses? We'd be Ok paying 15-20$ per month for Mattermost. We don't need all the Enterprise functions. I'd be OK with paying something but the only choice you leave are the highly expensive Enterprise plans. I am sure Mattermost would earn much more money by introducing a cheap small-business plan that supports the core communication features than trying to force entrprise plans on all these small companies who do not need 95% of these functions.

[Judx]

As small business we only need core communication functions. Why not create a cheap package for small businesses? We'd be Ok paying 15-20$ per month for Mattermost. We don't need all the Enterprise functions. I'd be OK with paying something but the only choice you leave are the highly expensive Enterprise plans. I am sure Mattermost would earn much more money by introducing a cheap small-business plan that supports the core communication features than trying to force entrprise plans on all these small companies who do not need 95% of these functions.

Great pitch! Small fee of $10-$20 / month for enhanced core functions is a great idea. Lite Mattermost. Can this be done?

[Tampa]

While I think a small business type license is definitely a good idea. I don't think even that would justify locking previously existing features behind a paywall unless there is additional stuff added to it, because pulling things out of open source into license is always going to be a dick move no matter what. When software is better because of the collective effort put into it, to treat them with "now pay up suckers" is just not okay.

On the reddit thread I did outline multiple options and their pros and cons, but the supposed ceo of the mattermost org has not really replied to those beyond the initial outreach they did. Not sure what their github user is else I'd tag them.

What's telling is that despite the activity on this ticket no one higher in the org has responded yet. Looking like they are trying to wait this out and we should absolutely not let them!

[lexo-mfleuti]

Personally I think: Yes, it is/was a "dick move" but Mattermost is a company paying developers to develop things and releases their products as OpenSource. They can do with their product whatever they want. If we are not OK with that, we can fork it and change the code to our liking. We just did the simpler thing and setup an internal Jitsi Server and linked that in the Mattermost settings. Which is just as good if not better than the Calls Plugin since it supports video conference and lots of other features. For small companies a really simple server with 512MB RAM and 1 Core CPU is enough. I am annoyed by how this is playing out but there are (good) alternatives. And the more they close and limit their system, the farther away they drive the small businesses. At one point, they will just be another Slack on the market, working only for large corporations and there will be new products like Mattermost for us small businesses. Maybe someone else will fork Mattermost, call it differently and continue another path. Since switching the system is expensive and time consuming, I would be OK to pay a "Small Business Package Fee" for the product. We are paying for various services we need daily and a fee of 15-20$ would be OK for us. Mattermost is a good system. But those Enterprise Plans are just way too expensive reaching 200$/month and more for our small team where we pay a lot of overhead for functions we never ever use.

Personally, I think, it would be even better to have prices for features. For example I'd like to being able to unlock the Group functionality. That would be kind of handy to us (but not necessary). We'd pay a fair 1-time-fee for unlocking it. That would be nice.

[SnowMB]

mattermost-plugin-calls/server/enterprise/license.go

Line 61 in 1620c68

return e.isAtLeastE10Licensed() || os.Getenv("MM_CALLS_GROUP_CALLS_ALLOWED") == "true"

I just gonna leave this here. Let's see when it is removed.

[patzm]

no go pro, but couldn't you simply set the environment variable MM_CALLS_GROUP_CALLS_ALLOWED=true ? 🤔

[rtfm98]

According to this I would say: that should work.
With go env vars as well as system env vars.

The interesting question is, if it's sufficient to set this var in the systemd file 🤔

[glouton]

Talking about license:
https://github.com/mattermost/mattermost-plugin-calls/blob/main/LICENSE

It's a mix and I'm no lawyer but seems to me that source code is free:

You may be licensed to use source code to create compiled versions not produced by Mattermost, Inc. in one of two ways:

1. Under the Free Software Foundation’s GNU AGPL v.3.0, subject to the exceptions outlined in this policy;

I wonder about these exceptions. Can something under AGPL have execeptions?

[lexo-mfleuti]

Hahaha! This actually works (for now) :)

Edit the service file and add the ENVIRONMENT variable:

nano /usr/lib/systemd/system/mattermost.service

[Unit]
Description=Mattermost
After=mattermost-net-bind.service
After=network.target
After=postgresql.service
BindsTo=postgresql.service

[Service]
Type=notify
Environment=MM_CALLS_GROUP_CALLS_ALLOWED=true
ExecStart=/opt/mattermost/bin/mattermost
TimeoutStartSec=3600
KillMode=mixed
Restart=always
RestartSec=10
WorkingDirectory=/opt/mattermost
User=mattermost
Group=mattermost
LimitNOFILE=49152

[Install]
WantedBy=postgresql.service

systemctl daemon-reload

systemctl stop mattermost && sleep 8 && sytsemctl start mattermost

Big thanks to the Mattermost programmers leaving this "loopwhole" for the Pros ;)

[glouton]

Seems to work with docker as well:

services:
  mattermost:
    environment:
      # additional settings
      - MM_CALLS_GROUP_CALLS_ALLOWED=true

Thank you developers.

Let's hope they won't remove this env var now.

[ados8]

Seems to work with docker as well:

services:
  mattermost:
    environment:
      # additional settings
      - MM_CALLS_GROUP_CALLS_ALLOWED=true

Thank you developers.

Let's hope they won't remove this env var now.

Verified working with Mattermost Version: 10.1.1 Build Number: 11162711545

[Tampa]

That is until that is changed too.

By the way, good job on packaging the plugin in the tar. It contains a ./ directory with a different user, so extracting directly from the tar into the plugins folder will change the user of the plugins folder and even mess with the permissions. Who packaged it like that? Don't include that stuff! 🙄

[mathieu-rossignol]

For those running mattermost embedded in self hosted Gitlab CE, mattermost is not run as a regular service and the /usr/lib/systemd/system/mattermost.service file does not exist. To set the workaround MM_CALLS_GROUP_CALLS_ALLOWED variable for the mattermost process, do it in the gitlab general /etc/gitlab/gitlab.rb config file and add:

# Workaround the limitation of Calls disabled in Groups (only allowed in 1/1 conversations)
mattermost['env'] = {
  'MM_CALLS_GROUP_CALLS_ALLOWED' => 'true'
}

Then run gitlab-ctl reconfigure for the change to take effect.
Calls are back in groups for me with this trick.

[Superriot]

Verified on a Gitlab Ominibus deployment wit Docker and gitlab/gitlab-ce:17.5.1-ce.0:

environment:
      GITLAB_SKIP_UNMIGRATED_DATA_CHECK: "true"
      GITLAB_OMNIBUS_CONFIG: |
            ...
            mattermost['MM_CALLS_GROUP_CALLS_ALLOWED'] = true

[bilalmbt]

isn't there a way to set that env variable on Cloudron ? I'm running mattermost on it and the config.json gets reset each time I restart the app for the env variables to be taken into account.

[Superriot]

isn't there a way to set that env variable on Cloudron ? I'm running mattermost on it and the config.json gets reset each time I restart the app for the env variables to be taken into account.

Just go in the Mattermost-Calls-Plugin Repo and download the Release: v0.29.1.

Install it in Mattermost, after that the group calls will be available again.

[mikebakke]

It's very nice that there is a work-around identified but it doesn't affect the underlying issue. If Mattermost really care about locking it out then that parameter is trivial to kill and at some point it will be.

For now? I stay on 9.11 as it does what I need - I have client installers for the current version so I'll just stay here. Yes, yes, security fixes etc which is why I'll keep looking at Matrix 2.0 - saw a quick and dirty docker implementation which seemed to address most of my concerns with it so will likely move to that as "main" and just have my current MM as a static archive.

Mega, mega disappointed as I prefer Mattermost but what is next? I clung on to Twitter for far too long but eventually jumped to Bluesky and Mastodon - lesson learned - once things start going in a direction, they usually keep going that way.

[jakoblo]

The past three years, I’ve been an ardent advocate for Mattermost, particularly for small teams. However, after transitioning my entire team to Mattermost, I find myself in a bit of a predicament. The standout feature of Mattermost was its ability to centralize all our communication needs. Now, we’re faced with the task of searching for a suitable tool to replace Mattermost for our internal communication and occasional group calls.

We’re at a loss about what to do next. The workaround what was found likely won’t be viable in the long run. A 10€ per user per month license simply doesn’t make sense for us. While we’re willing to support the project, we’re not interested in another subscription-based model.