New PHP Version Fork

Contents

Robert Eisele PHP fork

The new PHP version name and the PHP license constraints

Shall you use this PHP forked version?

The future of this PHP fork

Robert Eisele PHP fork

Last June 8, Robert Eisele launched a new forked PHP version that he derived from PHP 5.3.6. It is the result of merging several changes that he wanted to make to PHP, on which he has been working for the last 3 years.

This PHP fork version code is available on GitHub for anybody to download or even fork it again.

The new PHP version name and the PHP license constraints

Before commenting on what this new PHP version, I would like to mention some details about what you can do and cannot do when you create a new PHP version fork.

PHP is an Open Source project. You can take its source, modify it to your needs, and even redistribute it if you want. The PHP license, which is based on the Apache license, does not even require that you publish your changes, unlike for instance the GPL license.

The only requirement is that, if you redistribute your modified PHP version, you need to give your new version a different name. The new nameh must not include the PHP word. So you cannot name a forked PHP version something like Turbo PHP, PHP 2011, nor anything that includes PHP in the new version name.

Given that, in case you are wondering why Facebook was allowed to call their PHP compiler implementation, HipHop PHP, let me clarify the following. 

HipHop PHP is not a fork of the main PHP code. Facebook developers wrote HipHop PHP from scratch, thus without deriving their code from the main PHP distribution code. So the PHP license restrictions do not apply to HipHop PHP.

The restriction of use of the word PHP in the name of a forked PHP version is just a requirement of the PHP license. The PHP group does not own the trademark of the PHP word, so they cannot restrict the use of the PHP word in other applications which are not derived of the main PHP code controlled by the PHP group.

Shall you use this PHP forked version?

The changes implemented in this version relatively to the official PHP 5.3.6 are numerous. I will not repeat them here because you may read all about them in the announcement post mentioned above.

I just like to highlight that this was not a trivial effort. It was certainly the result of work that Robert did during a long period of time. I never heard of Robert's work until now, but from what I could observe, Robert seems to be a very capable developer.

That said, you may be wondering if you should use this PHP forked version instead of the main official PHP 5.3.6 version.

Personally I think it is not beneficial for the PHP community to dilute their efforts and create many forked versions. It would be better if there was a single PHP version with the features that all the different developers can contribute. That is why PHP got to be such a popular language. It was written by hundreds, if not thousands of developers.

However sometimes that is not possible. Sometimes there are developers that have strong feelings and need features which the PHP core developers do not agree in their inclusion in the PHP core implementation.

The eternal discussions on the PHP internals list about which proposed features should be included or not are quite common.

Sometimes features are simply not accepted because the proponent did not provide any code to implement the features. Other times, even though the code to implement the propose features is made available as a patch, there is always somebody that objects for a reason, that sometimes it is hard to understand.

In certain cases the discussions seem to take forever because of a simple detail, even though everybody agrees on implementing a proposed feature. That was the case of PHP namespace support. Everybody agreed that PHP would benefit from namespaces, but there was no consensus regarding the character that should be used as namespace separator. It was necessary to have a voting processed to decide to pick the namespace character separator.

The future of this PHP fork

Regarding Robert Eisele fork, I have noticed an effort from some PHP core developers to persuade him to submit his version changes as patches. That does not mean all patches will be accepted.

It seems that Robert is also not interested in carrying on the development of his PHP fork alone. Obviously is very large effort for a single developer to keep his version eventually integrating any changes which are made available in the main PHP version.

Sometimes forks seem to have more success than the the original project, at least for a while. That seems to have been the case of LibreOffice, which is a fork OpenOffice created by the Free and Open Source community after having disagreed with the project route when Oracle bought Sun and so have acquired the rights to the OpenOffice project.

Meanwhile Oracle just decided to hand over OpenOffice project to the Apache foundation. So I wonder if LibreOffice developers will not make an effort to merge efforts into OpenOffice again.

Another case of fork, actually multiple forks, were carried out with MySQL. One those forks is MariaDB. It was created by one of the creators of MySQL. He was unsatisfied with the route that Sun and then Oracle gave to MySQL and created this fork of MySQL.

MariaDB is a drop-in replacement of MySQL. It seems to be here to stay, especially in cooperation with other projects like XtraDB which is a free compatible replacement of InnoDB, a MySQL database table handler which supports transactions and online backups.

So we do not know yet what will happen with this PHP fork. Maybe the changes will be merged in the main PHP project, or maybe Robert gets help from other developers that help him to carry on as a standalone project.

What do you think? Should Robert carry on with his fork or should he do an effort to agree with other PHP core developers and merge this fork new features?