One of the various ways to measure an open source project is the way it encourages and accepts patches from community members (or future members). The various open source projects I’m involved with have many ways to send patches: mailing list, bug tracking systems and more recently pre-commit tools for peer review (such as gerrit). Another popular option is to use github’s pull request feature for this. Personally, I find it too complex for simple patches and would prefer gerrit over it.
As part of my work at Zend, I try to make sure patches are sent back upstream. Comparing to other open source projects I know, it seems to me that PHP isn’t open enough for contributions. This might be just my private case, but if not, it would be discouraging people to contribute and blocking the community from expanding.
To ease things up, I’ve created a github fork of the php-src repository and sent pull requests with each of the patches (as suggested at http://php.net/git-php.php). Even edited the bugs reports with the pull request details (as they provide such integration). I’m waiting to see if this will trigger a more rapid review process from the project. For the simple patch, I got a response very fast from a user, but still waiting for a core member to check it.
Going over the pull requests (both open and closed), I’m not too optimistic about having the patches merged, judging by past merged patches (most of them are at least 2 months) and by the open patches (e.g. a typos fix patch is waiting for month).