Re: [RFC] Policy on 3rd party code

From: Date: Sun, 06 Oct 2024 13:00:20 +0000
Subject: Re: [RFC] Policy on 3rd party code
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-125757@lists.php.net to get a copy of this message
On Sat, Oct 5, 2024, at 11:27 PM, Stephen Reay wrote: >> A number of people are concerned that if we use any of the "Big Names", it would >> be interpreted as an endorsement of that project. Eg, if we rebuilt the main website using Laravel, >> the Symfony folks would feel slighted. If we used Symfony, the Laravel folks would get rather >> cross. If we used Yii, the Slim folks would get upset. If we used Drupal, we'd get constant >> "well why not Wordpress?" questions. Etc. >> >> While I feel that concern is sometimes over-blown, I do believe it is valid. Notably, the >> "big name communities" tend to also be complete, integrated solutions, and those also tend >> to be where there's more active competition. Eg, there's only one meaningful Yaml >> implementation the market, and two UUID libraries worth mentioning. But there's literally >> dozens of "frameworks" or "CMSes" to get mad at us. >> >> So banning "full" frameworks is my attempt at steering clear of the appearance of >> that kind of favoritism. Showing favoritism for Composer or Xdebug is, well, there's no >> competition to complain. PHPUnit is technically not the only testing framework on the market, but >> it has north of 90% share (and is used internally by some of the few others). But showing >> favoritism between Drupal, Wordpress, TYPO3, Concrete5, and Joomla gets a lot dicier. >> >> A full framework also makes maintenance potentially more challenging, as we it's a >> much larger external moving target than a UUID library that we could easily fork in a worst case >> scenario. >> >> So... I don't really have a solid, clear definition of what constitutes a "full >> framework", because in the market, there isn't one. I'm sure someone could make a >> compelling argument that Slim isn't a full framework, for instance, although I don't think >> I'd agree with it. >> >> It is inherently squishy, which is why these are intended as heuristics, not strict rules, >> and when it's unclear we can bring it to a vote via RFC, case by case. >> >> I'm open to better ways to define what "full" means here if anyone has >> suggestions. >> >> --Larry Garfield >> > > Hi Larry, > > Right I understand the motivation, it's just the phrasing that I think > needs to be clarified. > > From what you've said (which is kind of what I imagined you probably > meant) I think it just needs to be clarified that the "full > application" exclusion is about *web* applications, and doesn't > applying to command line tooling/utilities. > > Cheers > > Stephen Valid point. I've added another definition, and used it throughout: Libraries refers to existing third party code packages or tools, either C extensions or PHP code, maintained by someone other than the PHP Internals team. It also includes command line utilities used primarily by a developer. It may also refer to non-profit PHP ecosystem organizations, such as the PHP Foundation or PHP-FIG. Web Application refers to a “full” web framework that provides end-to-end web application capabilities, or an installable complete application. It does not refer to command line utilities used primarily by developers building applications. (Libraries are OK, Web Applications are mostly not, except in marketing where we can mention them as long as we don't play favorites.) --Larry Garfield

« previous php.internals (#125757) next »