Feedback on Collaboration for Mission-Critical Work

Feedback
22

Thanks @Chostakovitch, appreciate your feedback here. This is a forum and I was hoping to hear from other people who wanted to speak on user limits and warnings, etc.

We’ve been talking to some of the larger deployments we know about, and we’ve had a few reach out to us, and it’s not a huge number, and they’ve mostly read this thread.

It’s been around 7 months since we started the discussion around limits, and it seems that outside a very small handful of admins for extremely large deployments (@bbodenmiller @ThiefMaster @Chostakovitch), there doesn’t seem to be a lot of controversy.

That said, I do really appreciate everyone’s input and perspectives, and I learn a lot from the discussions, and they certainly do impact our thinking.

So to continue:

But in that case, why isn’t a warning banner for administrators enough ? You gave the example where “the original admin had left […] the new admin wasn’t aware of the scaling guidelines”. Well, that is the purpose of warnings: to prevent this kind of problems, make information available and to point to the appropriate documentation (hardware, pricing, whatever). No sysadmin would ever deliberately let their instance become slow and unusable . Don’t you think so ? Generally speaking, in the open source world, programs warn people, but always provide a way to bypass the warning if people know what they’re doing (think rm -rf --no-preserve-root / ).

If the first admin turns off warnings, there’s much more risk the replacement admin won’t see the warnings and be alerted to scale limitations in the original deployment.

Hence the warnings for the edition that Mattermost, Inc. compiles has warnings at 5,000 users that can’t be dismissed. Also, a safety limit/hard limit at 11,000 users seems pretty non-controversial for a Mattermost Team Edition offering designed for 50 users.

Anyone else looking for limit-free builds can check there : Index of /projects/mattermost/

First, really appreciate Framasoft for offering the fork, as it solves a lot of problems discussed in this thread.

Just one minor note–typically when an open source project is forked it’ll be renamed so there’s no confusion (e.g. OpenSearch vs. Elasticsearch, Jenkins vs. Hudson, etc.). Also, “Mattermost” is trademarked, and the trademark of the name of an open source project is typically the only IP that’s protected.

Does Framasoft have a roadmap to change the name of the fork, so the IP would then be clean?

Ultimately, we added safety limits to protect the Mattermost brand. A fork without limits, that removes the Mattermost brand may be a way to meet both the brand issues and the broader community needs.

PS: Speaking about brand, wondering if there was any feedback from this group about the “Free Edition” label design that was proposed a while ago in forums?

This was another effort to protect Mattermost brand, and reducing confusion with end users about our free offering vs. paid offering.

While the forums have been quiet on the new label, I’ve talked to some admins running the free version and there’s a little bit of wincing to put “Free Edition” so front and center (though they appreciate why it’s needed). One idea on iteration was to have the label show only after a certain level of scale was reached so that low scale deployments (e.g. small gamer groups/hobbyists) wouldn’t see the label, but if it was used in a scaled context the label would appear.

The counter argument to this behavior is that generally infrastructure people don’t like to have things change on them, so just having it static from the start is the better design. Open to any feedback or opinions here.

23

Just to provide another piece of feedback: System76 currently uses Mattermost for the public Pop!_OS community chat. This is not an internal team (or an internal “enterprise deployment” grifting on the team edition), this is an alternative to IRC or Discord that anyone can sign up for.

We currently have 12,420 users in the default channel. Purging inactive users isn’t something we particularly want to do (as we never know when someone will want to come back), and would only be a band-aid solution since we’re always gaining new users.

We’ve been putting up with the red ERROR_SAFETY_LIMITS_EXCEEDED showing up for admins for the past couple of months, but we’d need to evaluate alternatives to Mattermost if new users were actually prevented from signing up.

24

@Chostakovitch would you be open to renaming Framasoft’s Limitless fork of Mattermost to another name and making it available to System76?

If so, it might be what @jacobgkau needs for the community he supports, while also removing the Mattermost brand from association with what we feel is an over use of the Team Edition we compile, and a risk to our brand.

Also, @jacobgkau thank you for posting, and welcome to the community!

25

Thank you!

Just to be clear on a couple of things, I have shared the Framasoft link when discussing this internally. Right now, we use Docker to deploy Mattermost (we have a custom Dockerfile based on the mattermost/mattermost-enterprise-edition image). As a small business, we generally choose infrastructure that’s low-touch, and the chat server is not our web team’s highest priority; I’m not sure how the cost/benefit analysis of them spinning an entirely custom Dockerfile based on a fork will go. It would be a lot more seamless if there was a drop-in replacement image on Dockerhub, but I don’t know if Framasoft is interested in distributing something like that.

We’ve had talk of switching to an entirely different system such as Matrix if this does become a problem. I don’t think we’ll be making any immediate moves, as we’re currently on the 9.5 ESR branch, which is supported until November.

Also, we’ve generally been proud to promote Mattermost as a free/libre & open-source alternative to proprietary systems such as Discord or Slack that some other FOSS communities use. I think it’s unfortunate that you see a large, public, open-source community using your product as a “risk to your brand” rather than an asset. However, it sounds like we are using your product for a use case that was not intended (although we’ve had no issues with stability despite the high number of users).

26

Hello @it33_mattermost, Chostakovitch is not a member of Framasoft, so they can’t rename the fork. But I am a member of Framasoft. The fork is now renamed to Mostlymatter.

Please note that we only forked the backend and we only release the compiled backend binaries.

1 Like
27

Thanks @framasky! Greatly appreciated :raised_hands::pray:

@jacobgkau just to clarify if you’re using something that’s called mattermost/mattermost-enterprise-edition I think we might be using the “Enterprise Edition” of Mattermost, not the open source version.

Typically -enterprise-edition denotes a commercial license. But to confirm you can check the “About Mattermost” option and if it says “Mattermost Enterprise Edition” it’s the commercial version, not the open source.

Most of the advanced automation and virtualization we do is with the commercial version, since our enterprise customers are funding that work.

That said, we’ve been thinking of changing the license for our commercial version (which offers capabilities like SSO with Gmail accounts, etc. in our “Professional” license subscription) and making some parts of our subscription free for small businesses with fewer than 100 staff and less than $10M in annual revenues.

This would create a “win-win” for small businesses using Mattermost, so that one day when they reach 100 staff or $10M in annual revenue, and can easily afford Mattermost licenses, everybody wins.

28

This would not address our issue with the user limit on our public instance. We do not need any of the advanced features in the subscription, but we do have over 13,000 users (almost all of whom are not employees), not 100. Unless you’re suggesting that we’d be able to have unlimited Mattermost users as long as our company has fewer than 100 employees, which we’ve come close to breaking in the past but are currently below.

We are using an Enterprise installation. Are you saying there is no “User limits exceeded.” warning in the Team Edition docker image? The Mattermost documentation suggests the Enterprise Edition should work the same as Team Edition if it’s not activated with a license, and user limit mechanism is contained in the open-source codebase, so I don’t see how which Docker image we’re using is relevant to this discussion.

29

I’d also like to point out, again, the issue with this statement:

Our instance is public. If and when we go over 100 employees, paying for 13,000+ licenses and an additional one for each user who signs up on our public server is not reasonable. This will essentially let anyone cost us extra money by signing up more accounts on the server. The license would need to be a single price, not per-user, for us to even be able to consider it for this application. But the only prices currently listed on the pricing page are per-user.

30

@jacobgkau - you would not be forced to add seats for every user who signed up. Take a look at Self-hosted subscriptions - Mattermost documentation We give you a lot of flexibility in dealing with growth in your user population, and you can choose to deal with that by deactivating older or less important accounts to remain within your license limit.

31

From that documentation:

When you buy an annual Mattermost subscription, you agree to provide Mattermost with quarterly reports of the actual number of activated users within your system… If you have more total activated users than you purchased in your annual subscription, your Customer Success Manager will provide you with a true-up quote for the new users added.

So yes, we would be forced to pay an additional licensing fee for each additional user using the chat server. As for this:

you can choose to deal with that by deactivating older or less important accounts to remain within your license limit.

That is not an appropriate way to manage a public chat server. There are no “less important accounts,” and if we were to deactivate “older” accounts simply because of inactivity, we’d prevent longtime users from returning to chat if they were to attempt to log in again after being gone for a while. They’d have no easy way to contact us about it, because they are not part of our organization; and even if they did, we would not be able to handle the administrative overhead of having to deactivate/reactivate individual accounts regularly just to minimize licensing costs. We certainly would not pay to be obligated to do that amount of work managing the user database.

32

So, yes, if you add users and want to keep them, you need to buy additional seats. My point was that you can choose to deactivate users rather than license them.

As for your second point, if you have paid subscriptions and decide to not deactivate accounts, then yes, your seat count will increase. I would contact the sales team… there are pricing models for academic, non-profit, large numbers, etc. Get a Quote | Mattermost will actually ping a Mattermost bot and whomever is responsible for your territory will get with you and you can ask them about that.

33

i am very interested in feedback from the community on these ideas. We’d love to hear your feedback on these ideas.

Orginal URL: https://forum.mattermost.com/t/feedback-on-collaboration-for-mission-critical-work/17563/32

34

Please Listen first This will essentially let anyone cost us extra money by signing up more accounts on the server. The license would need to be a single price, not per-user, for us to even be able to consider it for this app. follow these instructions.

35

@framasky would you have a link to the Mostlymatter fork? I think there’s some folks on this thread that might be interested in the project,

37

Hey @it33_mattermost,

I recently became aware of the planned changes in future Mattermost versions and am really disappointed about the decisions you made in the recent months, as I really can’t understand your arguments for various changes.
I refer to this discussion on reddit ( Reddit - Dive into anything ), GitHub issues like this one ( Call only in DMs is a massive step backwards! · Issue #864 · mattermost/mattermost-plugin-calls · GitHub ) and so on…

So, let’s begin:

a) Hard user limit

=> There’s no simple way (e.g. config.json) to deactivate this. And yes, I know that it will be possible to create an own build with special variables set. But that isn’t an “easy” or even practicable way as you argued. Why didn’t you just add an option in the config.json, as for everything else?! That would be too easy, huh?

Regarding the user limit you argued that the “Team Edition” was meant for small teams up to 50 members at any time in the past.
But that’s not true. I cite yourself:

Mattermost is an open source platform for secure collaboration across the entire software development lifecycle
(from your Github repo)

At its core, Mattermost is an open source alternative to proprietary SaaS collaboration for teams. The software, developed in partnership with thousands of contributors from around the world, is designed to increase the agility, efficiency, and innovation in high trust organizations while keeping data and operations under IT control.

Core committers, including both community contributors and paid staff at Mattermost, Inc., determine the project roadmap. For enterprises with needs beyond the scope of the open-source project, commercial plans are available from Mattermost, Inc. Partnership with our core committer community, along with revenue from our commercial plans, which ensures the continued improvement of all editions.

see Mattermost overview — Mattermost documentation

A limit or recommendation of 50 users has never been part of your documentation, as far as I remember the past 6 years. If that where the case, we would have never chosen Mattermost in the first place. We would have looked for a better, future-proof solution.

So that’s my understanding (since 2018) of the two (main) editions:

  • Team Edition (formerly known as “Community Edition”): open source platform (as mentioned above) - all relevant features without arbitrary limits or restrictions, but without enterprise support
  • Enterprise Edition: Team Edition + a few extra/enterprise features + enterprise support

So if an IT department of a company decides for themself, that they don’t need or want enterprise support or enterprise features, that’s their decision. Not yours.
It’s fine to show warning banners to Sysadmins in the System Console that there are more users than Mattermost, Inc. recommends for unlicensed systems. BUT there’s really no need for you to “protect” sysadmins or users as you argued somewhere. That’s Paternalism and not what I expected from Mattermost, Inc. Sysadmins/IT departments who are willing to take the risks of overprovisioning should be able to do so, it’s their matter, not yours.
OT: I know at least 2 Mattermost installations that are unlicensed and have over 2000 users and partly more than 1-3 Mio. messages where everything’s just working fine

And looking at this:

Team Edition is a free-to-use, open source, self-hosted collaboration platform offering all the core productivity benefits of competing SaaS solutions. (…)

see Mattermost editions and plans — Mattermost documentation

Where will “all the core productivity benefits of competing SaaS solutions” be after all your decisions have been implemented?!

In 2018, we decided to use the nonlicensed version of Mattermost, because we didn’t/don’t need any enterprise support. Community support is just fine. I don’t get why (apart from money) you see the need to force Enterprise Edition on all installations with more than 50 users. If the IT department decides to use open source software in their environment (some even have to use OSS) and don’t want and don’t need enterprise support, why don’t just accept their decision?

Side note: in 2023/24, we tried to request the purchase of an enterprise license (for high-availability and a few other features), but we weren’t granted any fundings for this. There’s nothing I can do about this fact.

So for now I see the following options for us:

  • kick out all ~2000 users and just use the instance for our team again => we won’t do this as we need to communicate with these users and customers and because the installation is being used heavily by all of our users (whole teams and departments switched from other solutions like Rocket.Chat or Wire to our on-prem installation, partly because they were missing features that Mattermost offers); with all the planned, new restrictions they will be very disappointed and will have to migrate all their stuff again to another/better on-prem solution that has to be cared for - but with what personnel?!)
  • Search for and migrate to another solution (but what about all the message history, existing channels and teams, user accounts, and so on?!)

Both are an (avoidable) really big pain in the ass.

b) Deprecation of MySQL

Technology is constantly changing, I get that. But a few thoughts about this:

  • the time period to switch to PostgreSQL is really, really short
  • according to the feedback I read lastly, your migration path (in the docs) isn’t working very reliable. Will that get better (soon) or is every Sysadmin/department supposed to find their own way to do that?
  • MySQL is a well-known and widely used DBMS; really a lot of software supports it, for good reasons
  • Since we have been using MySQL for quite a while, we have built up know how. We have absolutely no idea about Postgres. So this will also be a more or less enormous effort that we will have to invest in this migration - but again: with what personnel? And where will the time resources come from?

c) No more group calls in Calls

Well, I can’t agree more to all the feedback given on Call only in DMs is a massive step backwards! · Issue #864 · mattermost/mattermost-plugin-calls · GitHub
One argument from you I read somewhere was that, according to your telemetry data, most users use 1:1 calls anyway. But: I bet that many installations deactivated telemetry. That’s the first thing I ever do while installing new stuff. So your data is incomplete for sure.
And even if it wasn’t: that’s not an argument at all to randomly put already existing features behind a paywall.

d) Removing Playbooks plugin for all unlicensed servers

Playbooks v2 won’t be available to unlicensed servers after v10. That’s the same thing as with restricting Calls plugin. So you take away features, that were available for all users (apart from the features that were enterprise-only from the beginning) and restrict it to Enterprise customers. I don’t get it. If from the beginning of Playbooks you would have communicated that this plugin will be enterprise-only, that would have been just fine. Now, all the hard work of creating useful templates was for absolutely nothing as I think that you won’t publish a working migration path to other solutions, will you?

Conclusion:

All your planned and partly already implemented decisions in the last months are simply self-destructive. That’s how you scare away users and even whole companies. Even those who were contributing a lot of energy and know-how to create plugins, fix bugs or even whole features for free to your product. I don’t think the open source community is really amazed by all your money-driven decisions in the last time. Just looking on different blogs/sites/…: they are disappointed and really mad or even angry.

I already know your counterarguments, I have read them repeatedly in many places, “built for mission-critical companies” and so on… That’s not what you started with back then! And even if you were… that’s no valid argument at all to paywall stuff that was usable by everyone for months or even years and to set random hard user limits.

For the last 6 years I really was a big fan of you and your product and I recommended it to others a lot. Well, that’s over now.

Obviously, you have turned your back on your open source community. It’s just a matter of time before you will introduce more and more restrictions on community edition and/or your code becomes closed source and so on… And that’s really not the spirit and self-image/self-presentation you proudly spread about yourself to the whole world.

38

Thank you for sharing your detailed feedback, @rtfm98. The team truly appreciates your long-time support of Mattermost, and are committed to providing transparency and continuing to improve the platform to fit the needs of all of our users. For more information on the decisions around licensing and limits, as well as deprecations like MySQL support, you can find our official documentation here: Mattermost Editions and offerings and Migrating to PostgreSQL.