I have opened the vote on the proposed third-paty-code policy clarification.
https://wiki.php.net/rfc/third-party-code
The vote will end on 22 November.
--
Larry Garfield
larry@garfieldtech.com
On Fri, Nov 8, 2024 at 11:35 PM Larry Garfield larry@garfieldtech.com
wrote:
I have opened the vote on the proposed third-paty-code policy
clarification.https://wiki.php.net/rfc/third-party-code
The vote will end on 22 November.
--
Larry Garfield
larry@garfieldtech.com
Hi Larry,
I want to let you know the reason why I'm voting no. Sorry for not bringing
this up during the discussion phase but I honestly haven't seen it
mentioned.
Throughout the policy text there are three mentions to:
"Any library or PSR published by the PHP-FIG"
Given that the spirit of the policy is to avoid endorsements, it seems out
of place to give an external organization special grants. The rules for
inclusion and exclusion are and should remain objective and equal for all
libraries.
Regards,
Pedro
I also voted against because I think it's silly to create these arbitrary rules on the various frameworks. "Not playing favorites" is literally as easy as saying "The people who volunteered their time to build X did so using Y because that's what they knew, it doesn't mean the PHP project favors them over another option".
No one serious writes PHP code without a framework today, and the fact we go so far to keeping PHP "stand alone" I think hurts the project more than it helps because it gives a casual observer the idea that PHP development is just the PHP language, which simply is never the case for a serious project.
I have opened the vote on the proposed third-paty-code policy clarification.
https://wiki.php.net/rfc/third-party-code
The vote will end on 22 November.Larry Garfield
larry@garfieldtech.com (mailto:larry@garfieldtech.com)Hi Larry,
I want to let you know the reason why I'm voting no. Sorry for not bringing this up during the discussion phase but I honestly haven't seen it mentioned.
Throughout the policy text there are three mentions to:
"Any library or PSR published by the PHP-FIG"Given that the spirit of the policy is to avoid endorsements, it seems out of place to give an external organization special grants. The rules for inclusion and exclusion are and should remain objective and equal for all libraries.
Regards,
Pedro
I also voted against because I think it's silly to create these arbitrary rules on the various frameworks. "Not playing favorites" is literally as easy as saying "The people who volunteered their time to build X did so using Y because that's what they knew, it doesn't mean the PHP project favors them over another option".
No one serious writes PHP code without a framework today, and the fact we go so far to keeping PHP "stand alone" I think hurts the project more than it helps because it gives a casual observer the idea that PHP development is just the PHP language, which simply is never the case for a serious project.
This is counter productive, because the current rule is: don't use anything, or mention anything, third party.
And we're in 2024 now and nobody writes PHP code without Composer. Without this change, we can't use any composer available library for PHP.NET sites, nor even mention it in the documentation.
That's bonkers.
Also, requiring the PHP properties not never use anything third party makes everything so much more of a pain for us.
I strongly recommend you change your opinion on this.
cheers
Derick
And we're in 2024 now and nobody writes PHP code without Composer. Without this change, we can't use any composer available library for PHP.NET sites, nor even mention it in the documentation.
That's bonkers.
100% agree with you.
This is counter productive, because the current rule is: don't use anything, or mention anything, third party.
Per the very first line of the RFC...
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.
I guess my point here is when I read this RFC it moves the needle from "unwritten, vague, and inconsistently-applied" to a much more firm "don't use them, don't talk about them" on frameworks -- which I think is a mistake. It also seems entirely haphazard in the "what's allowed" vs. "what's not". in terms of packages based on Larry's (probably correct) opinion of what's mainstream as a solution for particular problems.. All of this is wildly inconsistent is my point. Also what happens if I decide to use a composer package component that's really a part of Laravel or Symfony or ....? Is that allowed or not?
I wouldn't have even blinked on a "yes" vote here if the RFC was to allow composer.. it's this other half-baked stuff that I am balking at... I'd very much like to see this RFC stripped of those bits if possible.
John
And we're in 2024 now and nobody writes PHP code without Composer. Without this change, we can't use any composer available library for PHP.NET sites, nor even mention it in the documentation.
That's bonkers.100% agree with you.
This is counter productive, because the current rule is: don't use anything, or mention anything, third party.
Per the very first line of the RFC...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.
I guess my point here is when I read this RFC it moves the needle from
"unwritten, vague, and inconsistently-applied" to a much more firm
"don't use them, don't talk about them" on frameworks -- which I think
is a mistake. It also seems entirely haphazard in the "what's allowed"
vs. "what's not". in terms of packages based on Larry's (probably
correct) opinion of what's mainstream as a solution for particular
problems.. All of this is wildly inconsistent is my point. Also what
happens if I decide to use a composer package component that's really a
part of Laravel or Symfony or ....? Is that allowed or not?I wouldn't have even blinked on a "yes" vote here if the RFC was to
allow composer.. it's this other half-baked stuff that I am balking
at... I'd very much like to see this RFC stripped of those bits if
possible.John
Hi John.
First off, the obligatory "it was open for discussion for a month, and now you mention this?"
Second, I'm not sure I really understand the objection here. This RFC shifts the policy from
"You cannot use or mention anything 3rd party at all, especially a framework, except for where you asked forgiveness and not permission already"
to
"Here's guidelines for when you can use, reference, or use for marketing (3 different things) third party libraries without asking first, and here's a mechanism for if you want to ask for specific exceptions."
So if, hypothetically, someone wanted to rebuild bugs.php.net using Symfony (note: Please don't), that wouldn't be allowed by default... but they could post an RFC to ask for an exception. (Whether it would pass is a different question.) If the issue is just a single component... those are fine, and there's even a few Symfony components already listed as approved for use (because they're already in use). So if someone wanted to use Symfony/Yaml on the docs site for some reason, they could just do it.
I guess my point here is when I read this RFC it moves the needle from
"unwritten, vague, and inconsistently-applied" to a much more firm
"don't use them, don't talk about them" on frameworks
This is... not true.
For using, yes, full frameworks are not allowed for the reasons stated. Components are fine, though, and if someone wanted to RFC an exception for Symfony-based bugs.php.net, they can try. That's more permissive than the current policy.
For documentation... it's no change from the current status quo. If your concern is "zOMG, why can't we just tell people in the docs to use Symfony?", it's because someone else will immediately respond with "zOMG, why can't we just tell people to use Laravel instead?", and in a year or so someone will probably say "zOMG why can't we just tell people to use Tempest?" And then we'd have to argue if CodeIgnighter is something we want to even acknowledge exists. Full frameworks are a very, very active market, and I agree that we should try to avoid putting our thumb on the scales more than is necessary. Though again, there's an RFC process for exceptions.
For marketing material, I quote:
"The library MAY be a Web Application, provided its mention clearly does not specifically endorse the Application. If many options exist in a space that bears mention, the most common should be given equal exposure."
So if, for example, we wanted to put up a "Yay, PHP 8.4" page that says "Laravel, Symfony, and Slim already support it!", that is explicitly allowed, as long as we don't play favorites. That's contrary to the status quo, where even mentioning that they exist is disallowed.
The guidelines are not "haphazard". They are carefully written to strike a balance, which is a different balance for different use cases. They were adjusted based on feedback from several people, though not as many as I would have liked. They are subject to adjustment over time via RFC, which is something the old policy as mum about (as it wasn't actually written down), so if you want to file an RFC to widen them a bit further, you can do that and let the voters do what they will.
So really, contrary to what you're saying, this RFC improves precisely the situation you're talking about in every way. Perhaps not as much as you would like, but it still moves the needle closer to it. I really don't have the stomach at the moment for litigating the "should we just go ahead and endorse some framework" question (I'm on team-no anyway), so I deliberately avoided that question when the main focus is to, as stated, let us mention Composer, PHPUnit, and other staples that have nowhere near the healthy competition that frameworks have.
--Larry Garfield
First off, the obligatory "it was open for discussion for a month, and now you mention this?"
I apologize for that, wasn't intentional. Unfortunately a whole pile of personal matters landed on my head between ... let's say October and November 6th that kept me from focusing on internals. As might be expected, the vote refocused my attention.
I think this is worth discussing a bit more below,...
TL;DR; I will at a minimum abstain from voting on this rather than vote "no" as my intent isn't to derail progress here.
For using, yes, full frameworks are not allowed for the reasons stated. Components are fine, though, and if someone wanted to RFC an exception for Symfony-based bugs.php.net, they can try. That's more permissive than the current policy.
For documentation... it's no change from the current status quo. If your concern is "zOMG, why can't we just tell people in the docs to use Symfony?", it's because someone else will immediately respond with "zOMG, why can't we just tell people to use Laravel instead?", and in a year or so someone will probably say "zOMG why can't we just tell people to use Tempest?" And then we'd have to argue if CodeIgnighter is something we want to even acknowledge exists. Full frameworks are a very, very active market, and I agree that we should try to avoid putting our thumb on the scales more than is necessary. Though again, there's an RFC process for exceptions.
Tangent, but FWIW I think this is something the PHP Foundation could help take on a bit, by creating a certification process a given framework can participate in. Any framework could apply, and all would be measured by the same reasonable standards.. then at least the PHP project could say "these frameworks have met this certification bar" which would be very helpful to people evaluating PHP as an option. I would gladly participate in drafting a rubric for community review if there was interest in that.
So really, contrary to what you're saying, this RFC improves precisely the situation you're talking about in every way. Perhaps not as much as you would like, but it still moves the needle closer to it. I really don't have the stomach at the moment for litigating the "should we just go ahead and endorse some framework" question (I'm on team-no anyway), so I deliberately avoided that question when the main focus is to, as stated, let us mention Composer, PHPUnit, and other staples that have nowhere near the healthy competition that frameworks have.
As I eluded to above, I am certainly not suggesting we endorse a single framework. I guess at the end of the day I've got a number of issues with the specifics of the language around how decisions are made in this doc, but I will concede that at least there is a document here that can be refined which is indeed a step forward. If you're interested some the concerns I have are (I'm focused on the maintainer bits below but I think they also largely apply to the marketing criteria as well):
I don't think the "version 1.0" requirement is a good one, only because I strongly suspect it wouldn't take me very long to find a very reasonable library that for whatever reason is 0.8 or something... so now it can't be used, unless there is an RFC?
I don't understand what the point of the "Explicitly approved" list is, if the point is any and all libraries which meet the acceptance criteria can be used without asking for permission then they are by default approved, right?
Phrases like the library is a "de facto standard" is a really arbitrary, subjective criteria, ripe for misinterpretation or conflicting interpretation. As language it makes sense for the far edge cases and not much else IMO.
I'm not suggesting that these alternatives be adopted right now... but off the top of my head I would offer these suggestions:
The library should be focused on a specific need and provides clear, specific functionality needed by the PHP maintainers that would otherwise be unreasonable to implement and maintain themselves.
The library should have an active developer community of at least 2 developers, and the library should have an currently active development history of at least 1 year.
The library is provided under an Approved License
On the marketing side I think we've got a long way to go, but that can be a discussion for later.. for now I'll just say that I have a lot of the same issues as the maintainer side regarding versioning / subjectiveness, etc. In my mind the marketing guidelines are way more important to the project than the maintainer ones: We can always resolve conflicts regarding this stuff and maintainers internally, but if we miss opportunities to tell potential users how PHP can solve their problem effectively we may never see them again.
Anyway, like I said I'll abstain as my intention isn't to derail progress but I think this needs a lot more work as a set of guidelines. I'd be happy to help out with a second stab that if there is interest -- probably best off-list for a first draft?
Coogle
First off, the obligatory "it was open for discussion for a month, and now you mention this?"
I apologize for that, wasn't intentional. Unfortunately a whole pile of
personal matters landed on my head between ... let's say October and
November 6th that kept me from focusing on internals. As might be
expected, the vote refocused my attention.
Quite...
I think this is worth discussing a bit more below,...
TL;DR; I will at a minimum abstain from voting on this rather than vote
"no" as my intent isn't to derail progress here.
Thank you. I appreciate your openness here.
As I eluded to above, I am certainly not suggesting we endorse a single
framework. I guess at the end of the day I've got a number of issues
with the specifics of the language around how decisions are made in
this doc, but I will concede that at least there is a document here
that can be refined which is indeed a step forward. If you're
interested some the concerns I have are (I'm focused on the maintainer
bits below but I think they also largely apply to the marketing
criteria as well):• I don't think the "version 1.0" requirement is a good one, only
because I strongly suspect it wouldn't take me very long to find a very
reasonable library that for whatever reason is 0.8 or something... so
now it can't be used, unless there is an RFC?
See, I find the 1.0 requirement far less arbitrary than the minimum maintainers requirement. Assuming the library is following semver (most do, mostly), having a 1.0 gives us a reasonable expectation that the API won't change out from under us in a minor release. In a 0.x, that is by definition a risk, making it not necessarily stable enough to trust. (There are indeed some libraries that stay in 0.x land forever, despite being well maintained. These maintainers are Doing It Wrong(tm) and need to stop.)
• I don't understand what the point of the "Explicitly approved" list
is, if the point is any and all libraries which meet the acceptance
criteria can be used without asking for permission then they are by
default approved, right?
The criteria are by necessity squishy. They're guidelines and heuristics, but the PHP ecosystem is far too complex for a series of yes/no binaries to make sense in most cases. And different people will no doubt interpret different cases differently.
So as a hypothetical, suppose someone tries to mention ramsey/uuid on a marketing page. Another person objects, saying that it isn't important enough of a library to the ecosystem as a whole to warrant a mention. We resolve that conflict by having an RFC to add ramsey/uuid to the "this is definitely OK according to these criteria" list. If it passes, then we've resolved it: Mentioning ramsey/uuid is now explicitly OK on marketing pages, and if someone objects in the future we can say "look, we already voted on it and decided it was OK. Stop fussing."
• The library should have an active developer community of at least 2
developers, and the library should have an currently active development
history of at least 1 year.
I see the intent here, to ensure a library isn't going to be abandoned. However, the vast majority of libraries are single-developer. Even those that have contributions from others are realistically one-person-projects. Looking at ramsey/uuid again (sorry Ben, don't mean to pick on you), ramsey himself has 705 commits. Dependabot is #2. The second human is jmauerhan at 35, so around 5% ish as many, all before 2020. Does that count as an "active developer community of at least 2"? I'd say no. But that library is a staple of the ecosystem and has been for over a decade. It's not going anywhere. It's probably more reliably maintained than many 2-3 person projects that never really got off the ground. So even if we could quantify what counts as "2 active developers", it's still a fairly poor signal of reliability.
--Larry Garfield
I have opened the vote on the proposed third-paty-code policy clarification.
https://wiki.php.net/rfc/third-party-code
The vote will end on 22 November.
The vote is now closed. The final tally is 24 Yes, 1 No, or 96%. It has passed.
Thank you everyone for your participation. We'll get the PR merged shortly. Those working on docs or the website or infra, the new policy is now in effect so proceed accordingly.
--Larry Garfield