WordPress powers a huge share of the web, yet no single company owns it. There’s no headquarters, no shareholders, no product roadmap handed down from an executive team. Instead, WordPress is built by a distributed network of volunteers and sponsored contributors who coordinate in the open, mostly on make.wordpress.org and in public Slack channels. Understanding how that system works helps explain why core is so stable, why plugin quality varies so widely, and why the software keeps moving forward without anyone technically being in charge of it day to day.
The Make WordPress Teams
Contribution to WordPress is organized into teams, each with its own focus and its own public blog under make.wordpress.org. The major ones include:
- Core: writes and reviews the PHP, JavaScript, and CSS that ship in every WordPress release.
- Design: shapes the admin interface, block editor patterns, and overall user experience.
- Meta: maintains WordPress.org itself, including the plugin and theme directories.
- Plugins and Themes: review submissions to the official directories and enforce guidelines.
- Support and Docs: staff the community forums and keep the developer and user documentation current.
- Polyglots: translate WordPress into dozens of languages and maintain locale-specific builds.
- Accessibility: audits core and default themes against accessibility standards.
- Hosting: coordinates between web hosts and core development on server-side compatibility.
- Marketing, Community, and Training: handle messaging, WordCamps and meetups, and the learning materials in the WordPress.org Learn platform.
Each team has one or more leads who set priorities and run weekly or biweekly meetings, all logged publicly. Anyone can show up, ask questions, and start contributing. There’s no gatekeeping application process for most teams; you contribute your way into trust.
Five for the Future: Who Pays for “Free”
WordPress is free to download and free to run, but building it takes real, paid work. That work is largely funded through a program called Five for the Future, which asks companies that profit from WordPress, hosts, agencies, plugin shops, to pledge roughly five percent of their resources back into contribution. In practice that means giving employees paid time to work on core patches, triage support forums, review plugin submissions, write documentation, or organize community events, instead of billing that time to clients.
This is why you’ll notice that a large share of core contributors list a company affiliation on their WordPress.org profile. It’s not a conflict of interest by default, it’s the funding model working as intended. The tradeoff is that priorities can tilt toward the interests of whichever companies sponsor the most contributor hours, which is a recurring topic of debate inside the project itself. Solo volunteers still matter enormously, especially in support, translation, and accessibility, but sponsored contribution is what keeps core development moving at a predictable pace.
How Decisions Actually Get Made
There’s no formal voting body for most WordPress decisions. Instead, the project runs on a mix of technical merit, public discussion, and designated leadership. Major directional calls, especially around the block editor and future “phases” of development, come from Matt Mullenweg as the project’s co-founder, often informed by heavy input from core contributors and community feedback threads. Below that top level, most day-to-day decisions are made by component maintainers, people who’ve earned trust over years of contribution in a specific area like the REST API, the media library, or block themes.
Each major release cycle has named release leads who set the schedule, decide what merges from the Trac ticket queue or GitHub pull requests, and communicate timelines through the Core team’s blog. Discussions play out in public tickets, Slack channels, and dev chat meetings, and rough consensus rather than a strict vote determines outcomes. This can be slower and messier than a corporate product cycle, but it also means changes get pressure-tested by people running WordPress on everything from tiny blogs to enterprise publishing platforms before they ship to millions of sites.
Inside the Plugin Review Pipeline
The official plugin directory is where most site owners interact with the contributor ecosystem without realizing it. Every plugin submitted there goes through a review process run by volunteer members of the Plugins team. That review checks for:
- Compliance with the plugin directory guidelines, including no obfuscated code and no tracking user data without disclosure.
- Proper licensing under the GPL or a compatible license.
- Basic security hygiene: sanitizing input, escaping output, and using nonces correctly for form submissions.
- A readme file that accurately describes what the plugin does and how to configure it.
Approval isn’t the end of scrutiny. Once a plugin is live, it stays subject to ongoing review. If a security researcher or another contributor reports a vulnerability, the Plugins team can require the author to patch it within a set window, and can pull the plugin from the directory entirely if it goes unfixed or the author goes unresponsive. That’s why a plugin’s “last updated” date and active install count on its directory page are meaningful signals, not just marketing. A plugin that hasn’t been touched in years, even if it still technically works, has had less recent scrutiny from this pipeline.
Themes go through a comparable, though separate, review process managed by the Themes team, with similar checks around security, licensing, and code quality before a theme is listed.
What This Means for Your Site
None of this is trivia. It has practical consequences for how you run a site. Core updates are unusually well-tested before release, which is why running the current WordPress version alongside a modern PHP release (8.1 through 8.3, with 8.3 and OPcache a solid default today) is safe and recommended rather than something to delay. Plugin quality, on the other hand, varies enormously precisely because the review pipeline can only catch so much at submission time and depends on ongoing reports afterward. Favor plugins with recent updates, responsive support threads, and a maintainer who’s active in the ecosystem.
A managed host takes some of this weight off your shoulders by tracking core and plugin vulnerability disclosures and applying updates or mitigations before they become a problem for your site; ServerBorn handles that monitoring as part of running on NVMe and LiteSpeed infrastructure. But it’s worth knowing that the underlying safety net, the review teams, the Five for the Future contributors, the release leads, is volunteer and sponsored labor, not magic. The more you understand who’s behind the software you run, the better decisions you’ll make about what to install and trust.
WordPress works as well as it does because thousands of people, paid and unpaid, keep showing up to review code, answer forum questions, translate strings, and argue over tickets in public. That’s a slower, messier process than a single company shipping a product, but it’s also why the software has outlasted plenty of tidier competitors.