Old, incomplete and sometimes wrong Official documents
Very limited Push notifications
Moving Fastly towards commercialization and removing features of the community version (limiting Active Directory sync, removing customized permissions, removing the possibility of scaling your rocketchat)
And so on …
Unfortunately, I have to announce that the community version of RocketChat is no longer a suitable tool for use in organizations.
I can’t say I disagree with your statement about how Rocketchat has progressively “pulled the rug” (so to speak) under the feet of the community that has supported it and has helped make it a good product. However, good, bad or indifferent, the company does have people who get paid to find ways to generate significant revenue from the product in order to continue operations.
However, in the end it will be those people making those decisions who will end up with either the fame of having Rocketchat becoming wildly commercially successful, or the shame of seeing it disappear into oblivion due to the community-affecting measures taken to try to commercialize it.
The community will always end up with another product to support, and thus, the story will repeat yet again. It is the way of things. No doubt the current open licensing models are allowing for this (in regards to 3rd party open source code Rocket.Chat and other projects use).
There are other companies offering competing products, with arguably more community-friendly featuresets, even if still primarily commercial. I am currently evaluating Zulip.
Sorry to read this kourosh,
Internal teams definitely working to bring more quality products overall, being it with features and documents. Believe that as we improve quality and quality perception, we do it for community and enterprise customers.
Some thought decisions along the way exactly to make sure Rocket.Chat can be a secure open platform for all.
What are your first impressions? I just read that zulip claims to be able to import RC workspaces. Interesting!
Rocket.Chat does not provide an official data export feature, so the Zulip import tool works by importing data from a Rocket.Chat database dump.
Sorry to take so long to reply. So far my impression is positive. All the features I need right out of the box, without limitations. Even push notifications are completely free. Zulip officially is saying that eventhough they may need to charge for push notifications in the future, it is definitely not going to be the way Rocket.Chat does, as Rocket.Chat’s current feature-limitation and long-standing feature-removing approach (and I agree) is visibly set to push community users away.
As far as importing, unfortunately I did not have good luck with the Zulip-provided import tool but that’s probably because I used the bleeding-edge dev version of Rocket.Chat (which means I lost basic functionality much earlier than other users lol).
I spent a good bit figuring out how to deploy Zulip with docker (my Rocket.Chat deployment was also docker), and I am quite pleased with how it went. I went prod today and started directing my family and friends to the new Zulip platform. I will keep Rocket.Chat for a while as a message archive, holding some hope that some day they will re-evaluate their current approach 
.
" The ultimate Free Open Source Solution for team communications." [1] The license is also MIT. I’m not a layer, but you can take the code and do what you want with it, except to sell it further. If I have understood correctly the license also stays MIT and cannot be changed, so the product and community will be there even if it will be successful.
Please correct me if I’m wrong.
[1] GitHub - RocketChat/Rocket.Chat: The communications platform that puts data protection first. README.md
Traditionally I have not seen forks of widely known open source projects do well. The only one (and that has a completely different set of circumstances) that comes to mind is OwnCloud → NextCloud (it was more a division between original contributors).
In this case, yes, a MERN wiz could fork the project, remove all the limitations Rocket.Chat has placed in their software, and then…say “here it is, fellows, all yours”. But there “is” proprietary code in use in Rocket.Chat (Marketplace is a good example), so all of that mess would have to be explored, and the code would have to be refactored. Then you get into the issue of branding, distributing, supporting, keeping up with upstream…There is also the situation of mobile apps. This is a communication platform…so mobile apps for both Android and iOS are a must. There is a whole bunch of reasons why forks usually don’t succeed. In fact, there are 8.6K forks of the project right now, but I dare say most are for tinkerers, private users, and “some” are for community contributors.
Long story short, what’s best for the community (and I daresay for Rocket.Chat, if they ever truly consider the long term) is that organizations simply regard the community as a key supporter, and stop removing features in the urge to force purchase. Even large companies understand this, making their fully-featured product free and selling the support, or hosting services, etc. Market share and platform knowledge are king.
I appreciate the excellent answer and view point. I think you are right about everything and some, sad but true.
