Its been quite a few years since I have been last subscribed to the internals mailing list. I still hang out in one of the popular core dev IRC channels, follow quite a few on twitter. So I still manage to stay on top of what is happening more or less but not the details in the discussions. Just wanted to put this as a disclaimer. Any opinions in this blog post are opinions formed watching something at a distance and this always runs the risk of being quite wrong or more impartial.

To me it feels like PHP development has become much better structured. It also feels like the RFC process has enabled an influx of new contributors that previously simply didn't know how to get their stuff in. 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". As such, there is nothing wrong with that, since if the current people can handle the load, why bother trying to please a theoretical new contributor? But while several core contributors, like Rasmus, Derick and Ilia, have sustained pretty significant levels of contributions, many others have drastically reduced their contributions. More over as the feature scope increases it makes a lot of sense to also grow the number of maintainers. However I guess the really active core group of contributors in most open source project I know tends to hover around 10-20. The beauty of clearer processes is that it can also help in clearer delegation, which can lead to subgroups within an open source organization that again have an inner circle of 10-20 really active people. Now from all I hear "discussions" on the internal mailing list still have a tendency to generate lots of less than helpful traffic.

But everything could be turned up side down in the near future. I have been critical of Facebook's initial efforts at trying to reimplement PHP. A change of direction towards a JIT without a code compilation requirement however have made their efforts significantly more viable. More importantly Facebook is now actively trying to enable anyone to run their chosen PHP framework on top of HHVM. They are even actively soliciting feedback from framework authors where they would like HHVM to go next in terms of language features. If you compare this to current PHP internals where it seems to be a never ending battle between mostly the older developers concerned with backwards compatibility, no doubt one of the reasons why PHP has been able to catch 80% of the internet, and framework authors asking for new language features to enable easier development. Make no mistake adopting Facebook specific syntax in frameworks will of course make that code incompatible with PHP itself. Some of this could be "fixed" by a "compiler" that transforms HHVM specific features to normal PHP code, but that would be probably more sad than ironic. Also what about windows users, still a very significant portion of the PHP user base?

None the less the proposition seems tasty when wearing my framework hat. But while this is exciting, its at least as much troubling to me. Do we really want Facebook to have final say in how the language evolves? I am not even sure if Facebook really wants this responsibility. I guess other scripting languages have already had to deal with this situation with various popular reimplementations of Ruby (JRuby, IronRuby ..) and Python (Jython, IronPython ..) having scooped up large parts of their user base. Then again I assume these reimplementations have actually also helped grow or at least sustain their use bases. Facebook has hired quite a few of previous PHP core developers though I am not entirely sure how involved they are in HHVM development. But at the very least it could ensure that there is a bit of a trust relationship between PHP internals and HHVM, which is of course quite important in the open source world. Rasmus also seems to be sympathetic to HHVM. To me a key requirement for this all to make sense is for more non Facebook employees to get involved in HHVM development. This would ensure that the project wouldn't blow up if for some reason Facebook looses interest. It would also help in making the internal decision process on HHVM more transparent.

At the same time I see a huge opportunity here. If I remember correctly it was Thies that first stated that the goal of PHP internals should focus on making it possible that all extensions could in fact be written in PHP rather than C back at some LinuxTag over a decade ago. With HHVM's JIT this now seems more feasible than ever before. I have long said that building a good API is an iterative process which requires input from many people and early adopters to battle test. However as PHP is written in C the number of contributors are limited and its not easy to get a broad range of testers to put the concepts into real world testing. PECL has tried to reduce this pain point a bit by providing infrastructure for C developers to create and distribute extensions outside of core release process. But to me its still clear that its not a sufficient solution to provide the number of eyes needed to build more complex APIs. So HHVM could help push forward a revolution in the process of adding new functionality to PHP that I have been waiting for since ages.

So in conclusion there are lots of reasons to be excited about HHVM's impact on the PHP community. But we should also ensure that in the process the community does not become dependent on a commercial entity.

Update: The performance of HHVM seems quite impressive indeed these days, since Chregu ran these benchmarks, the HHVM team has released version 2.3, which supposedly reduces CPU load another 20%. HHVM is now also available on Travis-CI.

Update 2: The article has been posted to hacker news, resulting in a surprisingly sane discussion.