Leaving WordPress Plugin Repository  ## Metadata - Author: [[rarst.net]] - Full Title: Leaving WordPress Plugin Repository - Category: #articles - Document Note: --- tags: - #WordPress - #PluginRepository - #OpenSource Author: [Andrey Savchenko (Rarst)] Source: [Andrey Savchenko's Blog] Reference: [https://www.rarst.net/wordpress/leaving-repository/] date created: {{2024-10-11}} {{time:20:00}} --- # Title: Leaving the WordPress Plugin Repository ## Table of Contents:  - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### References: - Savchenko, Andrey. "Leaving the WordPress Plugin Repository." [Rarst.net](https://www.rarst.net/wordpress/leaving-repository/) ## 📝 Summary: In this post, Andrey Savchenko reflects on his decision to remove his plugins from the WordPress repository. The post outlines the reasons behind his choice, highlighting issues with the repository's policies, the burdens on plugin developers, and the broader implications for open-source contributors. ## 📖 Main Content: Savchenko explains his dissatisfaction with the WordPress Plugin Repository, primarily due to: - **Maintenance Burdens**: Developers must adhere to guidelines and manage support, which can become overwhelming. - **Guidelines and Enforcement**: He criticizes the unclear and inconsistent enforcement of repository rules. - **User Expectations**: Many users demand free support, updates, and features, which adds stress to unpaid contributors. - **Alternatives**: By leaving the repository, Savchenko gains more control over his work, reducing the demands from users and the platform itself. Savchenko's decision touches on the challenges faced by open-source developers, especially when balancing community contributions with personal boundaries and priorities. ### 🗒️ Notes: - **Maintenance Challenges**: Developers often face high expectations without corresponding compensation. - **Guidelines Frustration**: The inconsistent enforcement of repository rules creates additional burdens for developers. - **Developer Fatigue**: Providing free support and updates is taxing, especially when users have unrealistic expectations. - **Control Over Work**: Leaving the repository allows developers to better control the distribution and support of their plugins. ## 📖 References: - Savchenko, Andrey. "Leaving the WordPress Plugin Repository." [Rarst.net](https://www.rarst.net/wordpress/leaving-repository/) ## 🗣️ Paraphrase: 1. **Original**: "I decided to leave the WordPress plugin repository because the burden of maintaining plugins there had become too high, with the community’s expectations far exceeding what I was willing to provide." - **Paraphrase**: Savchenko chose to exit the WordPress plugin repository because maintaining plugins there had become overwhelming, as the community's demands had grown beyond what he was able to sustain. 2. **Original**: "The repository has certain guidelines, but they are often unclear and inconsistently enforced, making it frustrating for developers trying to follow the rules." - **Paraphrase**: The repository's guidelines, though present, are frequently vague and enforced unevenly, leading to frustration for developers attempting to comply. ## 📰 Newsletter: In our WordPress community news this week, Andrey Savchenko shares his experiences and reasons for leaving the official Plugin Repository. He reflects on the challenges of maintaining free plugins, dealing with user expectations, and the inconsistent enforcement of repository rules. This insightful piece provides a look at the pressures faced by open-source developers and offers a fresh perspective on the importance of balancing community contributions with personal well-being. Read more on [Rarst.net](https://www.rarst.net/wordpress/leaving-repository/). ## ✅ Action Items: As a Developer Advocate, this article highlights important considerations when supporting open-source communities, particularly ensuring contributor well-being. You could develop resources to help plugin developers manage expectations and reduce the burden of free support, while advocating for clearer and more consistent guidelines within the WordPress Plugin Repository. ## 🧪 Hypotheses: 1. If more developers leave the WordPress Plugin Repository, it will signal a need for structural changes in its guidelines and support systems. 2. Developers who move away from official repositories may have better control over their work, reducing burnout and improving long-term contributions. ### 📊 Methodology: - Survey developers who have left or considered leaving the WordPress Plugin Repository to identify key pain points. - Analyze the frequency of guideline enforcement inconsistencies and their impact on developer satisfaction. ### ❓ Questions: - How can WordPress improve the repository to reduce the burden on developers? - What alternative distribution methods can plugin developers explore for better control? - Should there be more structured support for open-source developers within the WordPress community? ### 🔮 Future Research: Future research could examine the long-term effects of developers exiting centralized repositories like WordPress on open-source ecosystems. Additionally, exploring how alternative plugin distribution models impact developer satisfaction and user experiences would be valuable. ### 💡 Implications:  If developers continue to leave the repository due to similar concerns, it could reduce the diversity of available plugins and slow innovation. Addressing these issues could lead to a more sustainable open-source community with greater contributor retention. ### 🧠 Learning Styles Assessment: 1. **Visual Learners (Spatial)**: - **Present**: The article uses clear formatting but lacks visual aids. - **Improve**: Include diagrams or flowcharts showing the WordPress plugin development process and the challenges developers face. 2. **Aural Learners (Auditory-Musical)**: - **Present**: No auditory content. - **Improve**: Adding a podcast or audio summary could help auditory learners engage with the content. 3. **Verbal Learners (Linguistic)**: - **Present**: The language is clear and direct, with sufficient explanation. - **Improve**: Include more narrative elements or personal anecdotes from other developers to further engage verbal learners. 4. **Physical Learners (Kinesthetic)**: - **Present**: There are no hands-on elements. - **Improve**: Suggest practical exercises for developers on how to transition from the repository or manage plugin maintenance more effectively. 5. **Logical Learners (Mathematical)**: - **Present**: The article follows a logical flow but lacks data. - **Improve**: Add statistics or comparisons on plugin support time vs. developer satisfaction to appeal to logical learners. 6. **Social Learners (Interpersonal)**: - **Present**: There is minimal social engagement. - **Improve**: Encourage community discussions on the topic or link to relevant forums where developers can share their experiences. 7. **Solitary Learners (Intrapersonal)**: - **Present**: Reflection on personal experiences is a key part of the article. - **Improve**: Provide prompts for developers to reflect on their own experiences and how they align with Savchenko’s journey. 8. **Naturalistic Learners**: - **Present**: No connection to naturalistic contexts. - **Improve**: Draw parallels between open-source ecosystems and natural ecosystems, focusing on sustainability and balance. ### 📊 Accessibility Assessment: - **Screen Reader Compatibility**: The article is accessible but could include more descriptive alt-text for images and diagrams. - **Keyboard Navigation**: Fully navigable by keyboard. - **Contra - Document Tags: [[plugin directory]] [[rarst]] [[wordpress]] [[WordPress plugin]] - Summary: 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. - URL: https://www.rarst.net/wordpress/leaving-repository/ I have been saying for a while (considerably long while) that I had decided to remove my plugins from [official WordPress plugin repository](https://wordpress.org/plugins/). 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](https://subversion.apache.org/) (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](http://markjaquith.wordpress.com/2009/12/14/excluding-your-plugin-or-theme-from-update-checks/), 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](https://make.wordpress.org/core/2013/10/25/json-encoding-ssl-api-wordpress-3-7/), 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](http://wordpress.stackexchange.com/q/23047/847) 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](https://make.wordpress.org/plugins/2012/05/19/plugin-directory-refreshed-what-it-means-for-developers/) 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](https://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](https://www.rarst.net/category/wordpress/). 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](https://github.com/Rarst) is *exciting*, I can’t wait to experience more of it! :), Leaving WordPress Plugin Repository, rarst.net, 01j9wzhd6carp27rv9r4fs1c96.