Update 6.0.0 Read Receipts Complaint

Community Support
1

Dear Rocket.Chat, I do not appreciate features we’ve grown fond of using, such as Read Receipts, being seized from us and made a paid feature abruptly and without warning.

This completely inappropriate and immorally manipulative sales strategy has ruled out the chance of my team ever purchasing a subscription from your company. We will be moving from the product as soon as possible.

This is not how any respectable company treats administrators in charge of crucial communication software relied on by many users. It is truly despicable to take advantage of us administrators and our numerous users and use them as leverage against us to pay for a feature we used minutes ago.

I’ve put up with countless bugs, inconsistencies, and complaints to give Rocket.Chat a chance, but it ends here with this backstabbing in version 6.0.0.

4 Likes
2

I had not noticed that major change and that’s not going to be well received by users. Unfortunately we just upgraded to 6.0.0, so it’s too late now :frowning:

2 Likes
3

Hi!

I am really sorry you feel this way.

This change is stated in 6.0.0 release notes as well as some other restrictions and improvements. We have been carefully listening to our community, and bringing awaited and desired improvements and fixes, as you can also read at that release note.

Here we have a special page with those changes: Rocket.Chat SIX - Our most secure and scalable version yet

We are not taking advantage of sys admins or users. We are committed, and always working to deliver the best open source communication platform, with a well balanced set of features for Community Edition and for our Enterprise Edition offering.

4

It was a feature I used with all of my team members more than 20 times every day now being held for ransom. My comment is exactly right.

8 Likes
5

i agree with @steve5050 … moving a existing function to EE ist not cool. so we need to leave RC also, because Enterprise is to expencive for our team (many users, but we only need to chat).

11 Likes
6

All we use is basic Chat features with self-hosted RC. And read-receipt are basics for it.

EE is pretty expensive for us.

8 Likes
7

You’re right, and as my needs and budget grow, Rocket.Chat won’t be considered after this horrible situation they’ve created for me and my team.

3 Likes
8

Sorry Duda, I can’t let this pass without comment.

This is of course total and utter nonsense.

Rocket are taking advantage by removing what were previously free community features in to Enterprise only, and forcing them to be paid for.

Rocket don’t even have the courage to post on their website the current Rocket pricing (note if you really do have to talk to sales then argue like mad and try and drive a bargain - they need the sales more than you need Rocket…)

This has been an ongoing process which I fought for a long time until I realised it was pointless and it was better to leave Rocket and move elsewhere. Closed source mentality stomping on open source. A great product let down my awful policy decisions in a desperate grab for more revenue.

As I said at the time when LDAP was being stripped - “what next?” and it was “oh no, that’s it, no more” And I knew that this was not true.

There will be almost nothing left in CE bar the absolute bare minimum by the time they have finished.

OSINO - Open Source In Name Only.

Base your decisions on your future chat system on that basis.

9 Likes
9

Thanks for your feedback on this item. Read Receipts have been an EE feature from since before I joined the Core team but, as noted, that restriction has not been previously enforced. Recently the team has invested time in improving the read receipts handling for threads which was not working correctly. As part of the change we have also begun enforcing the EE restriction.

6.0 introduces to the Community Edition several other improvements, such as 10 security patches, a MS Teams Bridge app for easier cross-platform messaging, GitHub app, a brand new message composer, improved invitations, extended marketplace inventory and the much requested dark mode. We remain committed to continuing to add capabilities to the Community Edition and having a viable commercial offering is key to our ability to continue and expand our current level of investment in our Community Edition.

10

Implementing these advanced/enterprise features in CE barely anyone will use does not justify removing Read Receipts, a straightforward but necessary component of any real-time communication system. Even the most basic, small-scale use cases require this feature. If you hadn’t caused this great inconvenience to my team and stressed me with the task of finding a suitable replacement, I would have arranged an EE subscription plan when one became worthwhile to my team as my needs grew.

6 Likes
11

I understand that it is important for the company behind Rocket.Chat to make money. When the push notifications were limited, I understood the move behind it. I even asked for a offer for the EE. Unfortunately, the prices for an enterprise edition are far from our budget.
Then the extended LDAP functionalities were taken out of the CE. And now the read receipts.
I’m a little concerned about how the features are being categorized in the different versions. Why is a MS Teams bridge, a better Marketplace, a Github connection packed into the CE while read receipts are an Enterprise only feature? It makes me wonder about the future, which core features may also become Enterprise only.

6 Likes
12

Thanks for your question. Please consider joining our Community Open Call on March 29th at 12:00 ET. We generally cover items relating to the direction of the platform, decision process, priorities for CE and process for contributions. I’ll be on the call and I look forward to the discussion.

1 Like
13

I find this also a very weird strategy, to say the least. It is obvious, that by removing simple, important, basic features and on the other side adding some rather niche features is greatly reducing the value of the community edition. And even from Rocket Chat sales perspective I really don’t understand it. I worked at Red Hat for 7 years, so I certainly know, how you can make lots of profit from Open Source Software. But this is certainly not the way to do it. As Rocket Chat you should have the clear interest, that the community edition is highly valuable and covers like 95% of all the needs of small communities and businesses, so that you maximize the number of deployments and make your software a very widely used solution. That’s the best marketing you can have. Based on that trust, bigger enterprises will be happy to give you lot’s their bucks to also fulfill the last 5% of their requirements. But now this really feels like you prematurely try to squeeze some money out of the still moderate number of community deployments, where there simply is no money in most cases. Like in my case: we are a hobbyist samba bateria, and we thought it would be cool to use a Brazilian product. But of course we have zero budget for a chat solution. So you can squeeze as much as you want, there will be no money, never. So, our only option is to move to another free solution. You might think, “so what?”, because you will not lose any money then anyway, but then you don’t understand, that a strong and widely used community edition is essential for commercial FOSS, it’s the soil you can grow profits on. Because, you know, we all also have a day job. And if you have a lot of happy users of the free community edition, then they will bring that also into their businesses, where there actually is money. And, I mean, you are not slack. Within the first week I filed already something like 10 bugs, and stopped because it cost me too much time. There are lot’s of glitches compared to other software, typical symptom of “feature creep” with a lack of QA. You are simply not there yet.

I’m sure people are already on the verge to create a fork. And if not, then only, because Rocket Chat doesn’t have enough quality and relevance yet.

7 Likes
14

I feel like this is such a basic feature for any chat app there is no need for it to be behind a paywall.

5 Likes
15

Even if you ultimately don’t reverse or change things, there’s a better way to respond than this.

  • No one wants to be told that someone is sorry that they “feel this way”. The sentiment expressed in the OP is legitimate. Addressing it in this way (as well as the rest of the note) has the effect of summarily dismissing the user’s concern.
  • Similarly, pointing out that the change was “stated” in the release notes doesn’t change the fact that you’re taking a previously available feature and locking it behind the paywall. Listing it in release notes or putting it on a “special page” doesn’t make it better for your users who are losing this feature.

The primary thing that’s missing from this response is any kind of direct response to the raised concern. You don’t have to agree with your free users’ desire to keep free-features free. You don’t have to reverse your licensing decisions. All you had to do was to:

  • Acknowledge the legitimacy of the concern
  • Put a tiny bit of effort into explaining the rationale and position of the company around the decision.

For extra credit, you could also have articulated Rocket.Chat’s future plans and/or policies with regard to hijacking Free features under the paid umbrella.

But, you didn’t. :disappointed:

7 Likes
16

hi @warpraptor !

Thanks for those inputs. You are right. My first message certainly did not cover all the legit concerns. Sorry for that.

Let me know if, with the other messages, it’s clearer for you.

Also, I would like to invite you to join us in our upcoming Community Open Call, March 29th at 12:00 ET, where we can discuss it better.

Here is the Channel where we can discuss and align about this and other subjects:

Thanks!

17

Yesterday I wrote a (critical but polite) post to this topic, and then it got blocked with “Our automated spam filter, Akismet, has temporarily hidden your post”. It’s a bit suspicious, not sure why it would think it is spam. I don’t want to repost everything, if I’m not sure what’s going on.

2 Likes
18

Please, go ahead @ansiwen.

19

@ansiwen Sorry for that.

it was indeed flagged by akismet as spam :grimacing:

it’s posted now.

1 Like
20

Here’s something: Apparently, my RC Snap was stuck on 3.x track and I thought it was some big problem that I had to solve in order to bring things up to speed and get the “latest features and updates” from Rocket.Chat…now I realize I’ve been had!

I don’t see how RocketChat, with its roots so firmly planted in the community…you know, the one which helped build it, test it, advertise it, give it LIFE…is being effectively stolen from in progressive updates. In my out-of-date snap, I had read receipts, and they functioned well. Immediately after updating, not only was the function to get new ones missing…no, all of my already-generated Read Receipts were also removed.

Oh, but in return, RocketChat definitely felt obligated to throw a “Free Version” tattoo on the bottom of the chat window…at best looking to sell me, the server admin, on upgrading; at worst clandestinely seeking to nudge my users to pester me about making the purchase.

You want to make an improvement? How about writing the docs so they don’t contradict each other when they reference supporting documentation stubs? Here’s an example: Just take a look at the state of the Docker deployment docs compared to its referenced article here and read them as if you’re someone with a basic understanding of how Docker works, but being sold by RC on how easy the implementation is. Tell me you’re not going to struggle when one stub tells you to do one thing, and the other doc it references directly contradicts it or features information that is entirely outdated and/or irrelevant.

Of course, I’m not saying RC is responsible for the level of one’s technological understanding and capacity, but this criticism was largely meant to illustrate the sheer distance between the current state of Rocket.Chat and other SaaS chat apps that feature things like Read Receipts, standard. My RC x. Docker reference above is not the exception…it is in fact the norm with RC, and I can tell you for sure that these other chat SaaS companies do not suffer from this glaring problem.

I am shocked by this behavior, but in RC’s defense, it does have the opportunity and capability to be a great messaging platform. Unfortunately, its astronomical pricing model and apparent disregard/disdain for the user experience of its legacy community edition users does not bode well for its future, especially in a market so saturated with SaaS chats.

Hopefully it sees the light following this community call or whatever. Return the Read Receipts.

6 Likes