The hard part is not going open-source today but remaining open-source as your product evolves. When using a split model like this, inevitably the open-source version serves SMBs and the paid version serves Enterprises. Given enough time, you end up having two different versions of the product for two different customer segments and logically axe the version that doesn't make you money anymore.
It's likely not even going to be a conscious or intentional choice. At some point your enterprise customers are going to have enough bugs and feature requests to keep you busy full time, and your open source project might languish unless you make a conscious effort to dedicate a percentage of your time on it.
Ironically as some companies have already started noticing, when you stop being able to market your product as open source the start of the funnel will start to dry up. The start of the funnel is often not monitored, and the sales might even continue going up as your successful open source users go to enterprise. By the time you realise the funnel has dried up it might already be too late to turn back as competitors have filled the void you left.
In my opinion, this just means you've done a poor job on the architecture side of things. If you need a paid version that has extra functionality then your free version needs to be extendable.
Your free version should in theory just be a freemium version of your product. And your freemium version of your product should lead to paying customers and be a major way of generating leads and customers. If it's not doing that then it should be a case of do you need to stop adding so many features to the free version or is it that a free version just isn't used by enough people to even matter?
If no one is using it, then really stop building it you're just wasting your time just so you can virtue signal that it's open-source. Really, the only people who will be mad will be the ones not helping you out.
When your enterprise product is a superset of your open source product, you need a trigger that leads to buying. If that trigger is a feature, then it is only effective as a trigger if it is broadly useful to the product. In which case, you either withhold it from open source or cripple (or rate limit it) in open source. Your sales team - told to meet quarterly revenue targets and held accountable to that - will lobby for strict limits on these features.
My first hand experience is that there are two likely outcomes: (1) You limit the utility of the open version to create a buying trigger and your open source users dwindle away as the open product doesn't meet their needs. Or, (2) your community has sufficient momentum to build the feature itself and your sales team starts losing deals to your open source offering.
This model also creates harmful intra-organization conflict between those who argue for short-term revenue (probably their continued employment depends on that) vs. those who argue for the largest open source user base. It also creates conflict with your users as you intentionally offer a worse product to your largest user group (open source users).
