# [RFC] php-community: a faster-moving, community-driven PHP.

- Thread: https://externals.io/message/130461
- Original archive: https://news-web.php.net/php.internals/130461
- Started by Alex \"Pierstoval\" Rock on 2026-03-26T16:52:53+00:00
- Messages: 1
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #130461 — Alex \"Pierstoval\" Rock — 2026-03-26T16:52:53+00:00

URL: https://externals.io/message/130461#130461

> You cannot convince companies who are actively looking for 
alternatives to
 > PHP due to the lack of core, modern features like async, generics to 
invest
 > in PHP, so that maybe (more likely no than yes, as proven) in the future
 > internals may accept RFCs (financed by the PHPF or not), bringing 
async and
 > generics into PHP.

You might be mixing things a little bit here: companies that use PHP 
must be convinced that donating to the PHPF will help them. But these 
can be /any/ kinds of companies. Not all of them are actively looking 
for alternatives to PHP. I don't know how you work for, nor your past 
experience, but I know for a fact that there are *lots* of companies 
that are actually very happy of the state of PHP still being maintained, 
compared to actually unmaintained tech that sometimes is younger than 
PHP. All these are different subjects.

The point is: the PHPF needs funding, from anyone, because without it, 
PHP will die, and the millions of apps worldwide that use PHP will be at 
risk, and their users with it, which would cause a lot of unimaginable 
problems.


 > You first need to have a working, proven track record of leadership 
capable
 > of merging new features into PHP.

What you call a "leadership capable of merging new features into PHP" is 
the actual work of the core maintainers, the PHP release managers, and 
the volunteering community that accepts to read the internals, RFCs, 
PRs, etc.
This is the *current way* of doing things, and I don't understand why 
you make this comment about "You first need to (...)" while it's already 
the case right now, and has been for many years now.


 > Internals currently has exactly the opposite track record: this has to
 > change in order for both PHP and the PHPF to succeed.

Opposite to what? Merging new features to PHP? If you go to the PHP: 
Appendices <https://www.php.net/manual/en/appendices.php> page on 
php.net, there are a lot of "Migrating from (...)" pages that contain 
all the new features merged in PHP in each minor and major versions. 
Reading them for *any* version shows that there are a *lot* of new 
features on all new PHP versions, and actually way more than what is 
presented in the /"What's new in PHP X.Y?"/ blog posts that we see 
popping out on the web every year.
Your comment is just false, internals *do* have a track record of 
working successfully in adding new features to PHP.