Well said, Florin. :) I'm not a core contributor, I never have been and probably never will be as I don't know C... but I do follow internals quite keenly. It strikes me that the biggest problem here is that there's no one entity to decide the rules of the road, so everything (including the rules as to how things should work,) has to be decided by committee - but the committee is too big and too diverse to be useful.
If you look at other big open source projects, there's usually a person or group that sets the ground rules for contributions and as long as everyone plays by those rules, contribution is easy, rewarding and painless. Take Blink for example, Google defined the rules but now Intel, Opera, and so on all play nicely together with *very* little friction. Blink seems to have a really good framework for contribution; Instead of X% of contributors having to agree, they provide an "intent to implement" framework to seek feedback on an idea, and an "intent to ship" framework to seek approval from *three* relevant code owners - the people that know the most about the section of code your patch affects. This seems to allow for rapid innovation whilst protecting the codebase from fly-by patches. Could something like that work for PHP? And, perhaps more importantly, would the PHP core contributors be open to a person/group being appointed to lay down these ground rules? It could work on a time-restricted basis akin to the release manager role.
