Every WordPress site runs on an open source stack. That stack includes an operating system, a web server, a database, PHP, WordPress itself and the browser on your end. Each layer writes its own rules for who approves a change. This post walks the stack one layer at a time and shows where each project keeps those rules.
Key takeaways
- The big picture: a WordPress site runs on an open source stack of separate projects, from Linux to the browser, and each one writes its own rule for who approves a change.
- Why it matters: picking a host picks most of that stack for you, including the PHP version, the database and the web server.
- Yes, but: sponsorship buys different things at each layer, and nothing in this record shows a sponsor buying a decision.
- What’s next: open Tools > Site Health > Info, find your layers, and read one governance page.
🏠 When you pick a host, you pick an open source stack
You’ve done this. A client needs a site, you compare three hosts, and you pick the one with the friendliest support chat. Congratulations: you also picked an operating system, a web server, a database and a PHP version. Still, most of us skip that part of the plan.
Disclosure: I work at Pantheon, a WordPress and Drupal host.
WordPress says what it wants. Its requirements page recommends PHP 8.3 or greater, plus MariaDB 10.11 or MySQL 8.0 or greater. It also names Apache or Nginx, and HTTPS support.1 However, those are recommendations, not hard minimums. Still, they name four separate projects before WordPress loads a single plugin.
Disclosure: I worked at GoDaddy until July 2026. The full list of my relationships sits at the end of this post.
For years, this stack was my budget line, not background noise. At GoDaddy, I chose which foundations and projects received its open source funding. Over time, the question I heard most from budget approvers was short. Why pay for software anyone can download for free?
This post, then, is my long answer. In short, free to download doesn’t mean free to keep running, and every layer of the open source stack has people deciding how it runs.
🧱 The open source stack under one WordPress page
The last post compared who sits on each project’s board. This one goes a level down: who approves one change, at each layer a page load passes through.
Every layer below gets the same three bullets: what it does, who approves a change, and where that’s written. Four layers also carry a note from my funding work. The listings in those notes are public. My reasons are my account, so they’re labeled that way.
Text description of the illustration
What this illustration shows
- A tall wooden pantry unit has six shelves. From the bottom up, their tape labels read LINUX, WEB SERVER, DATABASE, PHP, WORDPRESS and BROWSER.
- Each shelf holds a few unlabeled jars and boxes, so the shelves look alike from a distance.
- On the floor beside the unit, a closed toolbox carries one label: BUILD TOOLS. It sits outside the shelves, just as build tools sit outside the page load.
- At the left, the developer sits in a manual wheelchair with a laptop on their lap and looks up at the bottom shelf.
- Meanwhile, at the right, the pantry coordinator holds a clipboard and points at the WORDPRESS shelf, near the top.
- In other words, WordPress is one shelf among six, and every shelf has its own rule for who restocks it.
🐧 The operating system: Linux
- What it does: first, it runs the server your site lives on, at the bottom of the open source stack.
- Who approves a change: subsystem maintainers accept patches, and maintainers pull from each other in what the kernel docs call a “chain of trust.”2 Only one person, the top maintainer, can merge into the main kernel repository. So your client’s homepage depends on a merge button exactly one person can press.
- Where it’s written: “A guide to the kernel development process,” which the kernel also publishes in its own documentation.3
That one person rarely sees a patch first, though. The same guide notes the top maintainer picked only about 1.3 percent of the patches in the 2.6.38 kernel directly.4 That figure is old, so treat it as an illustration of the design, not a current count. So the merge button works less like a bottleneck and more like the last signature on paperwork that subsystem maintainers already checked.
🌐 The web server: Apache or NGINX
- What it does: it takes each request, hands it to PHP, and sends the finished page back. WordPress also names both servers.5
- Who approves a change: at the Apache HTTP Server, a Project Management Committee governs. For example, a change that needs consensus needs at least three binding +1 votes and no veto.67 Meanwhile, NGINX sends every contribution through F5’s Contributor License Agreement, and “the technical committee for that project” reviews it.89
- Where it’s written: Apache’s voting guidelines, and also NGINX’s governance page and CONTRIBUTING file.
Apache’s page also lists open questions about its own rules. One reads, “We may need a better definition for ‘lazy consensus’.”11 A rulebook that admits its gaps in writing is more than most of us keep for our own client work.
🗄️ The database: MySQL or MariaDB
- What it does: it stores your posts, users and settings.
- Who approves a change: Oracle’s MySQL governance page says “Oracle is the project lead for MySQL community edition.” Oracle also nominates the first project leads and committers.12 MariaDB, however, splits the job. Its Foundation board “does not make technical decisions.”13 Meanwhile, a 2025 agreement says MariaDB plc “employs the developers who contribute more than 90% of the code of MariaDB Server.”14 So picking a database also picks between a company that decides and a foundation that pointedly doesn’t.
- Where it’s written: MySQL’s Community Governance Model; similarly, MariaDB’s Foundation pages and board minutes.
Same job, two different answers to who approves a change. And your host picked one of them before you ever logged in.
🐘 The language: PHP
- What it does: it runs every line of WordPress’s PHP code.
- Who approves a change: language changes go through RFCs, or requests for comments. Then each primary vote “requires a 2/3 majority.” Voters are people with php.net accounts who’ve contributed code, plus representatives they choose.15
- Where it’s written: PHP’s “Voting on PHP features” RFC, and also the PHP Foundation’s governance page.
- From my funding work: today, the PHP Foundation lists GoDaddy.com as a Gold sponsor, as of 2026-11-09.16 However, its governance page grants up to three board seats “automatically” to qualified Platinum sponsors.17 Gold isn’t one of them. Meanwhile, the Foundation pays for work, and the RFC vote decides the language.
I pointed budget approvers at PHP first. Fixing the language fixes it for every plugin, theme and site at once, which no single plugin budget can do.
📝 The application: WordPress
- What it does: it’s the part your client logs in to.
- Who approves a change: the Core Handbook says the project is “run by a core leadership team and led by co-founder and lead developer.” In addition, lead developers hold “final authority on technical decisions.”18 Finally, release squads form by open nomination, and the Executive Director or a designee confirms them.19
- Where it’s written: WordPress’s Core Handbook, on its “Project Organization” page and its release team page.
The same handbook page describes no process for appointing or removing lead developers.20 On the other hand, release squads form through a public nomination call, and a later post announces the confirmed squad.21 So if you’ve ever waited on a merge before a release, you know whose names to look for. So the release squad gets a public nomination call, and the final say gets no paperwork at all.
🖥️ The browser and the standards it follows
- What it does: it turns HTML and CSS into the page your client sees.
- Who approves a change: in Chromium, you need “a positive review from an owner of each directory your change touches.” Owners are committers with at least three months’ tenure.22 Similarly, Firefox requires “a module owner’s OK” to check code into that module.23 At WebKit, by contrast, existing reviewers select new committers and reviewers, and an objection goes to consensus, then a majority vote.24 Finally, at W3C, Working Groups develop the specifications, and a W3C Council hears formal objections.25
- Where it’s written: Chromium’s code review guide, Mozilla’s module ownership policy, WebKit’s commit and review policy, and W3C’s Process Document.
- From my funding work: W3C’s Diversity page names GoDaddy among the TPAC 2025 sponsors who “financially helped 26 of our attendees.”26 In other words, that’s the TPAC Inclusion Fund, not W3C membership.
Standards are only as good as who’s in the room, and the fund paid for people who couldn’t otherwise get there.
🧰 Build tools: the software stack you never ship
- What it does: Node.js runs the build tools behind the block editor. In fact, WordPress’s docs call it “essential” for block editor work.27 Likewise, PHP_CodeSniffer runs the WordPress Coding Standards, which are “a collection of PHP_CodeSniffer rules.”28
- Who approves a change: OpenJS hosts Node.js. Platinum members appoint directors, and “Gold and Silver members vote among themselves to select their representatives.”29 PHP_CodeSniffer, on the other hand, now lives at PHPCSStandards, the “official continuation” of the original, abandoned package.30 However, its README names no maintainers. Its contributing guide says pull requests that fail their checks “will likely be ignored by the maintainers or closed.”31 Neither file names those maintainers, or who approves a release.
- Where it’s written: OpenJS’s board announcement and members page, and the PHP_CodeSniffer README and contributing guide.
- From my funding work: OpenJS lists GoDaddy as a Silver member.32 Also, PHP_CodeSniffer’s Open Collective page lists “GoDaddy.com” as a corporate funder.33 Both readings date from 2026-11-09.
Build tools sit outside the open source stack your visitors load. Even so, every site you build passes through them. If the tools that build and check your code break, you can’t ship a fix, even though no visitor ever loads them.
💸 Who pays for the open source layers?
Here’s the open source stack as a table, in stack order. WordPress is one row, sorted the same way as the rest. Each layer’s section above names the document.
| Layer | Project | Who approves a change |
|---|---|---|
| Browser | Chromium | An owner of each directory a change touches |
| Browser | Firefox | The module owner |
| Browser | WebKit | Reviewers; reviewers also pick new reviewers |
| Standards | W3C | Working Groups; a Council hears formal objections |
| Application | WordPress | Core leadership team; lead developers on technical calls |
| Language | PHP | RFC voters, two thirds majority |
| Database | MySQL | Oracle, as project lead |
| Database | MariaDB | Developers, most employed by MariaDB plc; the board doesn’t decide technical questions |
| Web server | Apache httpd | Committers by vote; any binding veto stops a consensus change |
| Web server | NGINX | A technical committee, under F5’s contributor agreement |
| Operating system | Linux | Subsystem maintainers, then the top maintainer |
| Build tools | Node.js | OpenJS hosts it; members elect or appoint the board |
| Build tools | PHP_CodeSniffer | Not stated in its README; label: unknown |
So, why pay for free? Because money buys different things at each layer of the open source stack. For example, a Gold sponsor at the PHP Foundation gets no automatic seat, and the language still changes only by RFC vote. By contrast, a Silver member at OpenJS gets a vote for a board representative. Meanwhile, a TPAC sponsor pays for people to attend.
In other words, none of that buys a commit. Still, the record here doesn’t show any sponsor changing any decision, and W3C’s Process says “no Member receives preferential treatment within W3C.”34 Whether sponsorship buys a seat is its own question. Season 2 asks it in post 2.4.
🔎 Read one governance page in your open source stack
Find the open source stack under your own site, then read how one layer decides.
- Open Site Health
In WordPress, open Tools > Site Health > Info. WordPress documents the screen on its Site Health Screen page.
- Find your layers
The Server section shows the server architecture, the web server and the PHP version. The Database section shows the database server version. (I checked mine on 2026-11-09. It took less time than finding the coffee.)
- Pick one layer
Start with the layer that broke most recently. After all, you already care about that one.
- Read its governance page
Open that layer’s page from the list below, and look for who approves a change and where the rule is written.
- Linux: the kernel development process guide.
- Apache or NGINX: Apache’s voting guidelines or NGINX’s governance page.
- MySQL or MariaDB: MySQL’s Community Governance Model or the MariaDB Foundation’s about page.
- PHP: the PHP RFC voting rules.
- WordPress: the Core Handbook’s Project Organization page.
- Your browser: Chromium’s code review guide, Mozilla’s module ownership policy or WebKit’s commit and review policy.
📋 Quick answers about the open source stack
It’s the separate projects a page load passes through: an operating system such as Linux, a web server, a database, PHP, WordPress and your browser. Each one decides changes its own way.
RFC voters do. A primary vote needs a two thirds majority. Voters are people with php.net accounts who’ve contributed code, plus representatives they choose.
It depends on the layer. A Gold sponsor at the PHP Foundation gets no automatic board seat. OpenJS Silver members, on the other hand, elect a board representative.
Open Tools > Site Health > Info in WordPress. The Server section lists the web server and PHP version, and the Database section lists the database version.
❓ Questions you can use
Ask these of any layer in any open source stack, including the ones I didn’t cover:
- Approval. Who approves one change, and how are they chosen?
- Records. Where is that rule written, and when did it last change?
- Blocking. Can one person or one company stop a change?
- Money. What does a sponsor get: a seat, a vote, or a thank you?
If you find a governance page I missed, send it. I’ll add it to the list.
My relationships that bear on this post
- Pantheon, my employer, a WordPress and Drupal host.
- GoDaddy, where I managed the Five for the Future contributors until July 2026. I also chose which foundations and projects got its open source funding, among them the PHP Foundation, OpenJS, W3C’s TPAC Inclusion Fund and PHP_CodeSniffer.
- The WordPress Training Team, where I was a faculty member and a team rep. I’m not active on the team now.
- The FAIR Package Manager, where I used to sit on the Technical Steering Committee.
- The WPOCC, where I’m one of the founding board members.
- Questions I asked on stage at WordCamp US 2024, the WordCamp Europe 2025 fireside and WordCamp Canada 2025.
- My own words appear in court exhibits in WPEngine v. Automattic (Dkt. 18-28, 107-4, 18-5 and 69-16). The series reports that litigation in pairs.
🧭 Where this post sits in the series
This post follows 1.5, Which open source projects does Merge Conflicts compare, and why these? It uses the labels on the Merge Conflicts methods page. Next up is 1.7, where WordPress sits among other open source projects. Follow along on the Merge Conflicts series page.
Footnotes (34)
- WordPress. “Requirements.” wordpress.org. https://wordpress.org/about/requirements/. Accessed 2026-11-09. ↩︎
- The Linux kernel development community. “2. How the development process works.” A guide to the kernel development process, The Linux Kernel documentation. https://docs.kernel.org/process/2.Process.html. Accessed 2026-11-09. ↩︎
- The Linux kernel development community. “2. How the development process works.” A guide to the kernel development process, The Linux Kernel documentation. https://docs.kernel.org/process/2.Process.html. Accessed 2026-11-09. ↩︎
- The Linux kernel development community. “2. How the development process works.” A guide to the kernel development process, The Linux Kernel documentation. https://docs.kernel.org/process/2.Process.html. Accessed 2026-11-09. ↩︎
- WordPress. “Requirements.” wordpress.org. https://wordpress.org/about/requirements/. Accessed 2026-11-09. ↩︎
- The Apache Software Foundation. “How the ASF works.” apache.org. https://www.apache.org/foundation/how-it-works/. Accessed 2026-11-09. ↩︎
- Apache HTTP Server Project. “Apache HTTP Server Project Guidelines and Voting Rules.” httpd.apache.org. https://httpd.apache.org/dev/guidelines.html. Accessed 2026-11-09. ↩︎
- NGINX. “CONTRIBUTING.md.” nginx/nginx repository, GitHub. https://github.com/nginx/nginx/blob/master/CONTRIBUTING.md. Accessed 2026-11-09. ↩︎
- NGINX. “NGINX Open Source Governance.” nginx.org. https://nginx.org/en/docs/governance.html. Accessed 2026-11-09. ↩︎
- Apache HTTP Server Project. “Apache HTTP Server Project Guidelines and Voting Rules.” httpd.apache.org. https://httpd.apache.org/dev/guidelines.html. Accessed 2026-11-09. ↩︎
- Apache HTTP Server Project. “Apache HTTP Server Project Guidelines and Voting Rules.” httpd.apache.org. https://httpd.apache.org/dev/guidelines.html. Accessed 2026-11-09. ↩︎
- Oracle. “MySQL Community Governance Model.” dev.mysql.com. https://dev.mysql.com/community/governance-model/. Accessed 2026-11-09. ↩︎
- MariaDB Foundation. “About MariaDB Foundation.” mariadb.org. https://mariadb.org/about/. Accessed 2026-11-09. ↩︎
- MariaDB Foundation. “Board Meeting 2/2025,” minutes with Memorandum of Understanding (Attachment A). mariadb.org. 2025-03-12. https://mariadb.org/bodminutes/2025-03-12/. Accessed 2026-11-09. ↩︎
- PHP. “Request for Comments: Voting on PHP features.” PHP RFC wiki. https://wiki.php.net/rfc/voting. Accessed 2026-11-09. ↩︎
- The PHP Foundation. Home page, sponsor lists. thephp.foundation. https://thephp.foundation/. Accessed 2026-11-09. ↩︎
- The PHP Foundation. “Governance of the PHP Foundation,” section 3.3.2. thephp.foundation. https://thephp.foundation/governance/. Accessed 2026-11-09. ↩︎
- WordPress. “Project Organization.” Core Handbook, Make WordPress Core. Last updated 2026-09-07. https://make.wordpress.org/core/handbook/about/organization/. Accessed 2026-11-09. ↩︎
- WordPress. “WordPress Release Team and Focus Leads.” Core Handbook, Make WordPress Core. https://make.wordpress.org/core/handbook/about/how-the-release-cycle-works/wordpress-release-team-and-focus-leads/. Accessed 2026-11-09. ↩︎
- WordPress. “Project Organization.” Core Handbook, Make WordPress Core. Last updated 2026-09-07. https://make.wordpress.org/core/handbook/about/organization/. Accessed 2026-11-09. ↩︎
- WordPress. “WordPress Release Team and Focus Leads.” Core Handbook, Make WordPress Core. https://make.wordpress.org/core/handbook/about/how-the-release-cycle-works/wordpress-release-team-and-focus-leads/. Accessed 2026-11-09. ↩︎
- The Chromium Authors. “Code Reviews.” chromium/src docs. https://chromium.googlesource.com/chromium/src/+/HEAD/docs/code_reviews.md. Accessed 2026-11-09. ↩︎
- Mozilla. “Module Ownership System.” mozilla.org. https://www.mozilla.org/en-US/about/governance/policies/module-ownership/. Accessed 2026-11-09. ↩︎
- WebKit. “Commit and Review Policy.” webkit.org. https://webkit.org/commit-and-review-policy/. Accessed 2026-11-09. ↩︎
- World Wide Web Consortium. “W3C Process Document,” sections 1, 2.1 and 3.3. 18 August 2025. https://www.w3.org/policies/process/. Accessed 2026-11-09. ↩︎
- World Wide Web Consortium. “Diversity.” w3.org. https://www.w3.org/about/diversity/. Accessed 2026-11-09. ↩︎
- WordPress. “Block Editor Handbook: Development environment.” Developer.WordPress.org. https://developer.wordpress.org/block-editor/getting-started/devenv/. Accessed 2026-11-09. ↩︎
- WordPress. “WordPress Coding Standards for PHP_CodeSniffer,” README. GitHub. https://github.com/WordPress/WordPress-Coding-Standards. Accessed 2026-11-09. ↩︎
- OpenJS Foundation. “Meet Our 2026 OpenJS Foundation Board of Directors.” openjsf.org. https://openjsf.org/blog/meet-our-2026-openjs-foundation-board-of-directors. Accessed 2026-11-09. ↩︎
- PHPCSStandards. “PHP_CodeSniffer,” README. GitHub. https://github.com/PHPCSStandards/PHP_CodeSniffer. Accessed 2026-11-09. ↩︎
- PHPCSStandards. “CONTRIBUTING.md.” PHP_CodeSniffer repository, GitHub, 4.x branch. https://github.com/PHPCSStandards/PHP_CodeSniffer/blob/4.x/.github/CONTRIBUTING.md. Accessed 2026-11-09. ↩︎
- OpenJS Foundation. “Members.” openjsf.org. https://openjsf.org/members. Accessed 2026-11-09. ↩︎
- Open Collective. “PHP_CodeSniffer.” opencollective.com. https://opencollective.com/php_codesniffer. Accessed 2026-11-09. ↩︎
- World Wide Web Consortium. “W3C Process Document,” sections 1, 2.1 and 3.3. 18 August 2025. https://www.w3.org/policies/process/. Accessed 2026-11-09. ↩︎
Leave a Reply