For nearly a decade, WordPress has been developed as an open source content management system, able to easily respond to changes and new demands in the marketplace. It is because of this flexibility and community development method that the software was easily able to grow and expand to serve more than 60 million users and 15,000 developers around the world in just under a decade since its first version was released to the public.
Automattic, the company behind WordPress, has committed to open source software and the GPLv2 license in all areas of development for its popular platform. This not only covers the core software itself, but also all of the themes, plugins, and other extensions produced for WordPress by the ever-growing team of third-party developers who serve the community.
As part of its commitment to open source development and distribution, WordPress has employed its own Trac repository solution for development purposes. This public forum allows developers to upload new and experimental versions of their plugins, or new functionality plugins altogether, and have them tested by the wider WordPress community for bugs, quirks, and other failings. It does this by maintaining an up-to-date change log, an advanced system for user comments and bug reporting, and an easy-to-use interface which encourages WordPress users and developers of all skill levels to engage in the testing and programming process.
It all sounds pretty good and, by most accounts, the WordPress Repository is a huge benefit for the wider community of software users. But, as with every feature of a product or service, there exists a good mix of both benefits and disadvantages to consider when using the WordPress Repository to develop a new or existing plugin in the public eye. It’s important to be mindful of these considerations in order to have the best possible experience when engaging with the community and perfecting a new functionality plugin or WordPress theme.
PRO: A Wide Base of Users Helps to Speed the Process of Bug Testing and Development
Without the WordPress Repository for developers, the people who create plugins would be forced to test their own plugins entirely on their own time. That might sound okay, but there are distinct disadvantages to bug testing one’s own work without the input of others. First, and most obviously, WordPress is an open source software solution from which many developers receive no profit even when their plugins are among the most popular ones available. That means that they may simply not have the time or financial resources to engage in wide-ranging testing of their plugin, leading to more bugs down the road and a never-ending cycle of updates, testing, bug reports, and alterations. It’s not a practical way to test the most complex and in-demand extensions of the WordPress software.
On the other hand, bug testing one’s own plugin is like attempting to proofread a paper that was self-written. Sure, some of the most obvious typos will be easy to find and they’ll be easily fixed. But writers and programmers have a lot in common, in that the more complex errors (in terms of writing, the grammar and syntax) will be far harder to decipher in a lone-developer environment. For this, a community of active and engaged users is preferable. They won’t be biased toward the code itself, nor will they have written any of it; this distance from the act of programming allows them to more easily detect bugs, deprecated hooks and functions, and poor semantic PHP code, and report it back to the developer.
In turn, the developer who engages the support of the WordPress Repository gets a bug-free plugin that works more efficiently than it would if they were the sole party responsible for developing and testing the new set of features. The developer saves time by outsourcing much of the testing to an unpaid crowd of advanced and everyday users, and they get valuable feedback on both the functionality as well as the usability of the plugin they’ve created.
CON: Automattic Isn’t Shy About Imposing Their Will on Developers in the Repository
It’s been discussed that WordPress is an open-source piece of software, and that the company behind the software is firmly committed to free or low-cost content management solutions that are released under a fair license. To that end, Automattic does not permit just any plugin to be submitted to the WordPress Repository. Indeed, being listed among other plugins in the Repository will require developers to accommodate a number of stringent requirements.
First among these is that any plugin listed in the WordPress Repository must be released under a GPLv2 license as it concerns the code written by the developer. Any plugin not featuring this code will simply be rejected until it has been updated to comply with this license. Furthermore, any plugin which does not explicitly state its software license will be assume to fall under GPLv2, and that’s how the code will be treated — whether the developer likes it or not.
This requirement is perhaps the most notorious, and the one that developers most often run into problems with, but it’s not the only one imposted by the Automattic team on independent developers who choose the WordPress Repository for their development needs. All WordPress developers who wish to use the resources of the WordPress Repository must submit their plugin with an extensive
readme.txt file which instructs users on things as basic as installation and matters as advanced as bug testing, reporting issues, and deploying the plugin itself after it has been installed.
Furthermore, the WordPress Repository does not accept any plugin which is not free. That’s an interesting requirement, especially as the WordPress community begins to really grow in size and many developers are making pay-for-play plugins. Those developers who do charge for their plugins can get around this requirement in a number of ways, including requiring an API key or requiring an add-on package of features. Of course, that add-on package would be ineligible for inclusion at the WordPress Repository.
Overall, the utility of the Repository cannot be understated. To be included in this list of developmental plugins, however, developers will need to agree to play by the rules set forth by the Automattic team. That can be a con for for-profit plugin developers or those who aren’t fond of the GPLv2 license, but it’s the price developers will have to pay when accessing a community of bug testers and fellow developers.
PRO: The WordPress Repository is a Great Way to Track a Plugin’s Downloads and Relevance
Most developers are curious as to the performance of their plugin in the marketplace, often wondering how many of the software’s 60 million users have found their specific piece of code to be useful, compatible, and worth installing. For those developers who use the WordPress Repository, plugin usage statistics are no guessing game or gamble. Instead, every download is extensively tracked by the software in real-time. Developers can log in at any time and view download statistics for all of their plugins separately, and this will help them determine whether they’re on the right path with their new functionality or if perhaps it’s something that needs to be more personally developed.
The WordPress Repository is the perfect combination of remote hosting, free publicity, and intricate tracking of statistics. It’s part of the overall Trac system, which is a larger piece of software used around the world by developers of all types. In fact, some of the most popular desktop applications are developed using Trac before their release, allowing mainstream developers to track their successes and failures in a user-friendly, and very objective, way.
PRO: The WordPress Repository Enables and Encourages Feedback from Real Users
Here’s something that baffles most WordPress developers more as the days go by: It is not possible to comment on a plugin listed at the WordPress Extend plugin gallery. Those plugins can certainly be rated on a “star” scale, and they can be updated with compatibility statistics as it concerns the latest version of the WordPress software, but user interaction with the developer is simply not possible in any form using WordPress Extend. That’s a major failure, and one the company has seen no need to correct over the past few years.
This failure is erased by the WordPress Repository, should developers opt to use it either in addition to, or instead of, using the WordPress Extend website on WordPress.org. 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.
There’s no need to commit to the interaction-deprived WordPress Extend website when the WordPress Repository allows for such robust, helpful communication among developers, and between developers and their more inexperienced plugin users. It’s something that should be serious considered when weighing the pros and cons of either using the Repository, committing to WordPress Extend through WordPress.org, or self-developing and self-hosting a plugin off-site.
CON: Uploading or Updating Plugin Files is Not Novice-Friendly with the Repository
In order to use the WordPress Repository to upload and update plugin files, users will have to install Subversion and use that software to do their business for them. That’s fine, of course, but it’s a bit more advanced than most users are comfortable with. It could easily be considered a combination of the command line and FTP, and this combination might help to explain why so many users aren’t fond of the Subversion software itself. Advanced developers will relish the opportunity to learn a new piece of software en route to greater plugin adoption and notoriety, but those who are new to developing their plugins and using the Trac may be confused, get frustrated or leave the process behind entirely.
Unfortunately, this doesn’t look like something that WordPress will be changing anytime soon. The Subversion software is one of the most consistent features and requirements of the WordPress Repository, and that’s likely on purpose. It’s a pared-down, basic solution to an advanced piece of software and, even though it’s hard to figure out, the conventional wisdom is that it benefits developers in the long run.
The good news is that Mac users already have Subversion installed to their system by default. Chalk this up to a rare Linux-centric victory within the Mac OS X operating system. Those developers who use Microsoft Windows, which is probably the majority of the WordPress development community, will unfortunately have to install the software using a third-party executable. That’s a hassle, but it’s the only way to publicize a plugin for testing and feedback within the official WordPress community.
PRO: Plugins Listed at the Repository Gain Exposure within the WordPress Community
It might go without saying, but it shouldn’t: Developers who list their plugins at the WordPress Repository are opening themselves up to an entirely new community of users and developers who will help their plugin gain exposure among the wider WordPress community. Remember, the same people who use the WordPress Repository to test plugins are the ones who are offering help and advice to novice users through the WordPress Community Forums. If a certain plugin has helped them solve a problem, they’ll more than gladly recommend it to a user and point them toward the WordPress Repository page for the plugin in the process.
The WordPress community overall is one that is full of advanced developers, new people eager to learn, and a company — Automattic — which loves open source software and is committed to helping users and developers create the best products possible. Though there are several disadvantages to consider when choosing the WordPress Repository, the net effect of placing a plugin there is overwhelmingly positive and will serve to benefit a plugin and its developer in the long run.