The future of PHP, at a distance(pooteeweet.org)
pooteeweet.org
The future of PHP, at a distance
http://pooteeweet.org/blog/0/2259
11 comments
PHP related:
Sensio Labs (Symfony) announced a $7 million investment yesterday:
https://sensiolabs.com/en/a_propos/communique_de_presse_fund...
More here:
http://fabien.potencier.org/article/71/sensiolabs-raises-5-m...
Sensio Labs (Symfony) announced a $7 million investment yesterday:
https://sensiolabs.com/en/a_propos/communique_de_presse_fund...
More here:
http://fabien.potencier.org/article/71/sensiolabs-raises-5-m...
The only advantage of using PHP in my eyes is: incredible cheap and hassle-free hosting for beginners. If you change something when introducing HHVM to the masses, then you would have a game-breaker.
If you can afford/achieve anything better than "drag'n'drop" your "index.php" there, and open your browser to "test if it works", do it.
Except, of course, you have to maintain tons of legacy stuff already written in PHP.
If you can afford/achieve anything better than "drag'n'drop" your "index.php" there, and open your browser to "test if it works", do it.
Except, of course, you have to maintain tons of legacy stuff already written in PHP.
>The only advantage of using PHP in my eyes is: incredible cheap and hassle-free hosting for beginners.
Well, clearly the engineers working on Facebook's PHP (and several other large projects, from Yahoo! to Wordpress.com) aren't "begineers" neither looking for "cheap, hassle-free hosting".
I don't buy the "it's so crap, it's ONLY used because of cheap hosting" argument.
It's also a pragmatic language, with tons of libraries and features for web use.
So, it might be far from perfect, but than again, Javascript is far from perfect too, C++ is also flawed and Java has tons of bad decisions in its design (and culture). Still, those are some of the more widely used languages.
Well, clearly the engineers working on Facebook's PHP (and several other large projects, from Yahoo! to Wordpress.com) aren't "begineers" neither looking for "cheap, hassle-free hosting".
I don't buy the "it's so crap, it's ONLY used because of cheap hosting" argument.
It's also a pragmatic language, with tons of libraries and features for web use.
So, it might be far from perfect, but than again, Javascript is far from perfect too, C++ is also flawed and Java has tons of bad decisions in its design (and culture). Still, those are some of the more widely used languages.
Facebook just can't "switch" their backend. The mountain of built PHP stuff, including HHVM, is just too big to give up. They're of course not the typical beginners, but it's really easy to "get shit done" in PHP, so it happened that they used PHP when it all exploded in popularity, and mostly had to think on how to scale a running system massively, and not to rewrite everything from scratch again.
On the libraries side: compare with javascript... all the NPM stuff and frameworks out there, and all the clientside-libraries in addition (think alone jQuery plugins). There is much crap in the JS-Land, but the sheer amount beats PHP clearly i'd say.
Or take the JVM: the VM is a masterpiece of engineering/programming and has a lot of libraries availably, not only for web stuff, and supports many languages on top of it.
Or, if you have some experience in the .NET world and know your visual studio, you can literally drag'n'drop your website together out of layouts and components.
So far you can't share PHP code seamlessly between server & client (-> JS), your runtime doesn't run quite everywhere and allows you to use the language you like (-> JVM) or is preinstalled on every windows system today and has an excellent visual development tool (-> .NET).
Yes, every language and ecosystem has it's flaws, but mostly they have also some single strengths that outweight the disadvantages. When you must nail down what PHP's is: I say incredible cheap hosting, and tons of legacy stuff (ironically often dropped on shitty cheap hosting platforms).
You may find more stuff pro/con for all the samples i mentioned above, but i hope you understand the core problem.
On the libraries side: compare with javascript... all the NPM stuff and frameworks out there, and all the clientside-libraries in addition (think alone jQuery plugins). There is much crap in the JS-Land, but the sheer amount beats PHP clearly i'd say.
Or take the JVM: the VM is a masterpiece of engineering/programming and has a lot of libraries availably, not only for web stuff, and supports many languages on top of it.
Or, if you have some experience in the .NET world and know your visual studio, you can literally drag'n'drop your website together out of layouts and components.
So far you can't share PHP code seamlessly between server & client (-> JS), your runtime doesn't run quite everywhere and allows you to use the language you like (-> JVM) or is preinstalled on every windows system today and has an excellent visual development tool (-> .NET).
Yes, every language and ecosystem has it's flaws, but mostly they have also some single strengths that outweight the disadvantages. When you must nail down what PHP's is: I say incredible cheap hosting, and tons of legacy stuff (ironically often dropped on shitty cheap hosting platforms).
You may find more stuff pro/con for all the samples i mentioned above, but i hope you understand the core problem.
Unless the Facebook backend is a giant monolithic service, they seemingly could have used a loosely-coupled service-oriented architecture and rewrite individual services in some new language or platform. That's how Twitter migrated from Ruby to Java.
> So, it might be far from perfect, but than again, Javascript is far from perfect too, C++ is also flawed and Java has tons of bad decisions in its design (and culture). Still, those are some of the more widely used languages.
Still, I wouldn't take a job in any of them. Javascript is crap, only used because it runs in the browser. C++ is pretty crap, only used because it has manual memory management. Java has its problems, but it has a decent design at least for the time; there is a terrible culture that I think adopted Java because it was popular rather than the other way around.
But yeah, in 2013 there are really much better languages than PHP available; if you want a similar-feeling replacement Python or Ruby are much saner, if you're willing to step further afield there are wonderful modern languages that push the boat a bit further (I'm in love with Scala at the moment).
Still, I wouldn't take a job in any of them. Javascript is crap, only used because it runs in the browser. C++ is pretty crap, only used because it has manual memory management. Java has its problems, but it has a decent design at least for the time; there is a terrible culture that I think adopted Java because it was popular rather than the other way around.
But yeah, in 2013 there are really much better languages than PHP available; if you want a similar-feeling replacement Python or Ruby are much saner, if you're willing to step further afield there are wonderful modern languages that push the boat a bit further (I'm in love with Scala at the moment).
Define 'better'. Personally I think Clojure has a lot going for it, and it's better than a lot of languages in a many ways. However, for the kind of application I work on PHP is significantly better fit than Clojure. Most of the points made in this talk apply to my situation. http://www.infoq.com/presentations/php-history
The main "better" I care about is "fewer gotchas and special cases to memorize"; that's not the only thing that matters about programming languages, but it's a big factor. I don't have time to watch a 40-minute video; arguments I remember hearing from something similar are the very fast coding feedback cycle (easy with modern-day rails/django/etc.), "it's better than it used to be" (not really an argument), availability of frameworks (but I've never seen an actual example of the advantages that you don't get in other languages/frameworks), large standard library (again, present in other languages), dependency management (which seems more like php catching up with other languages than overtaking them), deployment (may have been a good argument in the pre-wsgi days and when Apache was the only webserver around, but not true any more IMO). What is it you see PHP as better than ruby/python at?
Well firstly the gotchas very rarely get me. I found the same with Javascript. The inconsistent and odd data conversions make fun slides to denigrate the language, but in practise they seem to be easily avoided.
I realize posting a 40 minute video to support my point is a bit lazy and unfair but you seem aware of some of the key points fortunately.
First let me admit that we have a php legacy codebase, so porting that to another language, even if we had a strong desire too would probably be prohibitive.
I definitely feel super productive in PHP. I've been able to knock out a new app feature in 1 day, which to build the equivalent in Java would have been at least 5. It's very easy to write code fast, and then come back and refactor it later. Using PHP Storm as an IDE with a very good debugger and PHPUnit to build a suite of tests for everything we do means that gotchas are always eliminated before production, and with PHP I find things are either working or completely broken with not much in-between.
I guess having a strong unit test suite, or really it's more of an acceptance test suite, is something you can do in most languages, but the assurance it gives us enables us to share large code bases between teams, doing frequent merges of features. You can have large numbers of programmers with varying abilities and even programming styles hitting the code without too much headache.
The talk also mentions state. Not sharing state between requests except explicitly. You don't have to worry about complicated background threads, resource leaks, memory leaks. Even crashes are less of a big deal since you just lose one request to it, not the whole server like with Java et al.
PHP's array is a swiss army knife with lot's of useful functions for transforming data, which is a lot of what we do on the server. I can map, reduce and filter data. I can dynamically handle arrays or single objects in the same function, or handle arrays of different kinds of data without any fuss. In short going from what I want to happen to having it happen is very fast.
Background tasks are queued and run on other systems including some written as bash scripts or in Python, Go and node.js. These languages are a better fit for these jobs and so we ditch PHP for those.
What Facebook is doing with HHVM (run faster) and Hack (add type safety as needed) is pretty interested and we've adopted the first but not yet the latter.
Hopefully that's flavour of what I like about using PHP. I have not written more than a few lines of Ruby so I cannot comment on that. I have done some maintenance work on a Python server but not with a modern framework. I'm not sure Python with a modern web framework offers all of the advantages I've mentioned above but I am open to being enlightened on that.
I realize posting a 40 minute video to support my point is a bit lazy and unfair but you seem aware of some of the key points fortunately.
First let me admit that we have a php legacy codebase, so porting that to another language, even if we had a strong desire too would probably be prohibitive.
I definitely feel super productive in PHP. I've been able to knock out a new app feature in 1 day, which to build the equivalent in Java would have been at least 5. It's very easy to write code fast, and then come back and refactor it later. Using PHP Storm as an IDE with a very good debugger and PHPUnit to build a suite of tests for everything we do means that gotchas are always eliminated before production, and with PHP I find things are either working or completely broken with not much in-between.
I guess having a strong unit test suite, or really it's more of an acceptance test suite, is something you can do in most languages, but the assurance it gives us enables us to share large code bases between teams, doing frequent merges of features. You can have large numbers of programmers with varying abilities and even programming styles hitting the code without too much headache.
The talk also mentions state. Not sharing state between requests except explicitly. You don't have to worry about complicated background threads, resource leaks, memory leaks. Even crashes are less of a big deal since you just lose one request to it, not the whole server like with Java et al.
PHP's array is a swiss army knife with lot's of useful functions for transforming data, which is a lot of what we do on the server. I can map, reduce and filter data. I can dynamically handle arrays or single objects in the same function, or handle arrays of different kinds of data without any fuss. In short going from what I want to happen to having it happen is very fast.
Background tasks are queued and run on other systems including some written as bash scripts or in Python, Go and node.js. These languages are a better fit for these jobs and so we ditch PHP for those.
What Facebook is doing with HHVM (run faster) and Hack (add type safety as needed) is pretty interested and we've adopted the first but not yet the latter.
Hopefully that's flavour of what I like about using PHP. I have not written more than a few lines of Ruby so I cannot comment on that. I have done some maintenance work on a Python server but not with a modern framework. I'm not sure Python with a modern web framework offers all of the advantages I've mentioned above but I am open to being enlightened on that.
> the gotchas very rarely get me. I found the same with Javascript. The inconsistent and odd data conversions make fun slides to denigrate the language, but in practise they seem to be easily avoided.
They don't tend to actually "get" me, but I feel like they're always there in the back of my mind, taking up space that could be used for something more useful. It's not a huge difference, but it's there.
> I definitely feel super productive in PHP. I've been able to knock out a new app feature in 1 day, which to build the equivalent in Java would have been at least 5.
Well sure, we're talking about a very different style of language. But I think Ruby or Python get you the same thing. Certainly you have map/reduce/filter (and Python's for comprehensions go one step further), and dynamic typing.
> with PHP I find things are either working or completely broken with not much in-between.
Interesting; what bothers me the most when using PHP is that it feels easier to introduce security flaws than other languages. Not that it's hard to code safely, but sometimes the most obvious way to e.g. access a database is the unsafe way (which is partly just because there're a lot of old libraries and bad advice floating around). Charset handling is a similar area; I've seen lots of PHP code that appears to work fine but goes wrong when given non-ascii characters. It wouldn't surprise me if there were similar issues with timezones, though I haven't dealt with them enough in PHP to be sure.
They don't tend to actually "get" me, but I feel like they're always there in the back of my mind, taking up space that could be used for something more useful. It's not a huge difference, but it's there.
> I definitely feel super productive in PHP. I've been able to knock out a new app feature in 1 day, which to build the equivalent in Java would have been at least 5.
Well sure, we're talking about a very different style of language. But I think Ruby or Python get you the same thing. Certainly you have map/reduce/filter (and Python's for comprehensions go one step further), and dynamic typing.
> with PHP I find things are either working or completely broken with not much in-between.
Interesting; what bothers me the most when using PHP is that it feels easier to introduce security flaws than other languages. Not that it's hard to code safely, but sometimes the most obvious way to e.g. access a database is the unsafe way (which is partly just because there're a lot of old libraries and bad advice floating around). Charset handling is a similar area; I've seen lots of PHP code that appears to work fine but goes wrong when given non-ascii characters. It wouldn't surprise me if there were similar issues with timezones, though I haven't dealt with them enough in PHP to be sure.
> Interesting; what bothers me the most when using PHP is that it feels easier to introduce security flaws than other languages. Not that it's hard to code safely, but sometimes the most obvious way to e.g. access a database is the unsafe way (which is partly just because there're a lot of old libraries and bad advice floating around). Charset handling is a similar area; I've seen lots of PHP code that appears to work fine but goes wrong when given non-ascii characters. It wouldn't surprise me if there were similar issues with timezones, though I haven't dealt with them enough in PHP to be sure.
Well in my case we work on mobile apps so the client doesn't do anything unexpected with respect to character sets and time zones. Probably that's harder when working with random web browsers. Security wise I agree with you it's easy to do wrongly, especially with the simple DB API's that can be used naively.
Well in my case we work on mobile apps so the client doesn't do anything unexpected with respect to character sets and time zones. Probably that's harder when working with random web browsers. Security wise I agree with you it's easy to do wrongly, especially with the simple DB API's that can be used naively.
Scala is incredible, but after learning it for a few weeks i realized that it is just too much. I just can't explain it better. Additinally the last time i toyed around with Scala, SBT was a joke compared to RubyGems/CPAN/NPM. Not the language matters, but the library-ecosystem around it.
The engineers working on FB's PHP have reimplemented the runtime. I doubt that was a bonus or a reason they considered PHP. I find it highly unlikely anyone started off using a platform with the goal of "we get to completely re-implement this platform because it will not work for us otherwise."
That's a flawed argument. The only reimplemented the runtime to get better performance, for their humongus needs. The PHP semantics and language remain the same.
So, them re-implementing the runtime is no more an argument against PHP than using PyPy instead of CPython or JRuby instead of MRuby is.
Not to mention that have they been using say Ruby instead of PHP, they'd have the same, or even worse, problems regarding getting the most performance out of their runtime.
So this is totally orthogonal to the issue of PHP's merits -- only has to do with performance, so the same things could have been said for Python or Ruby that are in the same ballpark as PHP in this area.
So, them re-implementing the runtime is no more an argument against PHP than using PyPy instead of CPython or JRuby instead of MRuby is.
Not to mention that have they been using say Ruby instead of PHP, they'd have the same, or even worse, problems regarding getting the most performance out of their runtime.
So this is totally orthogonal to the issue of PHP's merits -- only has to do with performance, so the same things could have been said for Python or Ruby that are in the same ballpark as PHP in this area.
I can give you two more advantages. Lots of know-how available and lots of developers to pool from.
Another: it's really-really easy. I've built frameworks, done ruby, django, prior to my Java days. And, wow, php is just sooo easy to iterate and play with.
"Also what about windows users, still a very significant portion of the PHP user base?"
Yes, especially during development. I am toying w/ a PHP implementation on top of luajit, written in PHP so it may be more hackable and bootstrapped.
The real problem is PHP fails to define a specification that implementations can follow (though they probably weren't prepared for the current situation). Sadly the runtime becomes the spec, and with such a large standard library, it's hard to predict what happens in dynamic languages when you send in something undocumented. In order to work w/ the myriad of PHP projects out there, unfortunately you have to mimic the undefined aspects.
We are headed towards a more fragmented PHP than we already have. I've had enough problems changing PHP versions (regressions and undefined standard function changes), now with HHVM, you will have one more fragmentation piece. I'm all for different implementations. The saving grace I've found is all the language phpt files (but doesn't help w/ parsing and many compile-time errors).
Yes, especially during development. I am toying w/ a PHP implementation on top of luajit, written in PHP so it may be more hackable and bootstrapped.
The real problem is PHP fails to define a specification that implementations can follow (though they probably weren't prepared for the current situation). Sadly the runtime becomes the spec, and with such a large standard library, it's hard to predict what happens in dynamic languages when you send in something undocumented. In order to work w/ the myriad of PHP projects out there, unfortunately you have to mimic the undefined aspects.
We are headed towards a more fragmented PHP than we already have. I've had enough problems changing PHP versions (regressions and undefined standard function changes), now with HHVM, you will have one more fragmentation piece. I'm all for different implementations. The saving grace I've found is all the language phpt files (but doesn't help w/ parsing and many compile-time errors).
Do you have a blog, or do you intend to put it on Github?
A PHP parser written in PHP that generates bytecode for LuaJIT or HHVM's JIT-runtime would be cool. I was thinking about this too. And it would be fun to hack around :)
FB's HHVM JIT and its bytecode format "hhir" is explained is the following recent blog post: http://www.hhvm.com/blog/2027/faster-and-cheaper-the-evoluti...
LuaJIT2 and DynASM: http://luajit.org/
[edit:] I found your repo: https://github.com/cretz/meh ...interesting, I am reading the code atm
A PHP parser written in PHP that generates bytecode for LuaJIT or HHVM's JIT-runtime would be cool. I was thinking about this too. And it would be fun to hack around :)
FB's HHVM JIT and its bytecode format "hhir" is explained is the following recent blog post: http://www.hhvm.com/blog/2027/faster-and-cheaper-the-evoluti...
LuaJIT2 and DynASM: http://luajit.org/
[edit:] I found your repo: https://github.com/cretz/meh ...interesting, I am reading the code atm
From my understanding, if the day ever comes where the official PHP engine is switched to HHVM, it would catapult performance past Python and Ruby in pretty much all scenarios.
Predicting the future is risky.
HHVM exists. You can benchmark it against Python and Ruby today. What are the results?
In any case, Python has things like cx_freeze that can be used to make apps close to compiled performance. And Python is not a single monolithic implementation. IronPython running on .NET for instance. PyPy has a VM with JIT.
In any case, few people these days are worried about raw performance of apps. There are easier things to fix with page load times, getting rid of resource locking, and so on.
HHVM will extend PHP's useful lifetime but outside of Facebook, Drupal-based sites, and WordPress-based sites, I don't see it growing in any significant way.
HHVM exists. You can benchmark it against Python and Ruby today. What are the results?
In any case, Python has things like cx_freeze that can be used to make apps close to compiled performance. And Python is not a single monolithic implementation. IronPython running on .NET for instance. PyPy has a VM with JIT.
In any case, few people these days are worried about raw performance of apps. There are easier things to fix with page load times, getting rid of resource locking, and so on.
HHVM will extend PHP's useful lifetime but outside of Facebook, Drupal-based sites, and WordPress-based sites, I don't see it growing in any significant way.
cx_freeze just package python apps so you can distribute them like native apps, that is without requiring the installation of the python interpreter. It doesn't impact performance.
Performance oriented pythonners go with pypy, numpy, cython, numba, etc. Each of them gives a very significant speed boost.
Performance oriented pythonners go with pypy, numpy, cython, numba, etc. Each of them gives a very significant speed boost.
If you add up Facebook + Drupal + Wordpress you probably come to a large % of total worldwide pageviews.
Versus native Python and Ruby, perhaps. Versus PyPy and Ruby Motion? Probably not.
I think what the parent comment meant was that the "official" PHP would catapult past the "official" python & ruby.
I believe the correct way to refer to them is not "official", but "reference". The reasoning for this being that most languages encourage others to implement a compiler/interpreter.
I find that under most circumstances php-fpm and nginx is already enormously snappy and resource miserly, especially compared to rails. That's just anecdotal but I've seen the same thing in a lot of places. Performance wise PHP is in a pretty reasonable state except at scales that only a few companies in the world have to worry about.
Does HHVM get massive gains for "normal" PHP code? I remember reading something about FB's early efforts, and there were strict guidelines about proper usage and whatnot.
I have no idea how "good" "normal" PHP code is written compared to Ruby/Python.
I have no idea how "good" "normal" PHP code is written compared to Ruby/Python.
We tried HHVM for use with our "normal" PHP.
There was a measurable performance increase, but it was disappointing overall. Perhaps my initial hopes were too high.
Our company is small and engineering/ops resources are very limited, leading to a lot of pragmatic decisions. After a few days of experimentation, I decided that HHVM was promising, but for us it's not yet worth the extra ops infrastructure.
We get much bigger improvements tuning other pieces of our stack.
There was a measurable performance increase, but it was disappointing overall. Perhaps my initial hopes were too high.
Our company is small and engineering/ops resources are very limited, leading to a lot of pragmatic decisions. After a few days of experimentation, I decided that HHVM was promising, but for us it's not yet worth the extra ops infrastructure.
We get much bigger improvements tuning other pieces of our stack.
It works for Wordpress and Drupal, and those contain 90% of PHP functions. I mean there are times you will find issues or what not, but for the most part it's pretty good.
"official PHP engine is switched to HHVM, it would catapult performance past Python and Ruby in pretty much all scenario" <-- official php performs faster than ruby/python anyway!!
Kinda wish they would drop backwards compatibility once in a while.
I get why they don't but that's why PHP is just the most popular mediocre language.
There should be scheduled non backwards compatible releases for every language (say every 10 years) that's the only way they can improve and not just get replaced when better ones come along.
I get why they don't but that's why PHP is just the most popular mediocre language.
There should be scheduled non backwards compatible releases for every language (say every 10 years) that's the only way they can improve and not just get replaced when better ones come along.
Chances are good that there will be a PHP 6 release in the near future (~3 years?) that contains a non-trivial amount of BC breakage. At least the idea has gained some momentum recently. But no branch / timeline yet ;)
Python did that, and now everyone loves to hate it.
I like Python3. They fixed all the inconsistencies in the language.
Sucks that some people are still stuck with 2.7 but it's definitely worth upgrading if you can.
Sucks that some people are still stuck with 2.7 but it's definitely worth upgrading if you can.
I don't think that developers hated Python 3. They hated to having to rewrite/fix a ton of 3. party modules. For a long time the improvements in Python 3 simply wasn't worth the hassle of dealing with incompatibilities.
Lua does it very frequently, and people generally don't get quite as upset about it. The popular LuaJIT compiler and interpreter even implements a language that is somewhere between Lua 5.1 or Lua 5.2 without matching either exactly.
PHP deprecates features all the time... you're an idiot.
Not the same thing. PHP needs a total makeover not some minor tweaks.
And you're very rude please go away.
And you're very rude please go away.
It's like how forest fires are a bad thing, but not having forest fires for a long time is even worse since the amount of underbrush just grows to the point where a massive calamity is unavoidable.
Backwards compatibility is a noble goal, but it should be done by add-ons, not core features.
Apple constantly throws out features to keep the core product leaner. Is this annoying and disruptive to the end users? Yes. It just means that new adopters, which is their constant goal, do not have to deal with this legacy.
X11 support was dropped, but you can still get it through third-party XQuartz. PowerPC code doesn't run out of the box, but there are emulators that work just fine.
PHP should show a little more confidence in itself.
Backwards compatibility is a noble goal, but it should be done by add-ons, not core features.
Apple constantly throws out features to keep the core product leaner. Is this annoying and disruptive to the end users? Yes. It just means that new adopters, which is their constant goal, do not have to deal with this legacy.
X11 support was dropped, but you can still get it through third-party XQuartz. PowerPC code doesn't run out of the box, but there are emulators that work just fine.
PHP should show a little more confidence in itself.
Not at all related to the post and/or content, but that domain name is awesome.
The latest HHVM update has seen CPU usage reduced by 20% across Facebook. I wonder how many thousands of servers that works out to.
In what universe does Python and Ruby's alternative implementations have significant market share?
In the real universe we live in, JRuby, at least, has fairly wide adoption, and YARV, which started out as one of the alternative implementations, became the mainline implementation (and, at least for a while, it was widely speculated the same thing would eventually happen with Rubinius.)
before bashing php about perfomance(to python ruby users)..
Lets have some data. for python users (http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...)
for ruby users {http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...}
Lets have some data. for python users (http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...)
for ruby users {http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...}
google app engine now supports PHP and they completely reimplemented the language. it is extremely fast and seems to already do all the things this story eludes might happen.... they already have.
They did not completely reimplement the language, it appears to be the standard implementation. Compare https://github.com/GoogleCloudPlatform/appengine-php/tree/ma... to https://github.com/php/php-src
"There were a bunch of old devs opposed to adding this documented "processes", saying that "open source is about fun and processes kill the fun". But to me that was always shining through that argument was that there is always an implicit process and that process is usually ideal for the current people "in power"."
Jo Freeman has an essay called "The Tyranny of Structurelessness" which focused on how this issue (lack of explicit process) played out in left-wing political movements in the 1970s, and she does a great job of explaining how the lack of explicit process allows those with implicit power to keep control of things.
http://www.bopsecrets.org/CF/structurelessness.htm
"Contrary to what we would like to believe, there is no such thing as a “structureless” group. Any group of people of whatever nature that comes together for any length of time for any purpose will inevitably structure itself in some fashion. The structure may be flexible; it may vary over time; it may evenly or unevenly distribute tasks, power and resources over the members of the group. But it will be formed regardless of the abilities, personalities, or intentions of the people involved. The very fact that we are individuals, with different talents, predispositions, and backgrounds, makes this inevitable. Only if we refused to relate or interact on any basis whatsoever could we approximate structurelessness — and that is not the nature of a human group."