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.
Yes, I agree…
Particularly when they want to bill like Microsoft…
They cannot understand that small businesses can have rocketchat with a lot of users without making money from it.
And standard plan at 50€ per month would be acceptable. Not something starting at 250€.
I know a guy, self employed with 200 contact in his rocketchat. Do you think he can pay 2500€ per month?
There is a problem in open source community between the no income and the too much income. You have to find a middle value.
I personally finance guys who do big software (ispconfig). I pay 5€ per month, and I get support. And for big businesses, they do big prices…
Maybe rocketchat team should quickly think about it…
We are starting a small company. To use rocketchat would mean to have 20 users or more for the first customer.
I don’t want ‘not pay’, but if it is to pay Microsoft’s price, why to use rocketchat? I will use teams, that the customers know…
Or try zulip… Anyway, we are beginning. Nothing to lose…
I think there is a bigger issue here. Many newcomers to a solution, like ourselves, will use the open-source offering to ease into it. We’re current trialing two rocket instances with a couple of teams to see how it fits with their needs, and how the API’s allow integration with our systems. The documentation is poor and out of date, the developer forum is devoid of help and we’ve already been forced into an ‘enterprise trial’ that we didn’t want or ask for during an update and that broke a bunch of things (cancelled that). Now we’re getting spam from the company trying to see how the ‘trial’ is going, and now I’m reading that they are crippling the open-source solution.
This all leads me to distrust the product, and the people behind it, and ultimately that’s pushing us out of the door, when otherwise we would have gone enterprise after testing and before we roll it out company-wide.
Zulip awaits then (Thanks for the intro).
Your business may not make money DIRECTLY from Rocket.Chat, but it IS making money (or should be, especially if you have a lot of users) and Rocket.Chat is therefore part of your success. Why would you use it if it wasn’t helping your business?
Just the same as any other tool you use in your business. How about say telephones? Did you get those for free and do you get all the calls for free? Chairs and desks? Office space?
Do you mean Users, or Omnichannel Contacts?
Either way, if he has 200 contacts does he have no work?
The starter/CE version is free with up to 25 users and 100 contacts. (If you have 200 contacts/clients then you aren’t probably aren’t working for nothing). That is orientated to small startups.
Regardless, talk to sales and see what you can negotiate. I think it may be a bit cheaper than you imagine as pricing has changed again.
Rocket.Chat is not a charity and has to make some money somewhere, just as you do with your business. Remember. Open Source does not mean ‘Free’. They could charge for all of it.
They have always tried to cater for free use for the small user, but how small is ‘small’ ? How much do they give away for free, and what is reasonable to charge for?
There is no one simple easy solution and no matter what they do, someone will always complain. They really do try their best to strike a reasonable balance!
Care to elaborate on that?
Mostly RC is perfect for us but with the new licensing we need to be fairly up to date with the versions. They’ve currently broken uploads for non-standard mime-types so I’d ordinary go back a version to keep the user’s quiet but now I can’t. With 2500-ish open issue in gitlab, no-one is going to listen to the handfull of people who have raised the bug so I’m feeling trapped.
Not to mention severe vulnerabilities laying around Security vulnerabilities remain unaddressed · Issue #27175 · RocketChat/Rocket.Chat · GitHub
If you have paid for a subscription you will get attention by opening an issue with them directly.
If you are using it for free - it is open source. That’s a downside of it.
Yes, dealing with bugs is a never ending issue. Same thing on most big open source projects.
Rocket.Chat have an internal queuing system which obviously favours those who have paid for support.
Not much else I can say really… “You pays your money and you takes your choices”
Well, that is in the desktop app, not Rocket.Chat itself. Don’t use the app if you are concerned… (personally I never do)
I am not sure what has happened to their HackerOne account.
CVEs are here
You can try contacting them at:
security at rocket.chat
Yes of course. Fully aware of the “no money, no priority” side to open source. With paying customers comes different priorities and the need to push new features over maintenance. Just today I realised that when I click on the “jump to” button after a search it works just fine but click on a second jump button it fails because it appends to the URL rather than replacing previous result.
The upload issue I referenced might even been seen as a security feature by the engineering team (as the various posts on this forum and the issues posted to github are being passed over) but I’d say poor testing was the culprit and I guess those who pay subscriptions aren’t uploading strange file formats! Fortunately I’m in the lucky position where I can ask one of my developer to hack the offending code out.
Finally, paying a subscription might turn in to management review process and someone would decide that Teams or Google chat would be a good compromise and I’m not going there…!
Jump - Yes I noticed that myself but didn’t track why!
It’s different in open.rocket - but broken in other ways. <sigh!>
Mime types - ‘allow all’ should have worked but isn’t a great solution. I agree it is a pain with opvn files. There seems to be a couple of unlinked bugs on it.
They did auto close bugs for quite a while, and that was annoying as well. Reduced the numbers, but then people complained they were closed with no good reason!
(There are also other issues due to internal vs external systems that I can’t go in to)
There is no easy solution apart from more manpower or more community assistance. And that, as in most open source projects, is regrettably lacking. There’s a lot of taking and precious little giving.
Yes I understand about paying, but as I am boss of my IT M$ & Google don’t get a look in 
But understand your position.
(we noticed uploads with .mrt extentions were failing. It’s a reporting file type.)
Oh 
Best you can do is open a bug, document as best as possible with a patch if you can, and hope.
