By Mattermost Entry Edition now enforces a 10,000-message limit on self-hosted instances, hiding older messages even though they sit in users’ own databases on their own servers. A school with 2,000+ users and 470,000 messages suddenly lost access to years of institutional knowledge. “Our server, our database, but it’s limited to 10K. It seems a joke,” wrote one frustrated admin on GitHub. However, this isn’t a license change like HashiCorp or Elastic. This is worse.
The Self-Hosted Paradox
Mattermost crossed a line that even aggressive license changers didn’t cross. When HashiCorp switched Terraform to the Business Source License, they targeted cloud vendors reselling their code. When Elastic moved to SSPL, they prevented AWS from offering managed Elasticsearch. Both moves sparked controversy, but both shared a logic: protect the creator from competitors profiting without contributing.
Mattermost’s 10,000-message limit has no such justification. Users run Mattermost on their own hardware, store messages in their own PostgreSQL databases, and already pay for servers, storage, and maintenance. The limit is purely artificial. Moreover, messages remain in the database but become inaccessible through the UI. It’s digital hostage-taking.
The distinction matters. License changes affect distribution rights and competitive uses. In contrast, Mattermost limits data access on infrastructure users control. That’s a fundamentally different category of restriction, and it sets a dangerous precedent for self-hosted software.
Retroactive Enforcement Breaks Trust
Mattermost didn’t just change future terms. They broke existing deployments. The Mattermost message limit arrived with version 11 in December 2025 and applied immediately to all instances. No grandfather clause. No migration grace period. Users who had run Mattermost for years lost access to messages sent before a calculated cutoff date.
The school admin’s complaint captures the trust breakdown: “How can we trust Mattermost from now on?” If the company can retroactively limit message access, what stops them from restricting file attachments next? Search functionality? Admin features? Once you accept that a vendor can artificially limit features in software you host, you’ve accepted a relationship based on leverage, not value.
Furthermore, the retroactive nature is what makes this uniquely problematic. Companies change pricing and features constantly. But those changes typically apply to new users or renewals, not existing deployments that operated under different terms. Mattermost chose the nuclear option.
The Edition Shuffle
To understand why Mattermost made this move, you need to understand their edition structure. Entry Edition offers advanced enterprise features—AI capabilities, Boards, audit logs—for free, but with the 10,000-message limit. Team Edition remains fully open source under MIT license with no message limits, but lacks SSO and advanced security features.
The trap is obvious. Users adopt Entry Edition for the attractive features, hit the 10,000-message limit months later, and face a choice: pay $10 per user per month for Professional, or downgrade to Team Edition and lose the features they now depend on. It’s classic bait-and-switch.
Mattermost’s justification? Team Edition “often resulted in oversized and unsupported deployments, with limited exposure to our most advanced features.” Translation: users weren’t upgrading, so we created a conversion path that forces the decision.
The Sustainability Counter-Argument
To be fair: open source companies need sustainable revenue. Development costs money. Engineers need salaries. Security updates and infrastructure aren’t free. The cloud vendor problem is real—AWS, Azure, and GCP profit enormously from open source software while contributing relatively little back.
MongoDB, Elastic, and HashiCorp all faced this calculus and made similar moves. A $10 per user per month price tag is reasonable compared to Slack or Microsoft Teams. And Mattermost does still offer Team Edition under MIT license. Users have a free option.
Nevertheless, sustainability doesn’t require retroactive enforcement. Mattermost could have grandfathered existing Entry Edition deployments. They could have applied limits only to new installations. They could have offered a migration grace period. Instead, they chose immediate, retroactive, artificial restriction of data users already stored on their own servers.
That’s not a sustainable business model. That’s vendor lock-in disguised as sustainability.
What Developers Should Do
If you’re affected, you have options. Matrix offers fully open source, federated architecture with end-to-end encryption—the French government uses it. Rocket.Chat provides a feature-rich, Slack-like experience with strong customization. Zulip’s thread-based organization model is particularly strong for developer teams.
You could also downgrade to Mattermost Team Edition, which still has no message limits. But that requires answering a hard question: after this move, can you trust that Team Edition won’t face similar restrictions later? Open core models create perverse incentives. The community edition exists to drive paid conversions. When conversions slow, the temptation to limit the free tier intensifies.
The broader developer community’s response matters here. If Mattermost faces minimal backlash and user churn, expect other self-hosted tools to follow. If migrations accelerate and the company reverses course, it sends a different signal. Open source sustainability depends on finding business models that don’t punish the communities that built the software’s reputation.
A Line Too Far
Open source business models are evolving. That’s inevitable and necessary. But there are lines. Retroactive artificial limits on self-hosted instances cross one. When users control the infrastructure, pay for the storage, and the data sits in their databases, access restrictions become something other than business strategy. They become digital hostage-taking.
Mattermost can still fix this. Grandfather existing Entry Edition deployments. Apply limits only to new installs. Offer reasonable migration paths. Engage with the community that built your reputation instead of unilaterally changing the terms.
Until that happens, the message is clear: in the world of open core software, you’re not a user. You’re a conversion target. Plan accordingly.
