The WordPress.org plugins repository team is about to change. The plugins are not changing, the architecture is remaining the same. It is the plugin repository’s review team that will be changing. One long time volunteer is retiring and new review team members are being onboarded.
Mika, a keystone member of the plugins review team, is stepping down this summer. She intends to continue being a part of the community and help onboarding new team member(s), but announced her time will be focused on her own projects and life instead of the review team after July 1st.
The decision to retire has been in the works since last summer. The review team has been working to expand the time since, but recent delays in responses from the review team have started to crop up. Leading to “open letters” being written and complaints being voiced. If you have been paying attention to the official #pluginsreview slack channel you have seen the delays being openly discussed and the team has been transparent about the issues a growing backlog creates and that they are working to address it.
The review team is facing a common problem we should all be able to sympathize with: There is more work to do than time available to do it.
Let me briefly introduce the WordPress.org plugins repository:
- 100% free for developers to list their plugins.
- Hosts over 60,000 FOSS (Free Open Source Software) projects.
- Has a regular need for upkeep and day-to-day operations (reviews, new submissions, support, security reports, etc…)
- The day-to-day operations come at no cost to the developers.
- The day-to-day operations are handled by a few people.
- Only repository available in default WordPress installations.
The first and last points solidify why this repository is so alluring for WordPress projects. The repository provides a lot of services for the developers at no cost and their code will be searchable directly in every WordPress installation. You would be crazy not to think that is a good deal for the plugin developers.
But … with only a couple of team members supporting over 60,000 plugins. I think you can see how the disparity in volunteer time available vs. the number of plugins created this all too common problem of more work than time available. The workload the plugins review team has historically been able to handle would take a whole department of highly skilled (both technical and communication skills) professionals. Yet, this was provided free of charge to the plugin developers in this repository.
These free services proved too enticing, the buffet at this free lunch is about to be Slim Pickens, if it is not already. Which is why, before you push your way into the line, you should take a step back and ask yourself.
Do you really need the WordPress.org plugins repository?
This may be shocking, but WordPress theme and plugin developers do not, strictly speaking, “need” the WordPress.org plugins repository.
With a little work you can self-host a plugin and gain more than you think you are losing out on. You can take ownership of your project’s distribution, there are marketplaces to help you sell your projects. Yes, you are allowed to sell access to open source code, which can help with a very serious issue every developer faces: monetization.
Independently hosted plugins can succeed. By taking on a little more responsibility, these plugin owners deal with less bureaucracy and gain a lot more flexibility.
Here are a few examples:
There are thousands more to be found on third-party marketplaces too.
Every independent plugin reduces the burden to the already overworked volunteers helping 60,000 other projects seeking free support. Think of this option as giving the WordPress.org volunteers a reprieve. The more theme and plugin developers that choose to self-host or to join other repositories, helps reduce the burden on the review team.
Going solo comes at a cost. Here is what you need to know if you self host your plugin or theme:
- You will need to self promote and market your project directly to users, but this is true for all successful projects.
- You will need your own website and supportive services, or use a marketplace.
- You will need to add auto-updating functionality in your plugin (trust me on this)
Luckily, there are already services and code out there to help you administer your self hosted projects.
Services like:
Marketplaces like:
There are guides to help you too:
There are lots of options available out there, do not let them be overshadowed by the WordPress.org repository.
One more thing.
If you self-host or sell through a marketplace or your plugin is available through WordPress.org. You should have a public vulnerability disclosure policy. This help security researchers privetly and safely report sensitive issues in your project, and reduce your burden on the repository that distributes your code. More details on this below.
It is OK to stay, but you can help by lightening the load.
I admit, understand why developers want their project(s) on the WordPress.org plugin repository. So, if that is you. Let me share how you can reduce the burden on the review team.
If you handle security issues yourself, this will help reduce the workload for the review team. Don’t worry, this can be easy. The first step is having a public vulnerability disclosure policy (VDP) and include it with your plugin.
A VDP, in its simplest form, is just a note that informs security researchers how to report security issues found in the project. It can be as short as saying “Please email security bugs to security@your_domain” or it can be a link to a page on your website or at a third party vendor that helps with these sorts of services.
By having a VDP you will be taking responsibility for handling security bug reports, instead of leaving it up to the repository team volunteers.
Other code repositories and projects have this built-in. GitHub’s Security.md file is one example, and there is a proposal for a security.txt file on websites. The WordPress community can learn from these examples and make their own solution, maybe implement their own solution like a “Security” field in the plugins headers.
I have been working with plugin developers in the last few months. Encouraging them to include a security point of contact in their plugins description, and a few have already set this up.
Github has made this easy to set up for projects via the Security.md file, some developers have gone this route:
Official WordPress.org community plugins recently added text about how to report security bugs:
Some projects have set up their own VDP or Bug Bounty (BB) programs include:
These projects took responsibility for addressing security concerns, in doing so reduce the burden on the plugins review team. Patchstack created a managed Vulnerability Disclosure Program (mVDP) to provide a free solution for developers because we found we had trouble finding points of contact. This free service helps project owners take responsibility and help reduce the burden on the plugins review team as well.
The more projects that sign up for Patchstack’s mVDP (or set their own VDP or BB program) the more we will reduce the burden on an already overworked volunteer team’s time. I encourage everyone to take responsibility for handling security reports in their projects, and stop relying so much on a small team providing a free service.
Remember that change is coming, and there are things plugin developers can do to help the repository team they have relied on for years. Remember how much this repository provides at no cost and review team that only asks for cooperation, patience, and understanding of their situation.
