Looking into Statamic, they also use Stripe and GitHub and take a 15% commission.
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.
Rules / Guidelines / Docs
As @azurecurve noted, the WP docs are a good starting point, particularly for the rules. Other items to consider:
- for submission process, plugin requirements, etc., new docs will be needed.
- where to store developer docs and who has access to update.
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:
A list of plugins that pay a monthly fee for placement. Non-paginated. Both free and premium plugins would be free to take advantage of this. Custom sort based on premium paid.
The firehose list of plugins. Paginated. Default to descending sort on last-updated date.
A list of the latest n plugins. Paginated. Or, even filterable down to
new this weekor
new this month. Default to descending sort on creation-date.
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
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
Free / Freemium / Premium
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:
- Free plugins are completely free, un-crippled, and not soliciting in any way.
- Premium plugins are everything else.
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.
Plans / Models
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 @zigpress 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.
Analytics / Reporting
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.
Plugin Maintenance & Adoption
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:
- vetting and approving plugins
- hearing complaints and enforcing rules
- administering the repo
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?
For any non-trivial program in a general-purpose programming language it is virtually impossible to say “there are no security issues” - there is no practical level of auditing to achieve that.
This is a well-known issue (we’re hardly the first to tackle this problem), so I would expect there to be standard legal language to deal with it.
I hope we can automate as much of our plugin auditing process as possible, both due to lack of time to review everything manually and to create an objective standard. A couple of potential starting points:
As others have said, even with an excellent automated review process there is no way to guarantee security, only to eliminate the “low-hanging fruit” in terms of potential issues.
I’d definitely be interested in exploring automated auditing further.
Under a system like this, ClassicPress would be building a plugin directory, not a repository. For each plugin, we’d store at least the repository name (on GitHub), the
git commit hash (to make sure that we’ve audited the current version of the code), and the basic info like icon, description, and website.
There are lots of auditing options, up to and including partnering with a company that does code review. That’s a topic for another thread.
We should not be auditing every plugin in the directory - not even in a fully-automated way - as it will cause vastly more problems than it solves.
I was simply trying to make the point that we need a directory, but unless we’re going to do something useful with it - like audited plugins - we don’t need a repository.
Clarification: I used the terms
directory interchangeably in my post above. I was referring to the directory.
I should clarify that a directory is a place to list public plugins and a repo is a place to work on code. From what I gather above, CP is looking at creating a directory, but not a repo.
It sounds like we (plugin devs) will submit plugins for inclusion in the directory, but will manage our repos on our own. This is ideal. The CP project doesn’t need to have copies of every branch of every plugin (in a repo) – instead, it only needs the finished plugin for listing (in a directory.)
No need to reinvent the wheel I think… Given the plethora of information available on existing plugins via the WordPress Plugins API, wouldn’t a plugin repository mirror approach make for a good starting point?
Auditing plugins is an impossibly time-consuming job and would mean nothing else would ever get done. Instead, we can start with the fact that most plugins will be already be compatible with ClassicPress if working with WP4.9… So wouldn’t a process of elimination be much easier…?
- remove anything made for specifically for Gutenberg (and that specifically won’t be made backwards compatible with Classic Editor, but most will anyway at least for a while.)
- temporarily remove “old” plugins (consider them abandoned until they can be manually reviewed - in the sense any “auditing” could be left to just checking if they still work or not.)
- can still mark/remove certain plugins if broken for ClassicPress as they come up, but keeping on top of those shouldn’t really be too hard. either they get fixed by the author and relisted or they don’t.
- perhaps a simple gist on Github could keep track of these via pull requests while the actual directory is being developed.