> On Oct 7, 2024, at 7:31 PM, Jim Winstead <j...@trainedmonkey.com> wrote: > > 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.
I am totally with you on this, and I apologize on my part if anything about what I said made people view it as an either-or proposition. Instead, I intended comments were intended to be viewed as "Yes, and..." > On Sun, Oct 6, 2024, at 12:33 PM, Mike Schinkel wrote: >> >> 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. > > 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.) What I was thinking when I spoke of a "gargantuan effort" was if a team were to try to duplicate the functionality of a modern website vs. just maintaining the aging and minimal website that is currently php.net <http://php.net/>. > 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. That rationale is an easy one. 1. First, both PEAR and PECL are package managers. I was proposing a directory. Directories are an order of magnitude easier to manage than a package manager. 2. PECL was an extremely high bar as it was a package needed to be written in C, so we should just ignore that one. 3. PEAR had huge friction because (from what I understand) it required approval from members of the PEAR Group to be included. Let's instead compare to examples that turned out very different from PEAR and PECL, and although are arguable also package managers it is their directory aspect that I am focusing on and that IMO has been a significant reason for their success: - https://packagist.org/ <https://packagist.org/> - https://wordpress.org/plugins/ <https://wordpress.org/plugins/> - https://www.drupal.org/project/project_module <https://www.drupal.org/project/project_module> The reason those three have been far more successful has a large amount to do with the fact that the directory is managed by all the individuals in the community with solutions to showcase and and not a small group of overworked and underpaid individuals, and especially not having gatekeepers who must scan everything and who have subjective approval for inclusion. And ensuring against bad actors have obviously been effectively managed by these other projects. Given all those factors I do not see a strong argument to compare the experience with PECL and PAIR to the idea of php.net <http://php.net/> hosting a directory of 3rd party solutions. > (And I think that "minus any objectively determined bad actors" is > hand-waving away some extremely hard non-technical issues.) While I would admit there may be some hand waving there, but to claim something is "extremely hard" without examples as a justification for not doing it is even more hand-wavy. Care to delineate at least of few of those extremely hard non-technical issues you envision to see if they are indeed extremely hard? >> 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. Maybe, maybe not. But that perspective obscures the point I was trying to make. It is entirely possible that soliciting an RFP for a website that could also help generate revenue would present the community with ideas that nobody here has even considered. One this is for absolutely certain, though. Keeping the website as-is will certainly not generate any additional revenue. For me I would rather bet on the potential for innovation than bet against it. > 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. Maybe. But there is find fault then it is to find a working solution. What I was asking people to consider is "Would we want this?" If the answer is yes, they we can discuss those things you claim to be dubious to see if there are solutions. Again, if we don't look for solution we will absolutely never find any. > 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. No, that is not what it assumes. What it assumes is that people can be rallied around an effort that is aspirational and the outcome can be an order of magnitude better result. Maintaining the existing website is not aspirational. Empowering the community to do so much more with the website could be aspirational. So all I was asking was, "Is that a future people would like to see, or not?" If no, then never mind. But if yes, why can we not explore how to make it happen? -Mike
