A few weeks ago there was a lot of drama around the WordPress Theme Review team’s decision to require all themes in the WordPress.org theme repository to use the customizer for theme options. Personally I think this is great, and I’ve actually been looking forward to it since last year, when the idea was first presented. It’s a great example of how the leadership in the WordPress project have used their influential positions to help improve the platform.
WordPress.org fills a lot of roles, one of the biggest is distributing code in the form of plugins, themes, and even WordPress itself. Any change in how that role is fulfilled is going to be controversial, whether the decision to do so is right (as this recent change clearly was) or wrong. Due to the inherent controversy and the impact that these changes will have, caution must therefore be applied.
While I believe that caution is a necessary component to any major change, however, I also believe that it shouldn’t stand in the way of progress. The plugin repository, in its structure, assumes a lot of things about the state of the WordPress ecosystem that may have once been true, but are no longer applicable.
Barriers to Ubiquity
My own business is based around selling access and support to free software. This is something that founder of the GNU software project, Richard Stallman, as well as many other leaders of free software, have explicitly stated as not being incompatible with the idea of free software.
If businesses like mine (and all of those before mine) that have successfully sold plugins and themes for WordPress had not done so, we wouldn’t have the thriving WordPress ecosystem we have today.
For example, the plugin-specific support forums were created as a place for anyone to discuss a plugin, extend it, and fix its bugs. That model works really well across the internet for helping developers work together.
The reality is that WordPress.org’s plugin repo is mainly end-user or implementer-facing, at this point. WordPress.org isn’t GitHub, which does fulfill that role. The plugin support forums are currently a place where users expect support from the plugin author—whether the plugin is a business product or just a cool thing someone posted so others could share.
This expectation of free support is implied by the structure of the site and I question if accepting that the expectation of free support should remain a condition of distribution via WordPress.org. Maybe it is time that we allow plugin developers to opt-out of the support forums or to offer paid support through WordPress.org.
I know the idea of anything being paid through WordPress.org seems odd, but it is not at all at odds with the GNU ideology behind the site. Optionally charging for support doesn’t prevent the free distribution of free software. In fact, I think it encourages it.
Giving away your code a hundred times, or a thousand times, doesn’t change the cost to create it, if you have a free distribution platform like WordPress.org, and you’re not risking being buried in unpaid support.
Reducing the barrier to creating a sustainable and profitable business around freely distributed WordPress products is essential to the growth of the WordPress ecosystem. This is largely because WordPress business models are based on ubiquity and open access rather than scarcity and restricted access. The less-restrictive model is what Matt Mullenweg praised when he talked with Matt Medeiros in an excellent episode of the Matt Report podcast.
While I wanted to agree 100% with Matt Mullenweg, I had to remember the difference between his venture capital backed business and my own self-funded business. Automattic is in the business of growing the WordPress platform and the user base of its products so they can be more attractive at the next funding round.
I’m not criticizing that. In fact, I think it’s awesome. The fact that they can use that funding to build cool and almost entirely free products like WordPress.com and JetPack, while donating a ton of employee time to the open source project, both in terms of developer time and community organizing, is vital to the success of WordPress.
That said, most businesses in our ecosystem are self-funded and bootstrapped, and have to become profitable quickly.
WordPress.org probably shouldn’t become an eCommerce platform and I don’t think it’s the right place to be upselling plugins and themes. It could, however, better facilitate paid support as a way to encourage businesses that create themes and plugins to make a distinction between no-cost software and free support.
Doing so will help make end-user’s expectations clear, while providing motivation for developers to freely distribute their code.
Easier Ratings
Because plugins and themes can only be rated on WordPress.org, they are more likely to be used by upset or frustrated users than satisfied ones. In fact, many users use bad ratings to extort special attention from developers. This undue influence could be minimized by reducing the barriers to submitting reviews.
The most logical place to submit a rating or review is from inside of WordPress itself. This is not currently possible since there is no way to make an authenticated request against the WordPress.org plugin’s API. This makes adding endpoints to the URL for ratings and reviews impossible.
If WordPress.org acted as an oAuth provider it would be relatively simple to add a “Rate This Plugin” or “Rate This Theme” button to the WordPress admin.
Distribution, Not Development
While the plugin and theme repositories are powered by a version control system SVN, they hardly ever function as one. Instead, most of the time, single version commits are made by copying the plugin or theme from where it is actually developed—typically GitHub. Theme developers are not even given the right access to their SVN repos; instead they just upload a zip file.
This leads to several important issues.
WordPress.org’s SVN is not used for the development of most plugins, and, even if it was, it lacks the UI for easy collaboration. As a result, it’s generally unclear where a user can report or patch a bug. This is a big deal as it leads to the misuse of the support forums and becomes a barrier to collaboration.
Simply allowing theme and plugin developers to specify the location of their actual version control would go a long way in alleviating this issue. A new, optional piece of meta information in the theme or plugin header could be easily used for solving this.
The difficulty in keeping a plugin’s actual version control system in sync with WordPress.org’s SVN leads to less maintenance releases, and a lot of “try installing the new version on GitHub,” which is not useful to regular users.
There are a lot of ways to automate deploying from the real repository for a plugin to WordPress.org. It’s something that as plugin developers we spend way too much time on. Time that could be spent on improving our plugins. Allowing plugin and theme authors to opt-in to having their WordPress.org SVN repos act as SVN mirrors for the actual Git repo for the plugin would save developers time and serve end users better.
New Decisions and New Options
WordPress is growing rapidly and so are the ways it’s being used. It is an amazing platform that has given me so much. I honestly am wary to write something like this, which in some ways is a criticism, because of how much I love WordPress, and how much it has given me; but that is exactly why I want to see it grow and do better as a community and as a platform.
Is what I’m claiming 100% of the right way forward or do I have any illusion that this will come to pass? No, I don’t. I know many people reading this will disagree with me, or have better solutions to these same issues.
I’d love to know what you think in the comments or feel free to DM me in WordPress.org’s Slack (Shelob9) to discuss it further.
8 Comments