Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125766
Feedback-ID: ia2404087:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 07 Oct 2024 16:31:55 -0700
To: internals@lists.php.net
Message-ID: <60dd81ad-7232-48a4-b419-48066bf15197@app.fastmail.com>
In-Reply-To: <1E3250E0-17C7-4BCD-9A5F-7F2FED48686D@newclarity.net>
References: <92b537ac-62f4-435c-bf55-07223cfa1915@app.fastmail.com>
 <FB303710-75A5-447E-9A6C-DCF4FD956542@koalephant.com>
 <cdbc3c06-7369-49d1-a794-06568cea4be7@app.fastmail.com>
 <1E3250E0-17C7-4BCD-9A5F-7F2FED48686D@newclarity.net>
Subject: Re: [PHP-DEV] [RFC] Policy on 3rd party code
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: jimw@trainedmonkey.com ("Jim Winstead")

On Sun, Oct 6, 2024, at 12:33 PM, Mike Schinkel wrote:
>> On Oct 2, 2024, at 3:36 PM, Andreas Heigl <andreas@heigl.org> wrote:
>> IMO the PHP website is more or less a bunch of static pages. There is=
 not really much interaction necessary. So having a framework might not =
necessarily be The Thing.
>
> You may be confusing cause with effect. =20
>
> IOW, given that all the current infrastructure really supports are=20
> static pages =E2=80=94 without a gargantuan effort to write and mainta=
in a=20
> custom framework from scratch by unpaid volunteers =E2=80=94 the resul=
tant=20
> website can only realistically be static pages.=20
>
> Frankly, I envision the PHP website could be so much more if developin=
g=20
> and maintaining it were not a gargantuan effort. Like WordPress' plugi=
n=20
> and theme repositories, PHP could have a database of *all* third party=20
> offerings =E2=80=94 minus any objectively determined bad actors =E2=80=
=94 and showcase=20
> to the world all that the extended PHP community has to offer.

Developing and maintaining the PHP websites is far from a gargantuan eff=
ort, as evidenced by how it is currently (and has long been) maintained =
on a very ad-hoc basis by a very small number of volunteers with some wo=
rk that is now sponsored by the PHP Foundation. (I believe that amounts =
to maybe the equivalent of one full-time person.)

I think a proposal for the PHP project taking on something like centrali=
zed databases of "all" third-party packages also needs to come up with a=
 very good rationale as to why that will turn out differently than how P=
EAR and PECL did.

(And I think that "minus any objectively determined bad actors" is hand-=
waving away some extremely hard non-technical issues.)

> Or, imagine a store where PHP could sell T-Shirts, plushies and more,=20
> all to fund more core development?

I have a hard time imagining that this would ever be more than a roundin=
g error compared to the sponsorships and individual contributions that t=
he PHP Foundation currently relies on.

>> On Oct 5, 2024, at 10:25 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>>=20
>> 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 sl=
ighted.  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.
>
> OR, we could change the current model and consider and another approac=
h.
>
> Instead of maintaining a website based on 1980s[1] technology which ca=
n=20
> give newer developers who are interested in modern developer tools the=20
> opinion that PHP is not for them, PHP could move to a model for its=20
> website where it embraces "Big names" and does so on merit.
>
> What do I mean by "merit?" =20
>
> Consider the potential of adopting a new approach where PHP puts out a=20
> call for RFPs to any and all who are interested in submitting a=20
> proposal to build and maintain a website for PHP for three (3) years a=
t=20
> a time.=20
>
> Interested stakeholders could join the PHP internal infrastructure=20
> mailing list and brainstormwhat is wanted tor the website and then=20
> prepare an RFP to put out for bid.  Nominally we would do so without=20
> paying for the service =E2=80=94 their benefit would be getting promin=
ently=20
> featured as the developer and maintainer of the website =E2=80=94 but =
we could=20
> ask organizations in the community like JetBrains to pitch into a pot=20
> that could go to the winner of the bid, if we want to.
>
> Then we take proposals from the projects themselves, any agency, and/o=
r=20
> any other organization that want to propose and we have the members of=20
> the PHP internal infrastructure mailing list create a short list of th=
e=20
> proposers based on criteria such as if we think they will be able to=20
> maintain doing so for a 3 years as well as what they actually propose,=20
> and finally have all voting members would vote on it.
>
> Why would we do it his way?  Because this is how web development for=20
> organizations usually gets done today. I was involved in a agency=20
> project back in probably 2017 to build the website for the Agile=20
> Alliance (www.agilealliance.org). Certainly they had community members=20
> that could have built it but they chose instead to have it done by=20
> deciding what they wanted and they putting out an RFP. The result was=20
> they actually got the features they wanted in the near term instead of=20
> looking back 10 years or more thinking "When we can get around to it w=
e=20
> can implement...whatever."
>
> We would want to start this process well in advance to ensure enough=20
> people know about it and how time to submit a proposal =E2=80=94 e.g. =
18=20
> months? =E2=80=94 and that the RFP process for 3 years later would sta=
rt a year=20
> after the site is launched.  I can imagine that a lot of PHP-focused=20
> YouTubers would be all over promoting this.
>
> Then the unpaid volunteers here need not be as highly skilled nor as=20
> burdened to maintain all the technical infrastructure and can instead=20
> focus on maintaining the actual **content**.=20
>
> The concern for bias also gets thrown out the door because it is based=20
> more on merit, and the decision is widely distributed across all the=20
> voting stakeholders in PHP in a relatively transparent process.  We=20
> could even say that any framework used for the last 3 years cannot be=20
> awarded the winning bid for the next 3 years to give more "big names"=20
> as shot at being the framework chosen.
>
> There are tons of details that would need to be worked out, but as thi=
s=20
> is a wildly different approach from any the community has taken in the=20
> past =E2=80=94 although as I said this is the common approach organiza=
tions=20
> take today to build and maintain websites =E2=80=94 if it gets shot do=
wn by too=20
> many then no need to discuss the details any further.

Frankly, I find your proposal dubious because it assumes that there is s=
ome body of "interested stakeholders"  who are going to be able to come =
to an agreement on an RFP that can then be used to enable a unbiased, me=
rit-based selection by a vote of the voting members.

It assumes that somehow assembling all of the organizational infrastruct=
ure to enable outsourcing the technical infrastructure is solving the ea=
sy part of the problem.

It assumes that there is some need for non-static-pages with content tha=
t will somehow come pouring forth out of less-highly-skilled unpaid volu=
nteers if only the technical infrastructure was taken care of for them.

What is currently blocking content that at least one unpaid volunteer* w=
ants to contribute in a way that leverages the existing technical infras=
tructure is that there is vague, unwritten policy that we don't mention =
third-party tools in the PHP documentation, except for all of the third-=
party tools that we already mention in the PHP documentation.

Jim

* It's me, I'm the problem.