Mattermost CEO here, @bbodenmiller I appreciate your feedback and thoughtful input on the safe user limits section. One of our core values at Mattermost is “self-awareness” and having dialog with our community is vital to how we work.
You’d referenced the conversation we had on GitHub and I wanted to re-share some of the ideas there to bring community members reading this thread up-to-speed:
What’s most important at Mattermost is that we’re accelerating the world’s mission critical work.
That means earning trust among the defense, government, and critical infrastructure organizations that run us for workflows vital to keeping nations safe, resilient and operational.
As a self-sovereign collaboration platform, one of the key use cases of Mattermost is out-of-band communications for security operations and incident response, and for that market it’s essential that we develop a brand of putting safety and security first.
Part of this is ensuring that any scaled Mattermost deployment–supporting hundreds, thousands or even tens of thousands of users–is running the security, reliability, compliance and automation measures necessary to defend larger deployments and earn the trust of the market.
We started with safety warning banners, and moved to implementing user limits after speaking to our largest deployments, both in nonprofits and in enterprises, we received surprisingly positive feedback.
First, deployments running open source forks of Mattermost can choose to omit the safety limits. By removing the safety limits these organizations explicitly take on security and compliance responsibility, which helps address the brand risk issue. The fundamental tenant of open source is that if you don’t agree with what the project is doing, you can modify it to fit your needs, and we’ve remain committed to that since our founding. Forking a system as complex as Mattermost is a material technical undertaking, so if we’re filtering the large free deployments to those willing to make such a large investment, and reducing the number of large free deployments choosing not to invest, it’s reduced brand risk.
Second, it reduces Mattermost brand risk from failures in free deployments. Poor user experience on large Mattermost deployments can be also be destructive to our brand. As an example, once there’s more than about 3 million posts in the system, search and user experience can become agonizingly slow, and even create work stoppage. The commercial version offers features like Elasticsearch and other capabilities, including onboarding and enterprise support, to correctly address scale milestones, to keep the user experience and workflows fast and productive, and to maintain the Mattermost brand.
I’ve personally been on calls watching an administrator show an 8 second lag from keystroke to input because the enterprise scale features weren’t used, and I sometimes feel like that experience alone enough to require commercial support beyond safe limits.
Third, it moves larger deployments to either our commercial or nonprofit offerings earlier in their lifecycle. Ideally a free Mattermost deployment grows to size where it’s value is clear, and the administrator can then purchase a commercial license at a reasonable deployment size, or apply for a nonprofit license if applicable. Without safe limits, some deployments grow to a size where the initial purchase with a very high user count gets far beyond what they’re able to get through procurement. Then the administrator can become stuck without the enterprise, support and escalation capabilities they need to manage operational risk, and Mattermost doesn’t have the commercial relationship needed to ensure the deployment’s success.
Fourth, this change increases investment in Mattermost for mission critical work. When Mattermost champions in critical infrastructure enterprises are enabled to make the business case for the commercial version at the right time, at a reasonable deployment size, the revenues from those purchases accelerate our ability to invest in building great software and accelerating the success of our champions and end users.
Most importantly, we can increase trust from critical infrastructure enterprises that we’re focused on their success. Having clarity that large deployments of Mattermost are intended for mission critical work on our commercial version at scale (whether that’s DevSecOps, security operations, Command and Control or other use cases in vital organization), protecting our brand from issues impacting free deployments that have gone far beyond safe limits, and having more revenue to invest in our platform are all additive to accelerating the success of mission critical work in the world.
The trade-offs in this direction include a) potentially losing some large deployments of our free version, b) potential brand impact from segments of open source users, customers, partners, internal staff and contributors that don’t agree with the above, c) potential trolling in different forms, rather than constructive dialog and discussion.
We’re still working on the right levels of safety warnings versus limits, and what’s important is that we also work with the largest free deployments to ensure a smooth transition.
There isn’t yet an announcement on these changes, specific limits, or release dates, and we hope to have one as the decisions and designs are finalized.
The major version change to signal a significant change impacting our community has been considered, but given safety limits don’t impact ~99% of free deployments, and that 50 users is the recommended size for free deployments, it could cause more confusion than clarity.
Based on anonymous telemetry fewer than 0.8% of unknown deployments are more than 500 users, and higher numbers, like 10,000, would be closer to 0.1%. This might be a little biased as larger deployments are often within self-sovereign private and air-gapped networks where anonymous telemetry can’t function.
To answer your questions in the context of the other thread:
@bbodenmiller: it appears they actually haven’t been implemented yet?
Correct. Since December we’ve been asking for feedback through this user forum, which gets over 300,000 page views a month, and as the user limit functionality is finalized we’ll have an announcement probably shipping warnings at the 10,000 user level in February and functional limits potentially in March, and then looking at lowering the limits in future releases. The PRs you mentioned are some of the early work in progress.
@bbodenmiller: Also regarding “moved to implementing user limits after speaking to our largest deployments … we received surprisingly positive feedback”, where was this feedback collected? There are only a few public mentions all recently that I can find of this proposal and any private interactions are likely largely with existing paying users who would be unaffected and frankly probably benefit from the change despite it going against generally agreed upon on source practices.
You’re correct. The large deployments were supportive because of the benefits from Mattermost accelerating its ability to invest in the platform and invest in their success with a larger commercial customer base.
The intention of safe limits is to have free Mattermost deployments adopt automation and scale capabilities earlier in their lifecycles, with Mattermost’s customer-facing teams helping them make the business case to stakeholders and to smoothly transition.
Until these changes are made, we’ll continue to have situations where Mattermost champions are in “dilemmas of success”–deployments that have grown the free version far past safe limits, and having higher seat counts, high adoption, and accelerated workflows paradoxically increase the complexity and time needed for procurement.
@bbodenmiller: Regarding, “It moves larger deployments to either our commercial or nonprofit offerings earlier in their lifecycle” the limits may make sense for new instances and with various warnings along the way so they are not one day caught by surprise when the instance can no longer accept new users. For existing instances such limits just appearing one day will be extremely frustrating and fall on to the shoulders of poor system admins with no purchasing influence.
100% agree.
We’ll probably start at a crazy high number like 10,000 users. There’s no admin at that scale that isn’t reading the changelog ahead of an upgrade.
As the change is finalized and rolled out, it’s imperative to Mattermost that we support larger deployments so the user limit change doesn’t disrupt operations.
For deployments that aren’t running their own forks, we want to be ready for Mattermost’s customer-facing teams to provide bridge solutions for free deployments running beyond safe limits, and help champions make the business case to stakeholders to join our commercial community, and ensure the platform performs resiliently at scale, as designed.
Our customer teams have helped Mattermost champions at the world’s most vital organizations win the support of their leadership on Mattermost for self-sovereign collaboration, DevSecOps, out-of-band communications, and Command and Control among other mission critical use cases.
No one wants large free deployments to be degraded or discontinued. At the same time, we are prioritizing our brand, our end users, and accelerating the world’s mission critical work by building a larger commercial customer base across critical infrastructure enterprises.
That said, we can only speak to the deployments who choose to engage with us, through community or commercial channels.
To broaden the feedback, we’re inviting commentary here, on our public forums, which have over 300,000 page views a month. We’re looking for input and dialog from deployments we may or may not know exist.
@bbodenmiller: It’s probably worth noting that in many cases it may drive them to competition like Slack and Microsoft Teams instead though.
Mattermost is designed to integrate with Microsoft Teams and the M365 platform: Mattermost and Microsoft Solutions
By joining Mattermost’s commercial community, deployments will have access to Mattermost integration for Microsoft Teams, along with AI acceleration from the Azure AI platform.
In October 2023, we announced our collaboration with Microsoft’s Defense solutions group to enhance Mattermost’s interoperability with the Microsoft in mission critical environments.
Moreover, when Microsoft announced their roll-out of Azure AI for classified workloads in the U.S. Department of Defense, they’ve highlighted Mattermost as a key ecosystem partner: 🤯 Microsoft 2024 roadmap is transformative for US Government. Meet Mattermost and Mobius Logic. | Ian Tien posted on the topic | LinkedIn
Here’s Microsoft’s announcement:
Microsoft: Another example is a new collaboration with Mattermost and MobiusLogic. Together, we are working to deliver improved collaboration and workflow solutions for national security customers built on Azure’s secure cloud and leveraging Azure AI capabilities. The solution stack is built on the Mattermost OpenOps AI experience platform connected across Microsoft’s core platform services including Azure AI Services, Microsoft Entra ID, and Microsoft Teams. The hub offers a highly interoperable collaboration experience with advanced levels of customization, integration, AI-acceleration and deployment across private cloud, public cloud and air-gapped networks.
Mattermost is often deployed as a supplement to Microsoft Teams.
By connecting Microsoft Teams to Mattermost, or running Mattermost along side, central IT solves a host of problems, from needing a self-sovereign platform to address regulations and data control complexity (e.g. including addressing Schrems II in Europe), to out-of-band communication for security organizations that might need to run incident response and mitigations concerning the M365 platform, to DevSecOps organizations that need to focus on technical workflows and integrating to rapidly and dynamically changing toolchains and in-house systems.
Again, @bbodenmiller, really appreciate your input and feedback. Thanks again for asking publicly so we can share answers with our whole community.
Very open to other feedback, per the title of the thread,