Is the WordPress Plugin Repository Worth the Hassle?
If you’re a relatively experienced WordPress plugin developer, you’ve most likely already asked yourself this question — possibly more than once.
If you’re a relatively new WordPress plugin developer, you’re probably asking yourself “Wait … why would I not want my plugin in the repository?!”
Both questions are valid.
As with most things in life, there are advantages and disadvantages to uploading a plugin to the official repository at WordPress.org. In this article, we’ll look at both sides of the debate.
The advantages of the repository are fairly transparent and obvious, while the drawbacks are both less obvious and arguably of greater impact. As a result, this article will spend more time on the latter than the former.
It’s important to note at the outset that we’re taking a look at the repository here purely from the perspective of the developer — not the end user (although some user-centric factors do impact the developer in the long run). So while there are a number of user-oriented issues with the repository — issues which clearly deserve a closer look — those issues are only relevant to this post to the extent that they impact the developer.
So how do you decide if the WordPress repository is worth the hassle for your plugin?
Let’s start by examining its benefits.
The Advantages of the WordPress Plugin Repository for Developers
Plugin developers enjoy a number of benefits from using the repository to host their plugins. Depending on whether you’re a professional plugin developer with lots of products or are doing it just for the love of WordPress, or some other goal, each of these advantages may carry a different amount of weight for you.
Initially, it’s important to note one critical requirement for use of the repository as a developer: Each plugin in the repository must be free to download and use. Upselling is permitted, but there are limits.
For example, you can create two versions of your plugin. The first — the one hosted on the repository — must be free, but it also must be functional. So you can create a version of your plugin that’s not as fully featured to upload to the repository, then offer the upsell to the user for the full-featured version, either for a one-time payment or on a subscription basis. AKA the Freemium model.
So there’s a benefit to developers willing to take these extra steps: you get all the benefits of the repository for a free “light” version, and the opportunity to then upsell your premium version to users of the free version.
The working theory behind this setup is that users of your free version will be pleased with its functionality, and so they’re more likely to be willing to shell out cash to use the premium version. That setup itself is definitely a benefit to the developer. It makes it easier to close the sale, and it greatly increases the size of the audience that’s been moved to that easier-to-convince spot in the buying cycle.
The WordPress repository increases the size of the audience that can potentially be moved to an easier-to-convince spot in the buying cycle.
And that leads us to the second key benefit for developers using the repository: exposure to a vast and diverse audience. As Scotch.io’s “How to Build a WordPress Plugin, Part 2” points out, the repository is good for developers because you become “part of the WP community.”
That’s especially true when you consider that the WordPress community includes people from a number of different countries who speak many different languages: “It makes a lot of sense to have your plugin easily [translatable] without having to touch its core coding.”
That community can also help speed up the process of debugging and future development — undeniably another benefit to using the repository.
Developers can certainly debug and refine their own plugins. But there’s no denying that the process is a whole lot faster, smoother, and more thorough with the assistance of a large, active user base.
That’s something that a lot of developers — especially those without premium versions to upsell — simply can’t replicate on a cost- or time-efficient basis. It’s just not practical.
Then, too, there’s the tendency we all have to some degree: getting “code-blind” to our own work. Just like writers often can’t see their own typos or grammatical errors, developers can sometimes miss problems in their own plugins — problems an engaged group of users can more easily find and identify.
The repository can also offer a plugin developer access to timely and nuanced user feedback. As Speckyboy notes in this article outlining some of the pros and cons of repository-hosted plugin development:
“The Trac software solution which enables the Repository is actually quite adept at letting users comment on a plugin’s features; plugin users will be able to directly interact with the developer of the code, and they can both comment on the features as well as review them using the basic commenting system which is as useful as it is intuitive.”
When doing so is made easier, users are more likely to provide meaningful feedback, which can only make your work better.
Finally, there’s a built-in user perception for repository-hosted plugins that they’re higher quality and more trustworthy than plugins which aren’t listed there. (Whether that perception matches reality is another question — one we’ll explore later in this post.) That makes it likelier overall that a user will download, activate, and use your plugin.
So much for the advantages. What are the drawbacks?
Support Is A Heavy Load to Carry
By requiring the developer providing the support to take action to “get” the requests, the repository is running a pull system, as opposed to one that “pushes” notifications to the developer.
If your plugin only has a few dozen downloads, and plugin development is solely a hobby for you, this might not be a big deal. But if this is your business, and/or you have several plugins, including a few particularly popular ones, a pull system can really wreak havoc on your productivity, your schedule, and your sanity.
Let’s face it: it can be a time-consuming process to offer support for free plugins, even if the developer wants to offer support.
Offering support for free plugins can be very resource-consuming, even if the developer is inclined.
Underneath many developers’ complaints about the repository, there’s a perception of a lack of concern for the developer.
Often, these developers’ criticisms are met with some version of “If you don’t want to spend time supporting a free plugin, avoid the repository. Release it on GitHub.”
But even if you don’t mind reasonable support requests for free plugins, you’re still fighting what many believe to be an unfortunately designed platform for support, that places all the obligation on developer to monitor, and doesn’t necessarily work with your established workflows.
Review/Rating System Susceptible to Abuse
Many developers agree that the current review and rating system is just too susceptible to manipulation by those with bad motives or those who simply didn’t understand what the plugin did, how to use it, or ask for support.
James Laws of WP Ninjas put it well in an article at ManageWP:
“The problem is that there is no accountability when someone makes these ratings. Users say something is broken simply because it doesn’t work in their particular setup, but that isn’t always the case. Sometimes something else is broken in their setup, or they just don’t understand how to use the plugin properly.”
Quality Problems with Plugins
While users may perceive repository-hosted plugins as being of higher quality, that’s not necessarily true for developers, many of whom have commented on the presence of plugins of questionable quality in the repository.
One example of this perception can be found in the post “What Lurks in the WordPress Plugin Repository?” which details the following issues (admittedly, in 2011):
- “More than half of the plugins in the repository are not compatible with WordPress 3.x”
- “85% of the plugins I tested had PHP warnings, errors and notices”
- “With a little bit of digging I found a plugin in the repo with a weakness and was able to use it to hack a site and turn it into a drone”
- “Only 32% of those 15,000+ plugins have been updated in 2011”
- “… two-thirds of all plugins haven’t been updated this year, and one third haven’t been updated since 2009.”
Mika Epstein recently gave a spectacular presentation about the entire review process from the POV of the volunteers (five, believe it or not — just five) who review plugins submitted for the repository (on average, 35 each day).
From this presentation, it’s clear that review is a long, arduous, and detail-oriented process that’s designed to catch problems with code, as well as violations of the plugin guidelines such as name, trademark, etc.
Does it succeed? Not entirely. Of course, any system run by humans will be susceptible to some level of fallibility.
The Review Process Itself
Mika’s presentation also lays out many of the issues with the review process. Basically, with a team of five volunteer members and 35 plugins submitted on average each day, working on an outdated BBPress platform, it’s not reasonable to expect a speedy, streamlined, developer-oriented process.
The end result: On the “add plugin” page on WordPress.org, you won’t find out how long you’ll wait — but you can see how many plugins are in line ahead of yours.
As of the time of this writing, 145 plugins in the review queue, with 108 waiting for their initial review.
And, as the Speckyboy post put it, “Automattic isn’t shy about imposing [its] will on developers in the repository.”
It’s also worth noting that the process of uploading and submitting isn’t very user-friendly, especially to novices, which doesn’t encourage new developers to try out their skills and add to the WordPress experience in creative ways.
Not Enough Data!
Hosting your plugin on the WordPress plugins repository will not provide you with much statistics and data about who’s using your plugin and how. You will develop blindly, having to do only with the number of downloads, and an estimate of the number of active installs. This makes it practically impossible to make any intelligent, data-driven decisions.
As Chris Lema suggests — when you have data you are not “flying blind” and it can open your eyes to very important and urgent decisions that need to be made regarding your plugin. These decisions will usually be for the benefit of your users in terms of development and support, and eventually for your plugin’s marketing & pricing optimization process.
Here’s a quick hangout Matt Cromwell had with Chris Lema, discussing this topic, among other related ones.
Plugin developers hosting their plugins with the WordPress repository do have a legitimate way of obtaining their plugin’s data, nonetheless, as long as it’s done with the user’s consent & approval. Freemius Insights can help with that by providing all of the missing pieces in a WordPress plugin’s data puzzle.
Restrictions on Plugins
Finally, developers must contend with a long list of restrictions on plugins accepted for the repository.
As outlined in brief at WordPress.org’s Plugin Directory information page for developer, those restrictions include:
- Your plugin must be 100% GPL compliant (and that includes non-PHP assets, such as images & CSS, which are not derivatives of the WordPress code)
- Can’t do anything illegal or “morally offensive”
- Developer must use the Subversion repository given by the plugin team if you want it to show up on the WP.org site — the directory “is a hosting site, not a listing site”
- Must have a readme.txt file that’s readable and compatible with the WP plugin readme file standard
There’s a much longer list of guidelines and requirements, including a prohibition on violating WordPress trademarks and another reminder that the team can remove plugins which possibly qualify as spam, illegal, or morally objectionable plugins.
Conclusion
A perceived lack of awareness or consideration for the developer community’s perspective and needs underlies many of the drawbacks mentioned in this article.
Coupled with the perceived or actual problem with the quality of plugins accepted for the repository and the many requirements that get enforced, it’s no wonder that the repository loses its appeal to some developers.
So what’s the solution?
If you’re a developer who’s interested in making a quick contribution to the WordPress community with your code — you may want to consider GitHub, like Coen Jacobs:
“It basically is a remote repository where you can store your code. But GitHub offers more. You get a basic ticket system, wiki and a nice way to view (and share, if your repository is public) your code online.”
Of course, GitHub offers its own set of advantages — and disadvantages — to plugin developers. So you should consider the question critically before making a final decision.
But, if your intentions and plans in the WordPress plugin world are long-term & repeating — and maybe you’d also like to monetize your plugin using the freemium model at some point — maybe the WordPress.org repository is right for you, despite all of its drawbacks. Besides, as members of the WordPress community we should press for improvements to the repository to address its drawbacks and problems.
What do you think? Are the advantages of the repository worth all the drawbacks and problems for plugin developers?
Originally published at freemius.com on June 2, 2016.