PHP RFC: Policy on 3rd party code
- Version: 0.9
- Date: 2024-10-02
- Author: Larry Garfield (larry@garfieldtech.com)
- Status: Approved
- First Published at: http://wiki.php.net/rfc/third-party-code
Introduction
The PHP project has had a long-standing but unwritten, vague, and inconsistently-applied proscription against mentioning or using third-party PHP projects, on the grounds that it implies some sort of endorsement over other third-party projects. While the desire to avoid endorsing a particular competing project is reasonable, it many cases it is actively harmful to the PHP project, its documentation, and the PHP ecosystem. “PHP” is not simply the php-src repository, and PHP.net is the home page of the PHP ecosystem, not of the php-src repository, whether we approve of that evolution or not.
This RFC proposes an updated heuristic for when and how third party code may be used or referenced, and a resolution process in case of conflict.
Proposal
The specific policy to adopt is documented precisely in this Pull Request: https://github.com/php/policies/pull/10
In the interest of avoiding confusion by having multiple versions of it, this RFC will not repeat what is listed there.
Discussion
This section is non-normative. It is a discussion of how this RFC author feels the above criteria would apply to various packages, as a way to demonstrate the expected thought process.
- Composer - It's 2024. Composer is the sole project in its market, and is used by the overwhelming majority of the PHP ecosystem. It is the only way to access the vast majority of the PHP ecosystem. We should use it, we should document it, we should promote it.
- Symfony/Yaml - I am not aware of any other Yaml library in widespread use. This is the de facto standard way to parse YAML in PHP, and has been for years. It would be fine for PHP tooling to make use of it. However, whether or not it is of broad enough interest to be mentioned in the documentation is debatable. I would likely lean no. It may make sense in marketing, potentially.
- Ramsey/uuid - This has long been a staple of UUID handling in PHP. It would be fine for tooling to use. More recently, Symfony/UUID has also come along, and though less used is still stable. If the documentation were to mention UUID handling, it would be prudent to list both as options. However, it is debatable if UUID handling is of broad enough interest for documentation. It may make sense in marketing.
- Symfony, Laravel, Slim, Yii,WordPress, Drupal, TYPO3, etc. - While Laravel and Symfony are the market leaders in PHP frameworks, and WordPress dominates the CMS-oid market, it is a highly dynamic market, with literally dozens of players that have reasonable use. That makes listing them in the documentation without “playing favorites” essentially impossible, and therefore none should be listed by name. They should also not be used directly to build any PHP tooling, again to avoid the appearance of endorsement. However, it may make sense to list several of them in passing in marketing material, explicitly noting that they are just some among many options.
- Serializers - This is another market with many viable players of various sizes, so we should not “endorse” any in particular via the documentation. It may or may not make sense for marketing material, but definitely not documentation. However, any of the major supported ones are fair game for tooling to leverage as appropriate.
- PHPStan, Psalm - These are, to my knowledge, the only serious players in the static analysis space that meet the above criteria. It's entirely reasonable, and encouraged, for tooling to make use of them. We can also document both under the heading of “static analysis tools, they're a good idea”, without saying people should use one instead of the other. This would be fair game for both documentation and marketing material.
Open Questions
- It likely would not come up, but are we OK with using AGPL code in PHP tooling? It's not like any of our code is inaccessible.
Proposed Voting Choices
Simple 2/3 majority vote.