The Frustrating State of the Word  ## Metadata - Author: [[williambay]] - Full Title: The Frustrating State of the Word - Category: #articles - Document Note: --- tags: - #WordPress - #Leadership - #OpenSource Author: William Bay (reflecting on Courtney Robertson’s themes) Source: Personal Reflection (website) Reference: https://williambay.dev/the-frustrating-state-of-the-word/ date created: 2025-08-23 00:00 --- # Title: Reflections on WordPress Leadership, Community, Development, and Product ## Table of Contents: - 🧭 Introduction (#-🧭-introduction) - 🧑‍✈️ Leadership (#-🧑‍✈️-leadership) - 🫂 Community (#-🫂-community) - 🛠️ Development Process (#-🛠️-development-process) - 🧩 Product & Gutenberg (#-🧩-product--gutenberg) - 🧷 Conclusion (#-🧷-conclusion) - 🔗 References (#-🔗-references) ### References: - “The Frustrating State of the Word” by William Bay: https://williambay.dev/the-frustrating-state-of-the-word/ - Related WP topics mentioned: Gutenberg, Full Site Editing (FSE), Core/Canonical plugins, ACF Blocks, Jetpack, Media Library proposal by Matías Ventura. ## 📝 Summary: This reflection critiques the current trajectory of WordPress across four pillars: leadership, community, development workflow, and product direction. It questions whether there’s a unifying strategy guiding WordPress, highlights disconnects between decision-makers and practitioners (agencies, freelancers, and small businesses), challenges the developer experience of native block development versus ACF Blocks, and warns that a totalizing Gutenberg/FSE future could constrain complex builds and raise costs. The author urges clear strategic decisions—whether to pursue an Apple-like controlled ecosystem or an Android-like open marketplace—and even entertains forking or “two-paths” futures for WordPress. ## 📖 Main Content: The essay frames a tension between vision and governance. On leadership, it challenges ad hoc approvals (e.g., plugin previews, duotone filters) and urges accountability and transparent ownership—especially for major initiatives like the new Media Library. On community, it distinguishes discourse leaders (Twitter/Slack/Trac) from practical users and service providers, arguing that the latter’s needs are underweighted while competitors (Squarespace, Wix, Webflow) advance. On development, the author argues native block workflows are inefficient for agencies compared to ACF/ACF Blocks. On product, an all-Gutenberg path might optimize brochure sites while making complex builds more costly, potentially shrinking the agency ecosystem. The piece ends by calling for explicit choices: forked futures, “WordPress vs WordPress Pro,” or platform differentiation. Personal reflections: - The critique of governance aligns with common OSS pain points: unclear ownership, sudden scope shifts, and insufficient stakeholder input. - The development workflow argument captures a real productivity delta: native blocks can be powerful but often slower to ship; ACF Blocks still deliver predictable, maintainable outcomes for agencies. - The strategic fork proposal could reduce friction—one path optimized for hosted/All-in-Gutenberg, another preserving classic workflows and extensibility guarantees. ### 🗒️ Notes - Leadership - Perceived “Steve Jobs” aura around leadership vs practical fragmentation. - Lack of unified direction; initiatives feel divergent rather than convergent. - Concerns over “pet projects” approval (duotone filters; plugin previews). - Core/Canonical Plugins may disadvantage independent plugin developers and centralize power. - Call for accountability and public ownership of major initiatives (e.g., new Media Library). - Community - Two communities: discourse makers vs practical users (SMBs, agencies, freelancers). - Practical users’ needs underprioritized compared to competitors’ progress. - “Democratizing publishing” must include developer tooling and business needs. - Subscription competitors provide end-to-end simplicity; WordPress cost goes primarily to hosting, not product capability. - Development Process - Agencies rely on ACF/ACF Blocks for velocity and maintainability. - Native block development seen as slower and more brittle; DX concerns. - Workflow/tooling matter for agencies and freelancers delivering client value. - FSE described as unstable for complex sites; still “beta-like” in practice. - Product & Gutenberg - Suggestion that Gutenberg might have been better as a fork. - Risk: 100% Gutenberg path may limit complex builds, raising costs 2–4x. - Potential agency squeeze-out if complexity and costs grow. - Proposal for bifurcation: Gutenberg vs WordPress, WordPress vs WordPress Pro, .com vs .org differentiation; ask explicit strategic questions about ecosystem model (Apple vs Android). ## 📖 References: - The Frustrating State of the Word: https://williambay.dev/the-frustrating-state-of-the-word/ - Gutenberg project: https://developer.wordpress.org/block-editor/ - ACF Blocks: https://www.advancedcustomfields.com/resources/blocks/ - Full Site Editing overview: https://wordpress.org/documentation/article/site-editor/ ## 🗣️ Paraphrase: 1) Original: “There is something absolutely broken and fractured when a feature like [plugin previews] is approved of by a ‘leader’.” Paraphrase: Approving plugin previews from the top, without clear process or consultation, signals a systemic breakdown in how decisions are made. 2) Original: “If WordPress evolves into a 100% Gutenberg experience… development effort… would result in websites costing 2, 3, or even 4 times more… drying up WordPress agencies.” Paraphrase: A fully Gutenberg-centric future could inflate project complexity and costs, potentially pushing many client projects out of reach and threatening the sustainability of agencies. ## 📰 Newsletter: This week in WordPress: Learning, Building, and Big Questions - Learn & Level Up: If you’re mastering web dev, keep sharpening your JS+React for block development—but don’t sleep on pragmatic tools like ACF Blocks that speed delivery in real-world client work. Great primer: Advanced Custom Fields’ guide to Blocks. - Product Pulse: Ongoing debates about Gutenberg and Full Site Editing continue. For complex builds, many devs report friction with FSE’s evolving APIs. If you’re shipping enterprise-grade sites, weigh native blocks against ACF Blocks to hit deadlines without sacrificing maintainability. - Community Highlights: The conversation around leadership transparency and the new Media Library proposal underscores a simple truth: agencies, freelancers, and SMB owners need a bigger voice in roadmap decisions. Got real-world feedback? Share it constructively in Make blogs and component meetings. - Fresh Plugins & Tools: Keep an eye on ACF, performance-oriented block libraries, and QA automation (Playwright + WP-CLI) to stabilize editor updates. If you’re experimenting with FSE, try a dedicated block theme in a staging environment and track template parts with version control. - Links: - Advanced Custom Fields Blocks: https://www.advancedcustomfields.com/resources/blocks/ - Gutenberg developer docs: https://developer.wordpress.org/block-editor/ - WordPress Site Editor docs: https://wordpress.org/documentation/article/site-editor/ Stay curious, build responsibly, and may your merges be conflict-free. ## ✅ Action Items: Prompt for aligning article insights with your role and OSPO goals: “Analyze this article through the lenses of open-source advocacy, contributor engagement, and developer education. For each major argument: - Advocacy: Identify governance and transparency issues; propose concrete policy or process improvements (e.g., public ownership lists for initiatives, RFC periods, decision logs). - Contributor Engagement: Map affected contributor groups (agencies, freelancers, SMBs, plugin authors). Design inclusive feedback loops (surveys, office hours, component mentorship) and define success metrics (response rates, PR throughput, time-to-decision). - Education: Outline training to reduce friction (ACF Blocks vs native blocks curricula, migration guides for FSE, hands-on labs). Include syllabi, prerequisites, and artifacts (checklists, code templates). - Sustainability: Recommend funding pathways (grants for public goods, contributor time sponsorships, recognition progr - Summary: The author expresses frustrations with the current state of WordPress, particularly in terms of leadership, community influence, development process, and the product itself. They question the lack of a unifying directive for the platform's direction and the approval of random pet projects. The author also highlights the need for better communication with plugin developers and the importance of listening to the voices of small business owners and web agencies. They criticize the workflow and development process for native blocks and express concerns about the readiness of Full Site Editing. Ultimately, the author suggests the need for a strong emphasis on the developers that make the WordPress ecosystem run and considers the possibility of forking WordPress to address these concerns. - URL: https://williambay.dev/the-frustrating-state-of-the-word/ I’ve been having lots of thoughts of the WordPress leadership, community, development process and the resulting product lately. My outlook isn’t particularly great… #### Leadership: I think many in the WP community view Matt Mullenweg as our version of Steve Jobs. The quiet genius that dictates every granular detail of the the product to create the most seamless user experience ever. And, yes.. he is quiet and I’m pretty sure he’s a genius. But the reality is there are so many leadership roles for so many variety of teams, that I feel there *is* no unifying directive for where WordPress goes, and how it gets there. The roadmap is great but as these projects are released it feels that instead of converging and forming like Voltron, things just miss the mark. Things are diverging, not converging. And where are these random pet projects coming from, and who’s approving them? **Duotone filters**: WTFingF?? Who approved that bullshit? **Core Plugins**: Sure it’s Matt’s idea. But it seeks to shutdown plugin developers that makes the community what it is. And it turns a back on the people that have built this house. Is this an attempt to make WordPress more locked down? Is the intention to become an Apple like ecosystem, yet paint a paint the picture that anyone can build any plugin? You can’t be the iPhone and Android at the same time. There are repercussions to choosing one path or the other. Also… everyone still hates Jetpack. No Core Plugins please! **Plugin Previews**: Then we get today’s drama. The ability to preview plugins popped up out of nowhere. **A leader in the community approved this!** No communication with existing plugin developers. No warning. No poll on if it was a good idea… It was just launched. The [backlash was immediate](https://meta.trac.wordpress.org/ticket/7251). There is something absolutely broken and fractured when a feature like is approved of by a “leader” This also points to one of my biggest frustrations: Ever since Matias Ventura announced the [proposal for the new Media Library](https://make.wordpress.org/core/2023/07/07/media-library/) I’ve been desperately trying to find out who is running that project. As a web developer and a professional photographer, *I might have some insights*. But the Core Media team has no idea. Anthony the Media team lead and I asked around at WCUS. I’ve pinged Matias on Slack… 🤷‍♂️ WhoTF is running this project? Is it all behind closed doors? Why is this project so fractured that one hand doesn’t know what the other is doing??? **Matt needs to repair the damage done on Twitter** I didn’t want this to be a thing here in this post. But Mullenweg needs to apologize and address the issues with Se Reed. Leadership starts at the top. That’s what leaders do. #### Community: I’m questioning how much the WordPress community has an influence on the product these days. And when I say community, I mean two things. There’s the community that talks on Twitter and Slack, and discusses WordPress adjacent things. They’re the ones in Trac, making decisions on tickets, etc. Then there’s the people in the trenches. The small business owners using WordPress to run their site, the web agencies building sites for clients, the solo-preneurs and freelancers… I feel those are the voices that need to be heard most. Those are the people that use the product. I feel that we’re so up our own ass that we don’t see that Squarespace and Wix and Webflow are starting to provide superior products and features, and listening to what those people want and need. I understand WordPress *democratizes publishing*. But WordPress hasn’t been just a blogging platform since we got Custom Post Types. We as a community need to think about how best to build a platform for those endusers and how to provide the best tooling for the developers building for those end users (hint: it’s not native blocks). Besides, Squarespace and Wix, and Webflow all democratize publishing for $20-30/month now too. The only difference is the $20-30 people spend per month on WordPress goes to a hosting company. I don’t think the Community at large (all of us) want to acknowledge the superiority of the other platforms. They may not have WordPress numbers. But a wave is coming. I guarantee it. #### Development Process I recently saw one of the coolest sites I’ve ever seen recently. I asked the designer if it was a custom React site with Greensock animations and ScrollMagic triggers, and HTML5 video libraries for the cool video playback features… *He said it was a Webflow site with all native interactions*! (insert dumbfounded emoji) **Agencies and devs have been ignored**! There’s a reason most agencies are still using Classic Editor and ACF, or ACF Blocks. I personally have come to enjoy building native blocks, and using React and JS. I’m very thankful I took the time to learn JS when Matt told everyone to. But native blocks are an absolutely atrocious workflow. ACF and ACF Blocks is the saving grace for agencies and developers doing highly creative custom web development. The same block built natively would take 2-3 times longer than one built in ACF Blocks. This matters to agencies! This matters to freelancers! They need a seat at the table. They need to be listened to. They matter more than the Plumber that wants to spin up a site and slap a theme on it, because the agencies and the freelancers are the ones that the Plumber eventually calls to build his site because *he is a fucking Plumber*. Workflow and dev flow matters!!! Tooling matters! Agencies and freelancers need to be listened to. Don’t even get me started on Full Site Editing… It may be fine for brochure sites. But there is NO way it’s ready for the more complex sites. There may be ways to make it work. But the workarounds, and the constant changing, and breaking, and renaming of things is a detriment to those that want to attempt to build with it. Full Site Editing is still a Beta product… #### Product Speaking of the product. I understand change. But I still can’t help to think what I thought back in 2019… Gutenberg should have been a fork of WordPress. More change means less and less of the WordPress we know how to build for. We already have the Classic Editor plugin. Soon we’ll need a Classic Media Library plugin, and a Classic Admin Plugin, and a Classic Multisite plugin. Who knows, maybe this was what Canonical Plugins was setting the stage for… If I can tie the last few sections together here: If WordPress evolves into a 100% Gutenberg experience, we lose the Classic WordPress we’ve come to know. And fine, that’s ok. We’ll just make brochure sites from now on. But that is the consequence of doing so. There are things that agencies will not be able to do. Or the development effort to accomplish those would result in websites costing 2, 3, or even 4 times more to be realized, putting that development out of reach for businesses, and drying up WordPress agencies. > It’s seriously time to consider what the next 10-20 years looks like for WordPress but with a strong emphasis on the developers that make this ecosystem run. Not the WordPress contributors, but the developers that build the entire web with WordPress. > > Maybe that’s forking WordPress and iterating and evolving both paths. How that looks, I don’t know. I’m not that smart. Maybe it’s two things. Maybe it’s Gutenberg and WordPress. Maybe it’s WordPress and WordPress Pro. Maybe WordPress.com goes full Gutenberg, and WordPress.org **We didn’t ask these questions when we started Gutenberg. It’s absolutely imperative we ask them now.** Does leadership want to be Steve Jobs, or Steve Balmer? Does WordPress want to be the App Store, or does it want to be the Android market place? These questions need to be resolved and the consequences faced., The Frustrating State of the Word, williambay, 01hc1fc7zhgxgmeq1wyvrzf5h5.