FILED UNDER:

Building Plugins and Themes IS Contributing to WordPress

✦

✦

A Note on Intent

I like to provoke discussion, but I’m aware that in the WordPress world, posts like this can go one of two ways. Either they become fuel to flame the “Matt ruins everything” narrative, or they turn into a rallying cry about how volunteers do so much work and get no respect.

That’s not what this is about.

Matt is my friend and is the reason WordPress is what it is today. I have nothing but respect for him and for the people working on WordPress core, themes, translations, documentation, and every other team. The community is full of dedicated, talented people doing incredible work.

That said, I think there are ways to make our community even better. This post is about one specific opportunity: how can we encourage more people to contribute to WordPress by becoming “extenders,” and why is that a good thing—a necessary part of our community?

Building plugins and themes isn’t a stepping stone to “real” contribution. It IS contribution, full stop. And we should talk about it that way.

The Current Definition

WordPress’s Five for the Future program defines what counts as contributing to WordPress. It’s comprehensive: core development, translations, documentation, support forums, community organizing, accessibility, design, training, and more.

But it explicitly excludes one thing: “Creating WordPress themes, plugins, or blocks (including those that are listed in WordPress.org).” The documentation acknowledges this work is “critical to extending the reach and utility of the WordPress project,” but states it “does not count” as making Five for the Future commitments.

The language matters. This work is called “extending” WordPress, not “contributing” to it. It’s categorized as something adjacent to WordPress, not part of it.

I understand the reasoning. The distinction helps define what counts toward organizational Five for the Future pledges. It creates boundaries around what the program tracks and recognizes.

But here’s what I think we’re missing: for most people who use WordPress, plugins and themes ARE WordPress. And the people who build them are doing essential contribution work that deserves recognition as such.

What WordPress Actually Is to Users

Ask someone why they chose WordPress over Wix, Squarespace, or Shopify. They won’t say “because of the twenty-three default themes and the core post editor.”

They chose WordPress because:

  • They can build an online store with WooCommerce
  • They can create beautiful pages with Elementor or Beaver Builder
  • They can optimize for search engines with Yoast or Rank Math
  • They can capture leads with Contact Form 7 or WPForms
  • They can create membership sites, learning platforms, directories, portfolios, restaurants sites, real estate listings, event calendars, and literally anything else they can imagine

None of this functionality exists in WordPress core. All of it comes from the 60,000+ plugins and 25,000+ themes that make up the WordPress ecosystem.

When someone says “I use WordPress,” what they really mean is “I use WordPress + a handful of plugins and a theme that together create exactly what I need.” The core is the foundation, absolutely. But the plugins and themes are what makes that foundation useful for their specific situation.

WordPress powers 43.6% of all websites globally—more than the next 10 platforms combined. That dominance exists because WordPress can be anything. And it can be anything because developers keep building plugins and themes that solve real problems.

The Real Work of Building Plugins and Themes

Let’s talk about what it actually takes to build a quality plugin or theme, because I think we sometimes underestimate this work.

Deep WordPress Knowledge Required

You can’t build a good plugin without understanding WordPress deeply. You need to know:

  • How the hook system works and when to use actions vs filters
  • WordPress coding standards and why they matter
  • Security best practices: sanitization, validation, nonces, capability checks
  • The proper use of WordPress APIs: options, transients, metadata, custom post types
  • Performance considerations and database query optimization
  • Internationalization and localization
  • Accessibility guidelines and WCAG compliance
  • How to work with the REST API and Gutenberg blocks

Many plugin developers know these systems more intimately than people working on other parts of WordPress. They have to—their code runs on millions of sites with infinite configurations, hosting environments, and other plugins installed.

Security Responsibility

When you maintain a popular plugin, you’re responsible for the security of potentially millions of websites. A vulnerability in a widely-used plugin affects more users than most core bugs ever will.

This means:

  • Staying current on security best practices
  • Responding quickly to vulnerability reports
  • Issuing patches and updates
  • Coordinating with security teams
  • Helping users understand how to stay secure

This isn’t optional work. It’s critical infrastructure for the WordPress ecosystem. The developers doing this work are protecting WordPress itself.

The Never-Ending Maintenance Work

Building a plugin or theme isn’t a one-time project. It’s an ongoing commitment:

WordPress updates – Every major WordPress release means testing your code, ensuring compatibility, updating deprecated functions, and sometimes rewriting significant portions to work with new systems.

PHP version changes – As hosting providers update PHP versions, you need to ensure your code works on PHP 7.4, 8.0, 8.1, 8.2, and soon 8.3. This often means refactoring code written years ago.

Browser compatibility – Themes especially need testing across browsers, devices, and screen sizes. What works in Chrome might break in Safari. What looks good on desktop might be unusable on mobile.

Plugin conflicts – With 60,000+ plugins in the repository, incompatibilities are inevitable. Users install your plugin alongside dozens of others, and when something breaks, they expect you to help troubleshoot.

Support questions – Every day brings new support forum posts. Users who don’t understand how something works, users with unique configurations, users who found actual bugs. Each question deserves a thoughtful response.

This maintenance work keeps WordPress functional for millions of sites. It’s unglamorous, time-consuming, and absolutely essential.

Documentation and Education

Good plugins and themes come with:

  • Clear documentation explaining features and usage
  • FAQs answering common questions
  • Video tutorials for visual learners
  • Code examples for developers extending your work
  • Changelog notes explaining what changed and why

This documentation work makes WordPress accessible to non-technical users. It’s the difference between “WordPress is too complicated” and “WordPress is so easy to use.”

Innovation and Experimentation

Here’s something that doesn’t get talked about enough: plugins and themes are where WordPress experiments with new ideas.

The Block Editor (Gutenberg) didn’t appear from nowhere. It emerged because millions of users were installing visual page builders like Elementor, Beaver Builder, Divi, and Visual Composer. These plugins showed that people wanted to design pages visually, not write HTML or shortcodes.

Core developers saw this trend and responded. Gutenberg is the result of WordPress learning from its ecosystem. The plugins didn’t compete with WordPress—they showed WordPress what users actually wanted.

The same pattern repeats throughout WordPress history:

  • The REST API emerged from plugins experimenting with JavaScript applications
  • Custom Post Types came from developers building complex sites that needed structured data
  • The Customizer was influenced by themes providing visual customization options
  • WooCommerce showed that WordPress could power e-commerce at massive scale

Plugin and theme developers aren’t waiting for WordPress to add features. They’re building the features, testing them with real users, and showing what’s possible. Sometimes those ideas influence core. Sometimes they remain as plugins forever. Either way, they’re expanding what WordPress can do.

Why the Distinction Matters

You might think this is just semantics. Does it really matter whether we call it “extending” or “contributing”?

I think it does, for several reasons.

It Affects How People See Their Work

When someone spends 20 hours a week maintaining a caching plugin that makes WordPress faster for 2 million sites, are they contributing to WordPress?

Currently, the official answer is “not according to Five for the Future.” Their work is valuable, sure. It’s appreciated. But it doesn’t count as contributing to WordPress.

What message does that send? It says: your work matters, but it’s not quite the same as “real” WordPress contribution. You’re helping, but from outside the project.

That doesn’t feel right to me. That developer IS making WordPress better. Their code runs on millions of WordPress sites, making them faster and more efficient. How is that not contributing to WordPress?

It Discourages People Who Could Help

Someone decides they want to contribute to WordPress. They’re good at PHP, they understand user needs, they want to give back. They start looking into how to get involved.

If they learn that building plugins “doesn’t count” as contributing, they might think: “I guess I should work on core instead.” But maybe their skills and interests align better with building plugins. Maybe they have ideas for plugins that would solve real problems for thousands of users.

By suggesting that only certain types of work count as “real” contribution, we might be steering people away from where they could have the most impact.

It Misrepresents What Makes WordPress Successful

WordPress succeeded because it’s infinitely extensible. The plugin system, introduced way back in WordPress 1.2, was—as co-founder Mike Little said—”a step change in WordPress development… probably the first step on making it the superior product that it is.”

That extensibility is WordPress’s greatest strength. It’s why WordPress powers 43.6% of websites while competitors with better funding, better marketing, and more polished interfaces struggle to gain market share.

When we treat plugins and themes as separate from “real” WordPress, we’re misrepresenting our own success story. The ecosystem isn’t a nice bonus on top of WordPress. It’s a fundamental part of what makes WordPress work.

What Good Looks Like

I’m not arguing that everyone who writes a plugin should get commit access to WordPress core, or that the Five for the Future program needs to track every plugin developer’s hours.

What I am saying is that we should recognize building quality plugins and themes as a valuable form of contribution to WordPress. That recognition matters.

It could mean:

  • Talking about plugin and theme developers as contributors, not just “extenders”
  • Featuring plugin and theme development work in WordPress community updates
  • Celebrating plugin and theme milestones the way we celebrate core releases
  • Acknowledging at WordCamps and in community spaces that building plugins and themes IS contribution work
  • Encouraging people who want to help WordPress to consider building plugins and themes as a valuable path

It doesn’t have to mean:

  • Changing how Five for the Future tracking works
  • Giving plugin developers voting rights on core decisions
  • Treating all plugins equally regardless of quality or usage
  • Anything that complicates the existing systems that work well

This is about culture and recognition, not governance or structures.

Why This Matters for WordPress’s Future

WordPress’s strength has always been its community. Not just the people who commit code to core, but everyone who makes WordPress useful: the support forum volunteers, the meetup organizers, the documentation writers, the translators, the accessibility advocates, and yes—the plugin and theme developers.

Each of these groups contributes differently. Each one is essential.

If we want WordPress to thrive for another 20 years, we need to keep encouraging people to contribute in all these ways. That means recognizing and celebrating all forms of contribution.

When someone builds a plugin that solves a real problem for thousands of users, they’re contributing to WordPress. When someone creates a theme that makes WordPress beautiful and accessible, they’re contributing to WordPress. When someone maintains and updates their work year after year, keeping it secure and compatible, they’re contributing to WordPress.

They’re not doing something adjacent to WordPress. They’re doing WordPress work.

An Invitation to Contribute

If you’re reading this and thinking about how you could contribute to WordPress, here’s what I want you to know:

Building plugins and themes is valuable contribution work. It’s not a stepping stone to something more important. It IS important.

If you see a problem that WordPress doesn’t solve, build a plugin that solves it. If you have an idea for a beautiful, accessible theme, build it. If you want to make WordPress better for a specific industry or use case, create the tools that do it.

Your work will matter. It will help people. It will make WordPress better.

And it will be contributing to WordPress—no matter what the official definitions currently say.

Because at the end of the day, WordPress is what we collectively build it to be. And the people building plugins and themes are building WordPress, just as surely as anyone committing code to core.

Let’s recognize that. Let’s celebrate it. And let’s encourage more people to contribute by extending WordPress in ways that make it better for everyone.