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.
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".
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?
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.
It's not bullshit. It conflicts with the architecture because they already have the feature implemented, presumably in a different way. And they plainly state that it's present in their paid version; they're not trying to hide that fact. Leaving the PR open and essentially helping the author morph the code into the exact same implementation the paid version has seems like a pointless exercise. If they wanted it in the community edition, they'd simply copy the implementation from the paid version.
Not sure why you're so up in arms about this. They built the project themselves; they get to decide what goes into it. People who don't like that are free to fork, and compete on their own merits.
> If they wanted it in the community edition, they'd simply copy the implementation from the paid version. […] Not sure why you're so up in arms about this.
Because they don’t want the feature in the free version even if someone gave it to them.
So when you invest in open-core, you don’t get incremental improvements as people collectively make an effort, like open-source. You get incremental improvements by eventually switching to the paid version.
> Because they don’t want the feature in the free version even if someone gave it to them
Gave it to them? They already have an implementation of this.
How is it a "gift" to spend unpaid time reviewing and merging a duplicate implementation, and then maintaining it forever, even though it likely has different dependencies and configuration option names than their existing implementation? And then after all that effort, all the maintainers get in return is a pay cut, if some paid users downgrade back to the free edition because they were only paying in order to use that feature?
As stated clearly in their CONTRIBUTING.md, this project follows the very common practice of requiring prior discussion on an issue, before submitting a pull request.
In this case, the pull request author completely ignored that process and submitted a 400+ line unsolicited pull request with no prior discussion. All of the wasted effort would have been completely avoided if the PR author bothered to post a single-sentence issue asking if the maintainers actually want this.
As for a chilling effect, the worse one I see is maintainer burnout from having to deal with PRs like this.
What I'm saying is that there are probably many, many authors who realise that and wouldn't risk contributing (therefore having a chilling effect). Kinda makes the project "open source-ish". All the legal infrastructure, none of the community norms.
Someone is out to paint open-core in a bad light. But what's the solution, when you've been told "won't happen, because it's how we make money?" Unless you give them money, no amount of HN venting will change that.
Perhaps contributing extension points and a plugin system? Would tooljet et al. say no to that? Modularity is generally considered a good thing.
So what? That's the business model they've chosen; it's their repository, and no one is entitled to merge things in.
If people care that much, they can maintain a fork, and add the features they want. If the fork ends up becoming more popular, it will end up with more contributors and become the de-facto main repo.
Yes, this potential contributor ended up having their time wasted, but they clearly didn't read the instructions for contributors, which asks contributors to open an issue first to discuss the planned feature. If they'd done that, then they wouldn't've wasted time.
>there will be a conflict in the architecture
Title makes it sound like they reject paid features out of hand.