Discussion regarding to the development of the ClassicPress Plugin Directory.
Previous discussion and link to AppCenter for inspiration: ClassicPress Plugin Directory - #21 by wadestriebel
Github Link to Elementary AppCenter: GitHub - elementary/appcenter: Pay-what-you-can app store for elementary OS
Edit: better link to Elementary Details
@anon71687268, @anon95694377, anyone else,
Below is a list of the items (an initial list anyway) which I think need to be considered for creation of a plugin repository.
Rules needed for:
Repository view in CP sites
Also required:
As a first draft for rules, I’d suggest we look to the WordPress Plugin Repository rules (possibly ; I think in spirit they are mostly reasonable. I’m not sure what sort of licence they’re under so I don’t know if we can copy and tweak or need to write fresh along similar lines?
If someone knows the answer to the above, I’m happy to go through them to produce a draft to consider for the rules.
Does anyone know Github who can explain how it works? I assume it’ll need to like WordPress uses SVN; one repository with approved plugins being added with the developer having write permissions, but everyone else being read-only?
I think I need an understanding of Github before I’ll understand all relevance of the Elementary AppCenter.
I updated my link to the Elementary AppCenter so it is more clear, but here is how they do it (which is why I like it): https://developer.elementary.io/
I don’t think it should necessarily be “pay-what-you-want” but the foundation is what I like. Where they use Github to manage the plugins: Submission Process · elementary/houston Wiki · GitHub
On top of that, the way billing is handled I prefer (using Stripe Connected Accounts). We allow freemium plugins but take a cut (I think their 30% is a bit high): Monetizing Your App · elementary/houston Wiki · GitHub
Also, thank you @azurecurve for kicking this off 
Also here is their AppCenter: https://appcenter.elementary.io/
And here is an example app on GitHub: GitHub - dahenson/agenda: A simple, fast, no-nonsense to-do (task) list.
Hi!
Taking the pricing issue on its own, and from the point of view of website owners (the people trying to find plugins), there are various models that could be applied, and I think it would probably be good if different models could be applied to any plugin in the CP repo (so some might follow model 1, some model 2, etc, according to each plugin author’s wishes).
Free (as in the WP repo) - support may or may not be offered
Free to download but one-off fee if lifetime support required
Free but periodic fee for support
Initial fee to access download then free lifetime support
Initial fee to access download and periodic fee for support (similar to CodeCanyon)
Limited free version (no support), fee to access pro version, then free lifetime support for pro version
Limited free version (no support), fee to access pro version, then periodic fee for support of pro version
It may well be impractical to offer all 7 models (and any others you can think of) so it may be better to cherry-pick a shortlist of models that could be offered, that would be most likely to satisfy both plugin developers and website owners.
So the point of my post is to say that I think it may be wise to decide first on what needs to be offered, then work backwards to how it can be achieved, whether by using Elementary or whatever.
On a related note, I would agree that a 30% cut sounds high. Maybe 20%?
And a final note: not all developers are able to open Stripe accounts (I can’t here in Malta), so even if Stripe is used to take payment for a plugin purchase, there must be a way to pay the developer that doesn’t depend on them having a Stripe account.
A lot of the payment options you mention may depend on the payment methods used.
Not only that but a way for developers to track users payment status. Which is something Elementary doesn’t do because everything is open-source and is a pay-what-you-want model.
There is a lot of complexity around ongoing subscriptions.
Sorry, I deleted my post while trying to edit. I will revisit this topic again.
I am planning on using Freemius for subscription management, payment processing, etc. This is all handled right within the plugin. What kind of a “plan” would this be?
Comments below are my own and I have no official standing.
I’d say competitor.
Assuming the repository goes ahead allowing premium plugins, this would directly compete by allowing people to buy from that plugin rather than through repository.
I guess a decision would be needed as to whether a plugin like that would be acceptable for the repository.
Personally, I appreciate what you guys @azurecurve and @CodePotent are doing to help move CP forward with a much-needed plugin repository. Figure out how you guys can get it launched, get the structure and payment issues resolved and be the two to get it going. My input on plugins specifically would be to go for core needs - a great contact form, security, spam comments, event calendar, and so on. Maybe a list of Top Ten needs for “core” plugins and then go from there. I’ve known many WP developers who made quite a good deal of money refining and trying to simplify “primary needs” core plugins like contact forms, event calendars, and so on. If all the plugins are GDPL, you could just fork one at a time and reboot them.
I’m just wandering the forum and offering my two bits. I’m done with marketing input but want to encourage you two guys as I see you both as being very valuable toward building a plugin repo - and helping move this ship forward in a key way. I think the hardest part will be planning where to host it, how to set up payment types (and whether or not CP wants a cut off the top), and getting it started and main elements agreed upon. Once that’s done you guys could get your foot in the door at a good time and promote your offerings thoroughly online.
@azurecurve, @anon95694377, it’s great to see you guys kicking off the discussion and raising lots of good points. I’ll add my thoughts to the mix and address a few of the comments at the end.
As @azurecurve noted, the WP docs are a good starting point, particularly for the rules. Other items to consider:
I would keep the top-level structure simple and use search filters in each of the views to help users find relevant results. For example:
new this week or new this month. Default to descending sort on creation-date.A Popular tab might be helpful, but only if the underlying metrics are measuring something more meaningful than the overall download count which is (arguably) artificially inflated for plugins that use quick release cycles.
I would omit Premium, Freemium, Free type views… these can be implemented as search filters. For example, each of the above views could have search filters to include/exclude premium plugins, particular categories, etc. And then, the search results could be sortable by, say, plugin age, install count, overall rating, etc.
I would avoid attaching fees to submitting or selling plugins through the repository. While some of the powerhouse plugins have enjoyed great success, the returns on plugin development (for the vast majority) may well be little-to-nothing. I feel certain that CP users will continue looking for plugins in the WP repo (even if they have to visit the site manually) until the CP repo reaches some form of critical mass. In other words, developers might simply upload to the WP repo under the allowed freemium model and dismiss the CP repo altogether. In terms of monetizing the repo, I’d not extend it further than paid placements in a Featured view.
I think Premium plugins should be allowed and should be marked as such, so that users can filter them in/out of search results. The distinction would be simple:
This makes it very clear and would help to maintain consistency in enforcement. Adding a Freemium category would murk the line and likely cause disagreements in the interpretation of the term, so I would avoid it. The terms free and premium can be used as search filters; they need not necessarily be dedicated views.
I like the idea of different update/support models, but think creating canned support models and/or enforcing a payment processor is too restrictive, and could even put ClassicPress in the position of having to be the plugin police when a user feels s/he is not getting the level of support they deserve/desire. Users are very accustomed to each plugin having it’s own support and update plans, so leaving this to each developer (same as now) is a familiar, accepted approach.
In case it isn’t clear by now, I’m advocating for developers to handle this themselves. Or, perhaps ClassicPress can handle this as an optional thing in exchange for a cut off the top on an as-needed basis. As @anon95694377 notes, there are concerns about supported payment processors in various jurisdictions. I will further note that there may be currency exchange fees and international transaction fees on developer payouts if the developer does not reside in the UK where the ClassicPress organization is formed. I made a donation to the organization and found out about both of these fees a week later while balancing my statement.
Does anyone know what sort of reporting and analytics are offered with the Elementary software? Or, if it is only available to admins? This is the biggest hole (aside of search) in the WP repo and is one of my driving reasons to use Freemius - well, that, and their cut is 10% max.
My feeling is that there shouldn’t be a plugin maintenance mandate, necessarily. A different (and less adversarial approach) would be to simply phase those plugins out of search results if the readme version hasn’t been bumped in n versions. At that point, they could be displayed in a list of other such plugins and dubbed adoptable (though not displayed in the dashboard). The reason for checking the readme version is simply that some plugins will continue to work across many core releases and do not require actual code updates – a version bump in the readme indicates someone is paying attention.
After the repo is up and running, there will be all sorts of tasks that must be completed on a regular basis. Some things can be automated, others will require some form of human interaction. A few examples:
Well, that’s all I’ve got for now…
Your best bet is to sign up for a free account at GitHub and run through the quick free courses at GitHub Learning Lab, which is an interactive and guided tutorial to help you get familiar with the terms and processes. If you don’t need to have private repositories, you can stick with the free account moving forward.
My feeling on how it will end up working is this: we develop a plugin within our own GitHub repos and then submit a pull request (see the courses) to the CP Plugin repo to have a plugin included. Then, it’s either approved, denied, whatever. After approval, you would continue to develop the plugin in your own account’s repo(s) and then submit a new pull request when you’re ready to release a new version. Bear in mind that I’m entirely guessing here, so don’t take any of this to the bank!
There’s a lot of work in forking a codebase and maintaining it…it’s not just a matter of reboot, whatever that means. 
Adding another related link; I know it’s early, just getting it down on paper.
So the point of my post is to say that I think it may be wise to decide first on what needs to be offered, then work backwards to how it can be achieved, whether by using Elementary or whatever.
I agree, and I think the first step in that is to sort out the terminology. Are we building just a directory or a repository too?
We must build a directory - that’s what everyone will search - but it’s less clear that we need the hassle of distributing the files.
Here I want to introduce the concept of audited plugins.
The most common source of security problems with WordPress, and by extension ClassicPress, is plugins. It’s the most common question I get asked when talking to someone in the security community: will you be auditing plugins?
I think it’s definitely something we need to be doing, and would set us apart from WordPress in a very positive way.
It also answers my own question: we should list in the directory any plugin that meets our criteria, and we should host in the repository only audited plugins. This flows from our “security first” approach - why would we want to host something if we’re not reasonably confident in its security?
(N.B. I’m deliberately not expanding the gory details of auditing and hosting plugins here - that’s for another thread).
TLDR: Yes I agree it would be nice. I just don’t know what implications this will have on growing our plugin and theme offerings.
Just being honest, while I agree this would set us apart from WP my concern would be the time commitment required to audit every plugin.
This, in my opinion, would add a complexity to submitting a plugin making it less likely that developers will want to deal with it. Thereby severely limiting our plugin growth.
Growing compatible plugins and themes is going to be a monumental task and be adding any barrier we are making that task way tougher to accomplish.
Another thought, what are the legal implications of auditing a plugin, verifying it is safe and then a site gets hacked because of it.
Probably a @timkaye question.
audited plugins ⊂ directory plugins
We obviously cannot audit all plugins - I didn’t suggest we try.
My bad, thank you for clarifying - I was trying to catch up on mobile.
What about the legal implication though?