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.