From: Pierre Joye on
On Tue, Oct 27, 2009 at 8:46 PM, Stanislav Malyshev <stas(a)> wrote:

> There's no any "fork" and nobody ever presented it as "the only usable
> binary distributions for windows".
> Applying patches between releases is how most of binary distros always
> worked (provided there are patches important for their clients which are not
> released yet) with a lot of opensource projects - incl. Redhat, etc. - and
> nobody ever thought of talking about "forking" anything.

Call it a spoon if you prefer :)

Btw, that's why I used "a kinf of fork" as I'm not sure about the
other patches not fitting in the backporting category.

Pierre |
From: Shahar Evron on

Pierre Joye wrote:
> hi,
> The only fact that you build 5.2 with VC8 means that you apply patches
> not present in php 5.2 (eventually in 5.3).

Yes, that's true. I include those in the 2nd category of patches we
apply. They should have no effect on any user code.

I am specifically trying to focus on real pros and cons of Zend Server
for the end user, not for someone who's a core developer. These patches
99.9% of the time have either no effect on the user's code, or, if they
do, it's for the better because it is some bug fix.

> But why would you provide your own binaries with random patches (not a
> judgement, only a statement) instead of using PHP binaries? Security?
> We do security releases when a librarie is affected. PHP itself has
> regular security releases as well. For example, Microsoft uses
>'s binaries for the Web Platform Installer
> (

First, they are not random. Usually they are very specific hand picked
patches that we decide are important enough for our own customers.
There's nothing random about it.

BTW in most cases these patches are created by Zend employees who fix a
bug in PHP specifically because it is important to our customers, commit
it, and we then provide an update.

Now as for the "why" question, A part of Zend's business is to provide a
binary distibution of PHP which is supported and updated by Zend. We
need to control patches that go in, libraries that we compile against
etc. - exactly because while PHP releases do include critical fixes,
sometimes our own customers need a fix that PHP developers do not
consider important enough to release (not criticizing, different users
have different needs). It happens on almost every release of Zend
Server. This is exactly what our customers pay us for.

In reality I think that this practice is not very different from how
Linux distributions might patch and release some software before there's
an upstream release. It happens all the time (and again, this is why
some people choose to pay RHEL or Ubuntu).

In fact, they do that for PHP as well - so I am not sure why this is so

> As being both my concerns are to actually see a kind of fork of PHP,
> being presented as the only usable binary distributions for windows
> and other platforms (and for apache too).

We do not present it as such (see first paragraph of my first email in
this thread - I specifically say the same setup can be achieved in other
ways). We do think it's better than some setups, it would be silly of us
not to take pride in what we do - but I don't think we've said it's the
only usable way to use PHP on Windows. If you encountered someone from
Zend saying that I'd like to know, so I can correct them.

Most importantly, it is *not* a fork of PHP. PHP is open source, vendors
are free to build binary distributions of it. We have no intentions to
start taking development in a different direction. Again, I think it is
like saying Debian forks PHP, or most other software they ship. It's
just wrong.

Actually, forking PHP makes absolutely no business sense for Zend as a
company. Seriously, think about it. More work for us, less value to our
users, more compatibility headaches - we are trying to minimize those,
not the opposite.

> As with any distributors who apply custom patches, we do not support
> them. However these distributors usually have an issues tracker and
> ask their users to report issues there. If they meet a real php bug,
> it is then then reported in our tracker. That's common practice. We
> will indeed not reject obvious bugs only because the users use ZS.

We have a ticketing system and forums, and we have in house developers
who can take a bug reported to Zend and work to either fix it or
properly report it in

Do you think an open bug tracker for ZS would make a big difference for
your work?



Shahar Evron <shahar.e(a)>

Product Manager
Zend Technologies
From: Shahar Evron on

Pierre Joye wrote:

> Random has no bad or good meaning here. You apply patches that
> upstream ( does not apply, for a given branch.

Yes, but they are not random... There is a very clear process by which
we choose them - and it is not by closing our eyes and pointing a finger ;)

> Are the windows sources available somewhere? For the libs and php?

Currently, only the Linux sources are available (through the src deb/rpm
package). We plan to make the Windows sources available too - I can't
put a time frame on it yet but it will happen.

>> We have a ticketing system and forums, and we have in house developers
>> who can take a bug reported to Zend and work to either fix it or
>> properly report it in
>> Do you think an open bug tracker for ZS would make a big difference for
>> your work?
> Not really as long as you report issues to us. But I did not see that
> happen in the past for windows (one example, the mssql library bug was
> updated in ZS but no report in about the actual issue).

Ok, I just want to make it clear that while it's possible we failed to
properly report some things (I am honestly not involved in every bug,
far from it - so I can't comment about this specific issue) it is not
our intention or evil plan to "hide" bugs from Again, this is
not something we'd benefit from. If it happened it was due to a mistake
and not because of some policy.

> It is also time for a little clarification. I have nothing against ZS
> in general. However I do have issues with the marketing behind it as
> it creates confusions while not improving php itself. Marketing is
> just fine as long as it stays outside, but as this discussion
> happens on our lists, I had to reply. Even if we disagree on a couple
> of things, I think we made our points and the readers can now make
> their choices with all the necessary info.

I understand and respect that. I think the original poster of the thread
asked an honest question and I felt that I had to give Zend's
perspective - I don't think that in my original response there was any
"marketing". I tried to be as balanced and as transparent as possible.

I agree that I've made my point, so unless specific questions come up I
will now shut up :)

With best regards,


Shahar Evron <shahar.e(a)>

Product Manager
Zend Technologies