Copying @ElisabettaCarrara’s questions from another thread…
A Freemium or Premium plugin wouldn’t be GPL would it? In that case they would not be able to change a Free one to either of those models as GPL code needs to remain so.
The conversation has been about the developer using their own GitHub repositories; I’d think limiting to GitHub for consistency is probably a good idea, but that is a question more for the developers who will write the CP plugin directory.
A plugin is essentially GPL whether it’s free, freemium, premium, paid, pro, commercial, or whatever…this is required in order to comply with the GPL license of the overall system. That doesn’t mean you have to release the code, or release it in a non-encrypted format, but it’s still technically GPL.
The GPL doesn’t prevent you from changing a plugin’s business model and making it freemium or otherwise paid. You’re not changing the GPL license by selling it, you’re just changing the business model under which it’s being offered.
I did some reading earlier and it seems you can change free to paid, GPL code must be available to buyers.
Yes, for the GPL, if the product that uses the code is distributed, then the code has to be made available in a usable (i.e. non-obfuscated) format to those to whom it is distributed. If the product is used only as part of a SaaS model, then the code does not have to be distributed because the product isn’t.
Whether the product is free or paid (both of which are permitted under the GPL) doesn’t make any difference to this.
From a user standpoint, a plugin switching from free to paid is annoying. There’s a new version, but you can’t upgrade to it unless you pay.
Switching from free to freemium can be annoying as well. If the availability of previously free features actually decreases when you upgrade, then that’s not great. If it’s purely adding new features, and the separation between the free & paid features is clear, then it usually works out fine.
I like the suggested categories “Free”, “Paid Features” and “Fully Paid” from @klein. I don’t think this is a good place to spend a huge amount of time and effort though, simpler is always better and we’re talking about the first steps here.
Once we get the initial version of the directory launched, we would be better served by providing a standard way to accept payments, and allowing plugin authors to sell (for example) paid support subscriptions.
I think you are wrong - having a freemium version doesn’t allow you to try out the premium features without paying. It only allows to to try the free features.
What allows you to try out premium features without paying, is a free trail, which may be available ( or not ) on freemium products or products with no totally free features. Most premium / freemium product have a free trial.
There is no difference between freemium and premium.
Where WordPress org have ‘gone wrong’ is that they don’t allow totally paid with ‘free trial’, hence creating an ecostructure of ‘freemium’ as plugin developers have to have a notional free version so they can upsell, rather than just a premium version with a free trial ( which is overall better for the users and developers )
Continuing to ‘force’ a freemium model - just because wp.org rules created it is a missed opportunity for classicpress.
It should be
And is developers want to have something in free that upgrades to premium that is fine. And if premium has or has not a free trial period that is fine.
At the moment, developers have to go through crazy hoops having two versions of code, one that is WP.org ‘legal’, and one that contains the ‘premium code’ which wp org refuse to host.
It does open the question of charging a service fee for hosting premium code, though.
My feeling as well.
There is no difference between freemium and premium.
Asserting this doesn’t make it true. It’s clear that many of us here (including me) can see a difference. Indeed, as has already been pointed out here several times, it’s a very common and well-understood distinction. Why does it matter to you if those of us who do see that as a meaningful distinction get to make use of it just because you don’t see it?
I think you are wrong - having a freemium version doesn’t allow you to try out the premium features without paying.
If you look back at what @ozfiddler actually said, you’ll see that he said nothing about trying out premium features. He said: “Freemium versions give me a chance to check out the developer - is it buggy? are there spelling mistakes?”
That’s exactly my position too. I use the freemium model to check out the developer. In other words, the free version of a freemium model is the developer’s opportunity to earn my trust.
What allows you to try out premium features without paying, is a free trial
Despite its “free” label, that comes at a cost that I’m not prepared to pay. One typical ploy is to require that the user provides payment details up front – it’s just that the charge is deferred. There is no way that I am going to do that, because the developer hasn’t gained my trust yet. As I said, that’s the beauty of the freemium model.
Alternatively, the free trial code will come with some artefact that looks terrible (and often confusing) to my users. It’s often an ad for the software. Ugh!
And, of course, the code will just stop working when the period is over. But it might be the sort of code which does something only when users do something, and when they do that might be unpredictable. So I have to remember when that is and plan accordingly, even though I don’t know whether the trial has been proven worthwhile or not, and then take steps to deal with it. So that adds more work. No thanks!
Some fair points well made.
I would reiterate in the current wp org world there is only 2 types of code
- free, and allowed on wp org
- the rest, which includes trials that expire and code that is extended to free plugins ( freemium ), or 100% paid for plugins, or other code that breaks wp org rules ( such as downloading data elsewhere )
The main point - that needs thinking about is will the repository mirror wp org and ban every line of premium code in a free plugin ( freemium ) forcing developers to go through hoops to manage the free & upgraded version, or will a more ‘commercial developer’ friendly approach be taken.
Check out rule 5 in the third post which suggests rules for the directory.
We’re building a directory, not a repository; we may choose to extend to a repository in future, but for now we’ll stick to a directory - it’s quite enough to be starting with.
Once you step back and see that we’re just listing plugins the whole free/freemium/premium distinction vanishes - as long as they’re accurately described it really doesn’t matter what model they follow.
I think what matters is a decent search function, with results that clearly show whether a plugin is in free, freemium, or premium category; because that’s info that matters.
Plugins switching status from free to premium, or freemium to premium, between versions is something I personally believe should not be permitted. I’d go so far as to include that as part of the “rules” for plugin submission. Once a plugin is released as free [or fremium] it stays that way. If a developer wishes to release a fremium/premium version it should count as a distinct new plugin.
However I recognise that this also begs a large number of issues and questions: not least are silly things like users not seeing nags to upgrade if the old plugin can still function with CP, and also a commitment by developers to maintain free versions or else declare them abandoned; and of course installation of new fremium/premium versions needs to migrate settings from a free version and remove that free version.
Quite happy to be ‘schooled’ by the community on this topic though
The individual words can have a description from an info icon (i) or some description in brackets for common language