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.