On Sun, Oct 6, 2024, at 12:33 PM, Mike Schinkel wrote: >> On Oct 2, 2024, at 3:36 PM, Andreas Heigl <andr...@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. > > IOW, given that all the current infrastructure really supports are > static pages — without a gargantuan effort to write and maintain a > custom framework from scratch by unpaid volunteers — the resultant > website can only realistically be static pages. > > Frankly, I envision the PHP website could be so much more if developing > and maintaining it were not a gargantuan effort. Like WordPress' plugin > and theme repositories, PHP could have a database of *all* third party > offerings — minus any objectively determined bad actors — and showcase > to the world all that the extended PHP community has to offer.
Developing and maintaining the PHP websites is far from a gargantuan effort, 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 work 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 centralized 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 PEAR 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, > all to fund more core development? I have a hard time imagining that this would ever be more than a rounding error compared to the sponsorships and individual contributions that the PHP Foundation currently relies on. >> On Oct 5, 2024, at 10:25 PM, Larry Garfield <la...@garfieldtech.com> 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. > > OR, we could change the current model and consider and another approach. > > Instead of maintaining a website based on 1980s[1] technology which can > give newer developers who are interested in modern developer tools the > opinion that PHP is not for them, PHP could move to a model for its > website where it embraces "Big names" and does so on merit. > > What do I mean by "merit?" > > Consider the potential of adopting a new approach where PHP puts out a > call for RFPs to any and all who are interested in submitting a > proposal to build and maintain a website for PHP for three (3) years at > a time. > > Interested stakeholders could join the PHP internal infrastructure > mailing list and brainstormwhat is wanted tor the website and then > prepare an RFP to put out for bid. Nominally we would do so without > paying for the service — their benefit would be getting prominently > featured as the developer and maintainer of the website — but we could > ask organizations in the community like JetBrains to pitch into a pot > that could go to the winner of the bid, if we want to. > > Then we take proposals from the projects themselves, any agency, and/or > any other organization that want to propose and we have the members of > the PHP internal infrastructure mailing list create a short list of the > proposers based on criteria such as if we think they will be able to > maintain doing so for a 3 years as well as what they actually propose, > and finally have all voting members would vote on it. > > Why would we do it his way? Because this is how web development for > organizations usually gets done today. I was involved in a agency > project back in probably 2017 to build the website for the Agile > Alliance (www.agilealliance.org). Certainly they had community members > that could have built it but they chose instead to have it done by > deciding what they wanted and they putting out an RFP. The result was > they actually got the features they wanted in the near term instead of > looking back 10 years or more thinking "When we can get around to it we > can implement...whatever." > > We would want to start this process well in advance to ensure enough > people know about it and how time to submit a proposal — e.g. 18 > months? — and that the RFP process for 3 years later would start a year > after the site is launched. I can imagine that a lot of PHP-focused > YouTubers would be all over promoting this. > > Then the unpaid volunteers here need not be as highly skilled nor as > burdened to maintain all the technical infrastructure and can instead > focus on maintaining the actual **content**. > > The concern for bias also gets thrown out the door because it is based > more on merit, and the decision is widely distributed across all the > voting stakeholders in PHP in a relatively transparent process. We > could even say that any framework used for the last 3 years cannot be > awarded the winning bid for the next 3 years to give more "big names" > as shot at being the framework chosen. > > There are tons of details that would need to be worked out, but as this > is a wildly different approach from any the community has taken in the > past — although as I said this is the common approach organizations > take today to build and maintain websites — if it gets shot down by too > many then no need to discuss the details any further. Frankly, I find your proposal dubious because it assumes that there is some 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, merit-based selection by a vote of the voting members. It assumes that somehow assembling all of the organizational infrastructure to enable outsourcing the technical infrastructure is solving the easy part of the problem. It assumes that there is some need for non-static-pages with content that will somehow come pouring forth out of less-highly-skilled unpaid volunteers if only the technical infrastructure was taken care of for them. What is currently blocking content that at least one unpaid volunteer* wants to contribute in a way that leverages the existing technical infrastructure 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.
