Reference Appendices

The PHP Foundation And Ecosystem Stewardship

The PHP Foundation is a nonprofit initiative that funds people and work supporting the PHP language. Its primary technical activity is contracting core developers to maintain and advance PHP.

It is one part of a wider ecosystem. The Foundation, the PHP project, PHP internals, PHP-FIG, framework teams, package maintainers, vendors, and user communities have related but different responsibilities.

Why A Foundation Is Useful

A language runtime requires sustained work that is not always visible in application code:

  • fixing bugs and security issues
  • maintaining the engine and standard extensions
  • reviewing patches
  • improving tests and continuous integration
  • supporting new platforms and toolchains
  • reducing technical debt
  • writing and reviewing language proposals
  • documenting and communicating core work

Volunteer contribution remains important, but predictable funding lets developers reserve substantial time for maintenance and long-term projects.

The Foundation collects sponsorship and donations, selects and contracts developers, and reports on funded activity. It operates through Open Source Collective as its fiscal host and uses the Open Collective platform for financial transparency.

Funding Does Not Decide Language Design

The PHP Foundation explicitly separates its work from PHP's RFC process. Language decisions remain with the PHP internals community under the project's proposal and voting rules.

A Foundation-funded developer may author an RFC, implement a proposal, review code, and vote if eligible. Their funding does not make the RFC accepted. Sponsors and the Foundation board do not replace the recorded internals decision.

This separation protects a useful distinction:

  • the Foundation decides how to steward its money and contracts
  • PHP internals decides language proposals through the PHP project's process
  • implementation is reviewed and merged through PHP's development workflow

Funding capacity and technical governance influence each other in practice, but they are not the same authority.

PHP Internals And The PHP Project

PHP internals is the development community around the PHP runtime and its mailing-list, proposal, review, and voting processes. Contributors maintain source code, tests, build systems, extensions, documentation, and release branches.

No single company owns PHP language design. Decisions emerge through project policies, maintainership, technical review, and eligible voting rather than through a framework vendor or application company.

The official PHP website, source repositories, manuals, release announcements, and RFC records are the primary places to verify language behavior and support status.

PHP-FIG Has A Different Scope

The PHP Framework Interop Group publishes interoperability standards and recommendations such as PSRs and PERs. These can define shared interfaces or conventions used by frameworks and packages.

PHP-FIG does not vote new syntax into the PHP language, publish PHP runtime releases, or direct Foundation contracts. A PSR can become widely adopted without becoming a built-in language feature.

For example, a common logging interface belongs to ecosystem interoperability. Adding syntax or changing engine behavior belongs to the PHP project's language process.

Frameworks, Packages, And Vendors

Laravel, Symfony, Drupal, WordPress, Composer packages, IDE vendors, hosting providers, and other projects have their own maintainers and release decisions.

They may:

  • sponsor the Foundation
  • employ PHP contributors
  • participate in PHP-FIG
  • propose or implement RFCs
  • build tools on top of PHP
  • set their own support and compatibility policies

They still do not become interchangeable with the PHP project. A Symfony deprecation is not automatically a PHP deprecation, and a Laravel release is not a PHP runtime release.

Reading Announcements Critically

When an announcement says that an organization is "supporting PHP," ask what kind of support it means:

  • donating money
  • contracting a core developer
  • contributing source or documentation
  • maintaining infrastructure
  • publishing a package or framework
  • proposing a language change
  • providing hosting or security work

Then verify the responsible body's record. Funding appears in Foundation reporting; RFC decisions appear in PHP's proposal and vote records; standards appear on PHP-FIG; framework behavior appears in that framework's documentation and release notes.

How Application Developers Participate

Application developers can support the ecosystem without becoming engine experts:

  • report reproducible bugs responsibly
  • test release candidates against real applications
  • improve documentation
  • contribute to packages and frameworks
  • provide useful RFC implementation feedback
  • sponsor maintainers or the Foundation
  • avoid demanding unpaid emergency work from volunteers
  • cite primary sources when explaining changes

Testing release candidates is especially useful because it exposes compatibility problems before a final release reaches production.

Stewardship Includes Constraints

Funding does not produce unlimited capacity. Core developers still prioritize security, compatibility, maintenance, releases, reviews, and difficult technical work. A visible feature may compete with less visible work needed to keep the runtime reliable.

Good stewardship therefore includes transparent priorities, review, sustainable workloads, and accepting that some proposals should wait or be declined.

What To Remember

The PHP Foundation funds and organizes resources for PHP development, but PHP language RFC decisions remain with PHP internals. PHP-FIG handles interoperability standards, while frameworks, packages, and vendors own their own products. Identify the responsible body before treating an announcement as authoritative.

Before moving on, make sure you can explain why a company can sponsor PHP development without gaining the right to declare a language proposal accepted.

Practice

Task: Map Ecosystem Responsibilities
  1. Contract a developer to spend paid time maintaining PHP core.
  2. Vote on whether proposed PHP syntax is accepted.
  3. Publish an interoperability interface for logging libraries.
  4. Decide when a new Symfony major version is released.
  5. Merge an accepted engine change after technical review.
  6. Report how donated funds were spent.
  7. Decide whether a Laravel feature is deprecated.
  8. Publish the official PHP migration guide for a runtime release.

For activities 1 and 2, explain why the same funded developer may participate in both without making the two governance processes identical.

Show solution

Responsibility Map

  1. PHP Foundation: it selects and contracts developers using its funding and governance processes.
  2. PHP internals/the PHP project: eligible contributors vote under the RFC policy.
  3. PHP-FIG: it develops and publishes ecosystem interoperability standards such as PSRs.
  4. Symfony project: Symfony's maintainers own its release policy and schedule.
  5. PHP internals/the PHP project: PHP source maintainers review and merge runtime changes through the project's development process.
  6. PHP Foundation: it reports on the money and activity it stewards, including through its fiscal and transparency arrangements.
  7. Laravel project: Laravel's maintainers decide their framework's feature lifecycle.
  8. PHP internals/the PHP project: official runtime documentation and migration guidance belong to the PHP project.

A Foundation contract funds a person's time; it does not transfer language authority to the Foundation. The funded developer can separately participate in internals discussion, implementation, review, and eligible voting under the same rules as that PHP process. The RFC result still depends on the recorded project decision, not on who paid for implementation time.