[duncan-donuts]

Idk if I’d take that explanation at face value.

I’m trying to recall a time in my career where I’ve heard this phrase and it was actually a technical problem. Most of the time this is a dismissive response that is more political than it is technical. And let’s be honest — we’re the ones inventing the architecture of the applications. If a feature is desired but it “conflicts with the architecture” then you figure out how to resolve the conflict.

[kelnos]

They already have the feature implemented, in their paid Enterprise Edition. Why would they accept an outside contribution for code they've already written? If they want it in the community edition, they'd just add their own implementation, and then not have two different implementations of the same feature to maintain. That sounds exactly like "not fitting into the architecture".

Regardless, they are not obligated to accept any contribution that they don't want, for whatever reason, even if that reason is "profit" and "business model".

[evanelias]

The full sentence was "However, ToolJet enterprise edition already has this feature and there will be a conflict in the architecture if we merge this PR."

That explanation seems completely reasonable to me. Why should they maintain 2 different implementations of the same feature, 1 of which they didn't write in-house? Why should they spend time reviewing and merging something contributed by a third party who couldn't be bothered to read or follow their CONTRIBUTING.md, let alone something that hurts their own bottom line?

[cmeacham98]

I agree it's reasonable, but the claim there are "technical reasons" for the rejection is bullshit. They're obviously rejecting it largely (if not entirely) because it's a feature they sell in the paid version.

If the rejection was actually because of technical merit they would have (1) explained in more detail than "conflict in the architecture" and (2) left the PR open for the submitter to fix.