Yeah, I just don’t see authors wanting to sell their plugin putting it on GitHub.
That’s a good point for fully-premium plugins (or whatever they’re called). I plan to offer quite a few free plugins, a handful of freemium plugins, and a premium-only title or two. Free and freemium are easy enough to deal with via the directory, but, I agree that a fully-premium plugin wouldn’t perfectly fit in with this model.
2 Likes
Question…
What is everyone’s feeling on Code Canyon?
I like Code Canion (and Envato in general).
Positive elements:
- great choice
- usually good demo sites (you can run lightouse to have a first impression)
- support is usually good and you can see if it really is
- many statistics about elements
- they invest on marketing a lot
Con’s
- You have 3 invoices for an item
- Fees are high
2 Likes
Are there other premium plugin market places that may be better options, Simone (and anyone else)?
(Specifically asking as possible alternatives to hosting premium plugins on GitHub, in consideration of @joyously 's question and @james ’ response.)
1 Like
There are also different models, like subscriptions in https://yootheme.com.
But this model is one-firm only. (hope one-firm only is correct in english 
)
Thanks, Simone.
Going to have a look.
@ everyone: What are the submission criteria like for these premium market place platforms?
How do they deal with bad code, for example?
Yes, they (try) to deal with bad code.
Of course they want to sell… they are not so aggressive in rejecting themes.
You can find their rules here. Quite interesting!
1 Like
Those actually seem like very sensible general guidelines for general-audience items.
It is also quite short, which helps.
Personally, I don’t think custom post types / taxonomies are ideal for every use case, but I agree that they may be preferable to new tables for a lot of use cases. (Just me venting 
)
The trick is: what is the goal? Those other market places are self-sustaining. Devs use them or not. Trying to put CP into that mix seems like it’s asking for trouble.
If you just want CP to have a way to show its users extensions, that’s one thing. If you want CP to notify of updates, that’s another. If you want CP to auto-update patch versions, that’s another. And searching and classifying them is another. I think getting involved with payment transactions is too much, and verifying that code for sale meets the CP standard is tricky because of the author wanting to hide the code before sale (because GPL).
It’s easy for me to see why the WP repo is “free only”.
1 Like
That. I think.
Agreed. Generally these platforms have existing affiliate programs though.
Discussion for another day.
For me too.
The question is whether devs will value the process enough to make it worth it.
There appears to be a lot of support for listing premium plugins in the CP directory.
Note, I’ve moved the discussion about hosting premium plugins to a new thread.
GitHub supports private repositories for free now, this would still be a workable option.
In any case this is for ClassicPress v3 and beyond, we need to build out our plugin directory for free plugins first.
6 Likes
Couldn’t an option be for an official directory, but the option to add other directories, so that it gives options for premium plugins to offertheir own directory and repos/infrastructure.
Users could have a menu system to choose the official directory, with the official plugins hosted on Github (or whatever is chosen), or they can choose to add other directories with the free/paid plugins from that developer or group of developers with its content hosted on github or their own servers.
Then you wouldn’t have to worry about the premium plugins/themes, and just concentrate on building the free version.
1 Like
You know, this exists in the theme selection through the Customizer. It has a list which has Installed themes and .org themes. You can add other lists there, I think. I don’t think there’s an equivalent for plugins.
1 Like
I had access to user research in the past that suggested to me having paid and free items listed side-by-side was more frustrating for them than it was helpful (even when clearly labeled as paid or free at the top level).
If we include both in the directory we should provide filters that default to one or the other but not both.
Also when it comes to premium plugins and themes more often than not what is being sold is not actually the plugin/theme but instead the service which supports it (IE it is GPL code so that can’t restrict your usage of it but they can offer only support for the service to a limited amount of sites it users or whatever they choose). Do we plan to offer other services as well?
At what point does a premium plugin instead become a premium service (and this no longer being eligible to listing as a plugin)?
3 Likes
But why? My guess is that most of those involved wanted free plugins only. So of course including other plugins would be annoying for them.
I’m not sure that’s a useful metric. What’s the incentive for developers to create plugins for CP otherwise? They do have to put food on their plates.
2 Likes
I have no idea about the why - I only had access to the research that the client conducted which did not include detailed answers to the questions, just yes/no answers. The users were actually overwhelmingly paying customers which found it confusing that both types of products were listed in their results. I personally expect that the same would still be true it they were people looking for only free items but I don’t have any data that supports that line of thinking.
I feel like people are either looking for free or they are looking to pay - let’s allow them to see the results in a format that separates them completely as one of the display filtering options available to select.
2 Likes
Also about the metric not being useful - that could well be but it is a metric I knew of and I still thought it was worthwhile sharing even though I agree that on it’s own it’s not very useful. No one needs to pay any attention to it if they feel it has no value. I think it’s value is as a way to give us a starting point for collection our own data about it.
The market here will likely be different so no one study would be able to make statistically significant predictions - but collectively lots of studies can make pretty good guesses 
My point is that ClassicPress really needs to serve two different groups: both users and developers. I think we need to be careful not to put one above the other. We could make the plugin directory super-user-friendly. And if we can do so without causing problems for developers, then that’s absolutely what we should do.
But if making the directory a little better for users in one particular aspect would be a deterrent to developers wanting to list their plugins in the directory, then that requires some consideration of whose interests matter more.
Yeah I understand, it’s good to put both sides across but at a certain point a decision one way or the other needs made. Let’s pose all the tough questions and extremes now, well in advance, so we can avoid the delays they may cause us to run into during the actual development phase of the directory
3 Likes