#StandWithUkraine
Andrey “Rarst” Savchenko —  — WordPress — github, plugin, subversion

Leaving WordPress plugin repository

I have been saying for a while (considerably long while) that I had decided to remove my plugins from official WordPress plugin repository. As things go — the more you talk about intentions the less action happens.

So I had mostly shut up about it for a while longer, until it was all too obvious that now is as good time as any.

Since I plan to blog more about WordPress things — the perfect opportunity to explain my reasons in a post it is.

Technicalities

The repository

It is ironic how we spell out “official” plugin repository, because WordPress never intended to have any other repositories.

Its core code is written in line with that assumption, interacting only with WordPress.org API. Notably API with infrastructure (code and logic both) that is private and undisclosed to public.

While implementing alternate repositories is technically possible, it is not supported (or even reasonably conventionalized) and such implementations are disallowed to be hosted in official one for distribution.

Development

WordPress uses Subversion (SVN) version control as storage and interface for plugins’ code. While SVN is usable it is hardly pleasant or popular for modern development, lacking in newer distributed version control paradigms, performance, and other conveniences.

More so WordPress actively discourages using its repository for active development, reducing it to storage mechanism with updates only happening for release versions.

Simply put that is not how development happens these days. Adjusting to the requirements is not particularily challenging. Having to adjust is one of many disregards to development realities and workflows in my opinion.

Updates

Compatibility

The process of releasing new versions is one of the most important functions for repository. From the perspective of WordPress users it is highly polished, friendly, and robust process.

From the perspective of WordPress developers it is a disaster.

The technical implementation of updates works as following:

  1. WordPress core submits all of the plugin data to the API
  2. API responds with available updates, which are displayed to user

It sounds reasonable until you bash your head on all of the data, including plugins that have never been intended to be hosted in official repository.

For such plugins completely invalid updates are routinely suggested, destroying them in the process of installing completely different plugin on top of them.

The exclusion of plugin from updates is technical nightmare, requiring excluding them from the data at the stage of HTTP request being made.

Adding insult to injury the data format had been changed last year, breaking all of existing implementations of such exclusions in the wild. In a project with extreme backwards compatibility commitments this came across as blatantly uncaring on top of already dismissive state of it.

Privacy

And let’s go back to all the data for a second. For example a data like specific developer producing specific plugin for a specific client (typical information contained in plugin’s header). Which is between them and no one else’s business.

Yet WordPress just helps itself to that information, without clear opt–out or even warning about it.

The privacy debates about data submission had been going longer than I am even using WP. They had never achieved anything above being laughed off.

Socialities

Promotion

The one commonly mention laud of repository is supposed “promotion” it brings to your plugins. Well, personally I hadn’t seen any. Unless the fact that there should only be one repository is promotional for hosting in it.

The only plugins that do receive promotion are those with highest downloads count and short “featured” list.

User base

I can understand restricting repository–hosted plugins to getting updates only by official process and not via third party sources/locations.

However, this technicality turns into de–facto lock–in, in lack of procedure for migrating away. The users of your plugins are not actually yours, WordPress considers them on loan on condition of using the repository.

Support

Repository automatically provides plugin with support forum and prominently displays stats from it.

The thing is — it is not a choice, it is an obligation. The option to not have support forum was explicitly considered and explicitly denied. Regardless of what makes sense to developer as support venue (if anything for free plugin), the presence of support forum is mandated.

I would be less irked about it if WordPress forums weren’t that horrible for my taste. Relatively less.

Legalities

I could as well omit this section, but I feel it would come across as holding back. Some people rather enjoy my recurrent meltdowns on topic of licensing.

There is very little licensing related in my decision to leave.

Yes, this in rules:

If you don’t specify a compatible license (such as in a license.txt file or referencing or declaring a license somewhere in the code or readme.txt file), what you check in is considered GPLv2 or later. By committing code to our repository at all, you accept this condition.

wordpress.org/plugins/about/guidelines

is batshit crazy. Needed to be said if we are on topic, but who cares.

Doing it for myself

To be very clear this isn’t manifesto or call to action. It is hardly even worth noting, coming from someone with such a small amount of plugins in repository and downloads of (barely above ten thousands).

Just a summary of reasons for my personal decision. I would never think less of anyone for using repository or more for leaving it. I very well might host client work in repository if necessary.

Naturally all my released plugins remain public, open source, and will be maintained to exactly same degree. I had added the list, including latest plugins that had never been released at official repo, to my WordPress category archive.

But energy, attention, nerves, and lines of code I am wasting on these issues are better dedicated to other things — I trust in and enjoy.

Is WordPress way always your way?

I had long learned that WordPress plays by certain rules and developers are rarely priority in those rules.

It is important to recognize the force in the market these rules had made WordPress. They also made the bubble of priorities and expectations around it, plain alien to many of processes happening in modern PHP community right now.

I think for developers it is extremely important to recognize (and admit to themselves) when playing by the rules WordPress gives is holding you back. Repository is not the first WordPress “rule” I abandoned (rest in peace PHP 5.2, really) and it won’t be the last to get in (and showed out of) the way of my professional direction and growth.

WordPress way or the highway.

You know what? Highway is exciting, I can’t wait to experience more of it! :)

Related Posts

11 Comments

  • David Coveney #

    Yep. Yep, yep all the way. Our biggest download success by a massive margin, the search/replace thing, isn't in the repo. Meanwhile, the amount of effort we've put into getting code just so for the repo hasn't always felt like it's been paid back. We exposed the amount of information the API received about an install many many years ago but it went largely unnoticed. Nobody cared, really. I'm not sure what the answer is, but having your plugin on the repository amongst the white noise of everything else that's on there is barely a benefit any more and we're certainly having similar conversations internally.

  • Andrey “Rarst” Savchenko #

    Our biggest download success by a massive margin, the search/replace thing, isn’t in the repo.
    I hadn't had people come to me because of my plugins. But I had people use my repo plugins, because of my reputation elsewhere. Arguably I had been promoting repo more than it had been promoting me. :)
    We exposed the amount of information the API received about an install many many years ago but it went largely unnoticed. Nobody cared, really.
    People do care. Alas not the people who could overturn these practices and not many enough to make them care.
    I’m not sure what the answer is
    I am not sure what the answer is, but by know I am sure enough to pick an alternate direction for myself and spend my attention differently.

  • Ændrew Rininsland #

    Damn skippy. Couldn't agree more. I want to mouthpunch somebody — anybody — every time I need to use SVN to update the repo. And the support forums must be killed with fire — I have a single pinned post in mine, saying "Go to GitHub for support, you WILL be ignored here." Your post also mentions a tonne of other things I hadn't even considered (privacy implications; the license thing which *is* utterly batshit crazy). Very good points all around. The sad thing is, it could be much better than this. I'm a Git-vetted contributor on Drupal.org (meaning I can create new projects in the Drupal-equivalent of the WordPress Plugin Directory), and getting to that point was an enormously long process — first I had to write my module, then I had to lint it against community standards. That much is similar to WordPress. But then I needed to post it to a code review, wherein both established community members and other new developers analysed what I'd written for consistency, security, standards, best practices, etc. In order to get an established member to review my code in a reasonable amount of time, I had to review three other new projects, in turn improving my knowledge of the Drupal API and community standards. Once my code failed the review by the established member, I then needed to review three *more* new projects before getting a re-review of my own code. Then, once approved by the established community member, it was then reviewed by a member of *the freaking security team* — after which I was granted Git access. Long and arduous? Yes. Frustrating? Often at times. Do I feel more confident about the quality of my Drupal contributions than I do of my WordPress contributions? Absolutely, no question whatsoever. While I'm not sure I advocate such a community-intensive process for WordPress (my guess as to why WordPress has way more themes than Drupal is this process — I kind of doubt most designer-y, front-endian folks could be arsed to endure something as technical and long as the Drupal.org Git-vetting process), *some* better sense of community around 3rd party development would be most welcome. As for me, I'll probably keep using the directory, but only as the most user-land representation of my code — everything substantive will be on GitHub.

  • Andrey “Rarst” Savchenko #

    WordPress always took pride in having a lot of extensions, same way it takes pride in having a lot of market share. It's very flat and flattering presentation of situation with either. In case of extensions the low entry bar to repo have always been beneficial to quantity. Which resulted in abysmal average quality. I often feel unfair with critique of review and approval process for repositories, since in the end it needs people resources. However I feel it's not too upfront of WordPress project to take such credit solely on quantity, swiping other issues under the rug (almost literally — in hiding those 2+ years plugins).

  • Rene #

    > The only plugins that do receive promotion are those with highest downloads count and short “featured” list. When you create a detailed readme.txt and you properly tag your plugin you are benefiting on several places at the plugin repository. E.g. Popular tags, highest rated, recently updated and so on. The secret is to periodically update your plugin and you get a lot of new downloads and user. About SVN: Personally i use for my plugin "Mashshare" the WP SVN repository as a pure download repository and use git for developing. Best, René

  • Andrey “Rarst” Savchenko #

    E.g. Popular tags, highest rated, recently updated and so on.
    You might have point about tags, I hadn't thought much about that facet. Most popular / highest rated from quick look have respective first pages covered with plugins with upwards of 500K downloads. It just makes big plugin bigger.
    The secret is to periodically update your plugin and you get a lot of new downloads and user.
    Except that too frequent updates are considered to be gaming the system and explicitly forbidden by rules. ;) And I want to spend my time improving my code, not spamming to "stay ahead". As for me having to do this to bump visibility is a hack and downside, not benefit.

  • Mayeenul Islam #

    It's a hard decision to take, and I can't deny your logic. But I've a different view. An icon like you, if raise voice somewhere, would take effect. WordPress has some mirrors in GitHub. I don't know the mechanism, but it seems we can simply shift from SVN to Dist. VC. If you leave because the system is in wrong shape, it won't be fixed anymore. I want to see it from a different perspective - if anything is wrong, why not I first start fighting against it, by NOT leaving, but being IN it with my VOICE, and CHANGES. Rarst, it'd be a drought if we miss you in WP Plugin repo. Truly. :(

  • Andrey “Rarst” Savchenko #

    An icon like you, if raise voice somewhere, would take effect.
    You are overestimating my status in community. While I have some visibility, I do not think I have much (if any) practical influence in mainline WordPress project matters. I had about one thing I count as success in that regard — getting licensing rules in line with de–facto situation (allowing Apache License v2, etc) while back.
    WordPress has some mirrors in GitHub. I don’t know the mechanism, but it seems we can simply shift from SVN to Dist.
    Just this weekend (after this post was written and already scheduled) it was announced that WP will trial accepting contributions to core via GitHub pull requests. I consider that is amazing shift, but it doesn't impact repositories for now and it's not enough to overturn literally years of issues, covered in the post, overnight.
    I want to see it from a different perspective – if anything is wrong, why not I first start fighting against it, by NOT leaving, but being IN it with my VOICE, and CHANGES.
    I am one person with only so much capacity to do things. Sometimes this means walking away from things towards things that matter more for me. I don't feel like fighting with repo.
    Rarst, it’d be a drought if we miss you in WP Plugin repo. Truly. :(
    I very much doubt absence of my plugins would matter much. I had never been a popular plugin developer and that makes it much easier for me to leave like this. And the point I am making here is that there are different ways to build and manage our infrastructure. Sometimes it's playing to the central repository, sometimes it's not.

  • Julien Maury Ⓦ (@TweetPressFr) #

    Hi. Can't wait to see your next shares on github :) But here I'm all at sea ! Considering the fact you do not want to waste your time with support for free plugins you should not releasing your stuffs on wordpress.org and github is the perfect place. Moreover you CAN build your own repository. A lot of premium WP Businesses have their own repo with updates and stuffs like this. Indeed if you're not satisfied with wordpress.org as hosting for your plugins then leave, we know where to find you :) again Github is the perfect place. Codes you share hardly regard average users. To me wordpress.org IS for average users. So yeah this is probably not the best place for you. Nevertheless I think WordPress needs good programmers and developers so it could be highly improved in the next years. Maybe it's not time for leaving...

  • Andrey “Rarst” Savchenko #

    Considering the fact you do not want to waste your time with support for free plugins
    Hadn't said that. I am perfectly fine (and do) provide reasonable support for my plugins. But dot org forums are not my happy place and I want better workflows and control for it than that.
    Moreover you CAN build your own repository.
    There is a lot of nuance between technical possibility and getting to favorable results. Composer infrastructure was shaped from the start with complete open source and even two levels of it in Packagist/Satis for different needs. Everyone uses same tools, everyone improves same tools. WordPress infrastructure is that closed source API you need to bend backwards to hack around. And when you do — likely no one will care but you. We have literally dozens implementations, I wouldn't even call competing — they are just floating around.
    Codes you share hardly regard average users.
    Yep. I solve my own problems primarily.

  • Hunter Satterwhite #

    Well said Rarst. Well said.