I have a free open-source plugin and I want to create a paid version with premium features.
I need to keep the currently existing plugin free and open source for consistency and it seems that the best way to provide paid features to users is by creating a second plugin that will contain all of the features the free one has + the paid ones on top of that.
So in this model I will have two separate plugins, two separate repositories, and one of the plugins is free the other is paid only.
To streamline the user experience I’d like to make it so that the free plugin disables/hides itself if the pro one is detected, so that users don’t have duplicate toolwindows, inspections etc.
However, I also need to persist the run configurations and plugin settings, data etc. so that users don’t have to start over.
I think that in order to achieve this I will need to create some migration component in the plugin that would automatically migrate over the user’s data to pro/free version so that the experience for users is seamless.
Is that the only way to go about this? Or would it be possible to somehow share the plugin/run conf options between the two plugins? Maybe setting the same ID for the run configurations etc. (I presume that would result in a conflict during initialization, but I’m asking in case there is some way to make this work).
Alternatively, is there a better way to ship the premium features for someone in my situation?
I would strongly recommend that paid plugin is dependent on free one and does not copy code but instead share code in the free plugin.
In other words, create a freemium plugin. A single plugin with a set of free features. If a customer wants to unlock the paid features, he can acquire a paid license. It seems to be the de-facto rule for this situation. From my point of view, this is easy to develop, and users are familiar with freemium plugins.
For sharing the source code of the free part, this is another story.
PS: you may see some plugins that have two versions (two plugins): paid and free (I mean, they don’t have the “paid“ flag, but if you read the description, they’re not free). This can be confusing. I think most of them are old plugins, published before the marketplace introduced paid licenses (per example: JFormDesigner). These plugins use an external provider for the payments. Later, these plugin owners published a version that integrates payments from the marketplace. This is why you see two distinct plugins, but this is absolutely not the rule.
Also, some plugin owners support both payment methods (external and marketplace) via two plugins because with an external solution, you don’t have to give 15% to JetBrains, but you have to handle it by yourself, you take the responsibilities, and users have to trust your payment method.
1 Like
I also like freemium plugin option, it is much simpler and drives all users to install a single plugin while not fragmenting its userbase
I have considered creating an extension plugin, that depends on the free one. However, I will need to modify some of the functionality of the free plugin in a way that is not suitable for creating extensions. This could probably be handled by simply duplicating the communication layers that need to be different, and having two versions of it, one in the add-on and one in the free one.
I have also considered making it a freemium plugin, but then comes the problem of maintaining open-sourceness.
The free part of the plugin is pretty much done and released in both the store and on GitHub. It has 63 stars, some issues, discussions - I’d prefer keeping the momentum this plugin has on GitHub.
I’m also not sure if stopping maintenance of the open source part of the plugin would be a good idea… I wouldn’t be able to stop what’s out there publicly from being out there publicly… What I’d fear is someone taking the free parts and then distributing them if I would’ve moved to a closed source and freemium model.
I’d like to go closed source and and I definitely like the idea of freemium where users have just one plugin, it’s easier to offer the features to free users as well this way… But I’m simply not sure it is the best way to go from where I am now. I’d like to avoid giving people incentives to fork and diverge instead of contribute to the plugin…
Maybe creating a Pro extension that can be fully closed source, depending on the free plugin in all that can be depended on and including the rest that needs to be custom with the add-on is the cleanest way to go from here…
What do you guys think?
Why? Your builds of plugin on the Marketplace may include proprietary modules additional to OSS, it is not mandatory to publish exactly same plugin built from OSS code
Please note that we soon enforce uniquness of modules in all plugins in the Marketplace and all attempts to copy plugin code (services, modules, extensions) will finally be ruined. And the only way to copy such would be shading / renaming FQNs
@yuriy.artamonov Can you please give more details?
I have 3 paid plugins, and a fourth paid plugin that combines the features of the 3 first plugins (it’s like a repackaging of the 3 first plugins, so it’s using the same classes, same services IDs, etc - but it’s offered at a lower price). If my understanding is correct, I will have to rework my fourth plugin?
Will this affect existing builds? Will this be a rule on the marketplace? In the IDEs?
Edit: If it’s in the IDE, it’s OK, because I marked my fourth plugin incompatible with the 3 first (there is no reason to install the same features twice).
This seems critical to me.
Thx,
Also, what will happen if two plugins share some code? I’m reusing the same code (same package and class names) for license management..
We will try to only affect new plugins and new plugin XML format with explicit module names. Old ones do not have module identity for optional XML config, so there cannot be clashed ID if there are no IDs
1 Like
I’ve done some research of the freemium model and planning in my repo. I believe that pulling in the OSS repo code and building the premium plugin in a private repository is the way I’ll go.
Thanks for discussing this with me.