An interesting debate has gained some momentum this week regarding WordPress Core (also known as canonical) Plugins, specifically their impact on the current plugin library for WordPress. To help with context, Jane Wells posted some information about Core (originally known as Canonical) plugins on the WordPress Development Blog. Jane says (interestingly, nothing about Sergio):
Plugins that are community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution. These plugins would be GPL and live in the WordPress.org repo, and would be developed in close connection with WordPress core. There would be a very strong relationship between core and these plugins that ensured that a) the plugin code would be secure and the best possible example of coding standards, and b) that new versions of WordPress would be tested against these plugins prior to release to ensure compatibility.
Then, Jay Canono stirred the pot this week with a well-conceived post questioning the idea of the Core plugin and if it would mean the end of the free-market plugin system as we know it. As opposed to reiterating the discussion, read the post and be sure to read the comments. There, you will find additional commentary from Matt Mullenweg and Mark Jaquith (WordPress Lead Developer) regarding the topic. For the purposes of this discussion, just know that I do not see this as the end of the free market for plugins on WordPress.
I’d like to add some additional perspective around how Core plugins impact WordPress in the enterprise space.
WordPress as a platform is rock solid. We use it to support programs like the Sony PlayStation Blog (both US and Europe), eBay’s corporate blog, and a recipe sharing community. Scale is never a concern. What happens, though, is we will be brought in on an already completed WordPress project where they are having issues with performance. Never has the issue been with WordPress core functionality, but rather with plugins used on the site that were just not developed efficiently. Regardless of a plugin issue here, the initial reaction is that WordPress as a platform is the issue. That’s bad.
The current plugin library has been an indispensable resource to our team across our projects involving WordPress. Many times, the functionality required for our projects has been addressed through at least one WordPress plugin which saves the team time and the client money. Wonderfully, it allows us to focus on solving new problems.
Fitting a functional need, though is really only one part of this puzzle. The usefulness of the plugin rapidly degrades if there are issues with its scale, security or support. The onus is ours to assure that plugins we’re using are designed to scale, free of vulnerabilities and will continue to function as WordPress evolves. If you can’t provide these types of assurances around functions within a company’s site, confidence can erode quickly.
So, from my perspective, the idea of Core plugins can be summed up as peace-of-mind. They are plugins that are not dependent upon a single developer’s passion for the plugin, but rather that of a group. Upgrading, performance and security issues are minimized as a result of the team actively managing the plugin.
These are all steps in the right direction when it comes to reinforcing confidence in the platform.
In the case of our projects, we need to provide assurances of stability. Steps like Core plugins help reinforce these assurances as there is a direct line of accountability that is all too often missing.