Curious how you plan on managing a pro version of the product when the free version is open source. Will you just be rejecting pull requests which add features which are in the pro version? Given that the code is licensed GPL, this seems to be inviting a fork which will have additional features which would otherwise be restricted to the pro version.
People are welcome to fork and add their own features. They will need to support and maintain their features just like me. They will need to pull in upstream changes or their fork will rapidly age.
I target Inspeqtor Pro at teams and businesses with a real budget. They want a supported, pre-packaged product that solves their problem. If someone is willing to find and use some other person's fork, they were probably never going to pay for the Pro product in the first place and therefore there's little to no real competition here.
Would I reject PRs? Quite possibly; that seems super passive-aggressive to me. It would be more polite to open an issue first and discuss the situation.
I wasn't suggesting the case where someone explicitly does all the work and opens a PR which implements a feature of the pro version. I was moreso considering someone who had implemented something that was on the roadmap for the pro version. In either case, it's reasonable to say you would reject PRs.
I'm just wondering how governance of the project works. I assume you're already dealing with the same sort of thing with Sidekiq. I just find this sort of business model interesting since the more common approach seems to be providing hosting or priority support.
Yep, It's my job to communicate a vision for the product: what types of features are Pro, which are OSS. Right now my rule of thumb is "team" or collaboration features are Pro, the rest is OSS. Yes, I would close PRs if they provide more enterprise-focused features that I wanted to sell but not before chatting with the submitter and seeing if there was a common ground or some feature subset which could be open sourced.
