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 that clearly deserve a closer look — those issues are only relevant to this post to the extent that they impact the developer.
Let’s start by examining its benefits.
So how do you decide if the WordPress repository is worth the hassle for your plugin?Tweet
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 WordPress.org plugin 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 set up 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.Tweet
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 plugins that they’re higher quality and more trustworthy than plugins that 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 to provide 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.Tweet
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 developers 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.
Subscribe and grab a free copy of our book
11 Proven Techniques To Increase Your Credit-Card Disputes Win Success Rate by 740%
Share with a friend
Enter your friend's email address. We'll only email them this book, scout's honor.
Thank you for sharing
Awesome - a copy of '11 Proven Techniques To Increase Your Credit-Card Disputes Win Success Rate by 740%' was just sent to . Want to help us spread the word even more? Go on, share the book with your friends and colleagues.
Thanks for subscribing!
- we just sent your copy of '11 Proven Techniques To Increase Your Credit-Card Disputes Win Success Rate by 740%' to .
Have a typo in your email? click here to edit the email address and send again.
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.Tweet
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”
- The 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 that possibly qualify as spam, illegal, or morally objectionable plugins.
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?
A good one. Thanks. But if you consider what else you could like making the plugin just Paid or go on any alternative route from doing a Crowdfunding project to host entirely on Github, WP.org (yea now we could do that, thanks to Syed) is still best option. And we all know WP.org plugin directory is getting a revamp, and will get new process for plugin submission and some other discovery issue will be improved. The SVN thingy is not going anywhere in anytime soon though, but now we have so many ways to automate that if that really bothers you, for me I am kind of used, as thats what we are doing for most of our life! 😀
There is an entire other post to explore here regarding the wp.org (wootwoot) repo guidelines. For us, managing support on wp.org is a pain but doable. Adhering to GPL and trademark stuff is a no-brainer. Most of the guidelines are reasonable and defined well enough to navigate.
However, on the detailed guidelines page items 5-8 are where the real juicy parts are for plugin developers that are running a business.
For Postmatic we tried for nearly a year to stay within compliance of items #5 (no trialware) and #8 (no sending executable code) while working the freemium model. It got very complicated. And very expensive. I’ll explain.
We were at an advantage because we are at our core a mail-sending service. The first difference between a free plan and paid plan is that on the free plan mail is sent using your webhost (via wp_mail) and on the paid plan your mail goes upstream via our api to our Rails server.. which packages it up, and hands it off to Mailgun for sending. This flow gave us the opportunity to build out the premium features (appending links with UTM data for example) on the Rails end and let the plugin just be dumb.
I hate the experience in WordPress of using a plugin from the repo but then deciding I want to go premium and then having to download the premium version… and wonder if i should keep the free version active with the premium version… or delete it …. or what? It’s terrible user experience. We wanted to avoid that.
To do so we had our one version of Postmatic in the repo and abstracted any premium features to our Rails server.. and made the two talk over an api. This way there was one version of the plugin, with no ‘sleeping’ code. The plugin behaviour would change depending on the plan associated with the active api key – but again any paid features would happen in the cloud. Anyway. It was complicated, but an awesome user experience.
Just recently we gave up on the idea. Developing a feature in Rails and making it work over an api is a lot more complicated than just doing so in PHP. The example of appending UTM data to links is an example. We caved for financial and efficiency reasons. Now we maintain two versions of our plugin. Lame.
Thanks so much for sharing your experiences, Jason. It’s no doubt a complicated subject and one that each developer has to come to a decision about. I think the financial aspects are the ultimate deciding factor for many and I think if we surveyed a bunch of devs, their decisions would likely mirror yours given similar circumstances.
I think there is another factor when deciding if hosting on .org is worth the hassle and that’s your company or products goal.
For instance, sometimes Freemium isn’t just a business model, but a philanthropic motivation. When we developed one of our products we looked at .org as a distribution channel, but as we became more attached to the community and matured as a business, it became a way to give something great to the community. It’s still a part of our business model for the product, but when we are assessing the “hassle” of that choice, this motivation is a strong factor.
Definitely an interesting & important motivation. One which, I think, is a little less spoken of when weighing in the options.
That is an excellent point, James!
Thanks for saying this, James. Because after all that’s what that repository is for.
One thing that would really help with the analytics on the wordpress.org site is the number of new downloads vs download for plugin updates. Currently, the download count which accounts for both new installs and updates doesn’t help much to know how the plugin is doing.
I think using the WordPress Plugin repository is also a great way to validate your plugin idea. You can host it there and by using Freemius, you can get a lot of analytic data.
So I would say, it is worth the hassle 😀