Hi @it33_mattermost, thanks for taking the time to answer.
(lots of edits to fix grammar and meaning; as you may have heard, French people are not good at talking english 
)
From what I’ve read, this thread won’t change anything about the current direction regarding user limits and now message limits - at least it’s nice to chat with you, but also a bit frustrating. Please be ensured that there is nothing personal with you; I really intend to make you feel our point of view, while trying my best to feel yours.
This time I am writing in my own name, but I think I am not the only one who feels that this is ultimately a commercial move. Maybe things would be simpler if presented that way.
In a 2018 thread, @jasonblais seems perfectly fine talking about teams with 10k+ users. The hardware requirements page just tells us to stress the system with a testing tool if teams reach 2k users.
I am also a bit frustrated of this narrative because, while it makes sense in hindsight, neither the documentation nor the forum made it explicit until now. We launched our instance in 2016 (at the time we were even maintainers of the Docker image - hi @pichouk), and we never thought that we would have this conversation one day.
Perhaps you have indeed seen dramatically slow Mattermost instances since then because they grew on unsuitable hardware. Right.
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 /).
Right now, this Mattermost move feels like you assume that sysadmins are unable to correctly use Mattermost, and that they need to be technically hard-limited before they start taking appropriate action. This is not a good signal from my perspective, as it sounds to me like presumption of incompetence. In my opinion, a healthier presumption is to assume sysadmins are competent, not to punish everybody because some instances are dysfunctional.
I do get that point, but please consider the following:
- We do not need Enterprise features, and in general we tend to prefer to run FLOSS code on our machines.
- We have 10k+ users, so according to the nonprofit Q&A, we have to undergo a special review, which may clash with our efforts to keep our free will.
- We are not guaranteed to be able to spend 250$ every 3 years
- We have absolutely no insurance that things will stay as they are, and this thread is a perfect example:
- What if Mattermost, Inc. refuses to renew the license after 3 years for some arbitrary reason ?
- What if the price goes up and we can’t afford it anymore ?
- If you change your mind at any point, we cannot go back as some features are like points of no return (e.g. imagine that we finally start to use LDAP integration, but that the next year our application is rejected for whatever reason; what could we do ?)
- etc.
On the other hand, the FLOSS version is guaranteed to run forever, even if we have to stick to a specific version because the license would have changed.
I said earlier that our usage of Mattermost is quite special: indeed we have hundreds of small teams, mainly non-profit organizations, public research teams with no budget, very small companies, students, and so on. We really cannot afford to enroll and then be excluded from the nonprofit program for reasons beyond our control, hurting not just us but all those organizations. So yeah, from my point of view our instance is “critical”, but not because we need high performances, complex workflow integrated with Gitlab, clusters with 99.999% availibility, etc., but because a whole heterogeneous ecosystem depends on us to communicate. Just that.
So far, my guess is that you probably want that companies which…
- Use Mattermost Team Edition for free
- Make a reasonable amount of money
- Are using Mattermost for production-ready, critical work
…simply pay for using Mattermost.
This is perfectly legitimate; I personally reject the idea of making money on the FLOSS community while barely giving anything back (hi, AWS) - for that reason I highly value AGPL. I think you see the Team Edition as a trial for, say, a small development team of a random company. As the adoption grows across multiple teams and as the instance scales, you want the company to consider Mattermost Enterprise, because it can afford it and because you, as any company, you need income. As a side effect, the company will also benefit from support, performance, easy scalability and features that are generally useful to big companies, so it is a win-win situation.
My bet (and regret) is that our particular situation (where neither the nonprofit nor the enterprise version seem to be suitable) seems to have no importance in your decision making, since we are not the actual commercial target, despite being a “champion” and despite not being the only impacted nonprofit NGO (Framateam is another very close example).
But still, I wanted to let you know that for us, a small nonprofit organization with tens of hundreds of users and only a few volunteers who already spend a lot of their spare time trying to provide an privacy-friendly, free, humane alternative to (Slack|Discord|Google Drive|Trello|whatever personal data leecher) for small organizations and privacy-seeking individuals, having to maintain a fork mainly because of commercial reasons (and because of an obscure gray area about whether changing a build-time argument triggers the AGPL) is frustrating.
As a side note : the license says that:
You are licensed to use compiled versions of the Mattermost platform produced by Mattermost, Inc. under an MIT LICENSE […]
You may be licensed to use source code to create compiled versions not produced by Mattermost, Inc. in one of two ways:
- Under the Free Software Foundation’s GNU AGPL v.3.0, subject to the exceptions outlined in this policy; or
- Under a commercial license available from Mattermost, Inc. by contacting commercial@mattermost.com
It is utterly clear that compiling ourselves Mattermost makes the license reciprocal, as the MIT license is tied to the binaries that Mattermost, Inc. produces.
Also, the AGPL makes it very clear that build-time arguments are part of the software:
The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.
Hence, it seems to me that the license argument which was used to close the discussed MR is at least very fragile.
Back to the fork hypothesis. We deeply care about the security of our users. We have a bot that warns us as soon as there is a security release (see below), so we can upgrade ASAP by changing a variable in our Docker Compose file.
While it takes time for us volunteers, it is still manageable. Maintaining a fork is a whole different ballgame, and I’m not sure we can apply critical security patches rapidly, having to go through the whole pull-patch-compile-dockerize-deploy process, making our infrastructure more vulnerable.
As a final thought, I would like to argue a last time that issuing warnings with links to various pages of the documentation is sufficient if the issue you’re trying to tackle is really security and performance. As I’ve said, no sysadmin would ever deliberately let their instance become slow and unusable - unless they do a bad job, which is clearly out of your responsibility and power. If a sysadmin does a bad job for whatever reason, I bet that its instance will go through a whole bunch of other problems that you can’t solve with limits. Undergoing hard limits makes me feel a bit paternalized, but more importantly it hurts organizations like ours, that use our spare time to advocate for privacy and FLOSS.
However, please be ensured that I really do value and appreciate that, as a CEO with tons of stuff to do, you take time and care to interact with the community. While expressing frustration and difficulties is important to me, I really have no animosity towards you. Besides, I regret as much as you the lack of participation to this thread. Unfortunately, most of organizations like ours usually don’t even know that such discussion/feedback request happen there - I really stumbled on this thread by chance.
Thanks in advance for reading and, I hope, answering with frankness.