Hello everyone.

I just want to point out one thing about all that internals stuff and
remind about a good idea that has been surfacing a few times through the
years, but now I think it can actually get traction because of recent
problems.
It is based on the fact that there are too many people writing to internals
and mailing lists are not actually manageable at this level. I stopped
following all the stuff around a year ago, when I started to get like 15 to
30 maillist threads in my inbox daily (hundreds of mails) and too much
noise.
So, I think, it's time to move to a forum. Actual forum, that can be
managed, can have sections dedicated to certain stuff and has user
management that allows to mute or actually ban people who are not able to
behave, troll and do other kind's of stupid stuff that disrupts the work.
Many devs are already just ignoring this mailing list, so what is the point
of having it if relevant people just don't read it?
The list should remain of course, just to be used as a notification tool
for new important forum threads, RFC's, daily/weekly digest so that those
who have less time can still follow all the stuff in a compact manner.

Hell, I even volunteer to do integration stuff with mailing list, wiki and
other, just don't give me too much frontend stuff to do.

Arvids.

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.

• having a RFC to make a language change requires to have a patch
  which if you don't know C and internals you got no chance of doing.

Well, so what should happen? An RFC without patch is accepted and then?
Somebody has to write a patch at some time. Whom of the people spending
their free time do you want to force to do that even though they might
not be interested in the feature?

Getting a patch first

  * proves feasibility (yes, I love saying "It's just software
    everything is possible" ... but then there's always a "BUT")
  * shows technical consequences of a feature
  * shows that there is somebody who is interested in developing AND
    probably maintaining the patch (if somebody with a good idea can
    not convince a single developer how will this be maintained?)
  * allows users to actually test a feature and find problems which
    might not be that obvious from theoretical examples

Yes writing a good patch can be lots of effort, and it might be dumped,
but for most features the initial patches aren't that big.

And if you do know C, PHP internals will drain the soul out of you
before doing something

Comparing PHP with other C projects I've seen the code isn't as bad as
many people make it sound. Sure we have some "weird" macros, but for
many of those: What's the alternative? (C++11 would allow some
improvements here and there but create a whole lot of other issues) Sure
we have some creepy areas: That happens, when a project grows over more
than 15 years, when sometimes not so good developers add things,
sometimes people try to optimise things for performance and often try to
keep a good BC story (even on internal APIs) But overall PHP is a
modular quite structured code base.

• there were patches proposed by Facebook, and others, that are / were
  rejected, delayed or ignored. Who heard of Facebook anyway, they have
  just one website with a billion users probably running on a a couple
  of Galaxy Note 3 and 2-3 iPhone 6 as a load balancers, my cat can do
  better I tell you.

Facebook has active contributors who can push anything and know most
"core" people well enough. If anything they want is falling under the
floor they probably don't want it that much. Also mind: Facebook is
one usecase. Not everything which is good for them is necissarily good
for other users. And we have a multitude of users. Some want afast and
slick platform, some want many advanced features, some want it to be
simple. What we have to do is to find the "right" line ... oh, and mind
they are not using PHP but hipHop.

Where Zend | The PHP Company? It's their name, no? They are making
money out of PHP brand, certifications and training?

So can you. So do others.

They've added the opcode cache and that was the single biggest thing
they've did in 7 years? Feel free to correct me if I'm wrong.

They are active in fixing bugs and improving the performance and other
things. Sure they are not propose many new features but maybe (I'm an
outsider and can only speculate) they have noticed that with a fast
enough platform offering lots of language features you don't have to do
all things in the core but can build the environment around the core
language by building frameworks and tools and benefit the platform more
in that way. (while also making it simpler to develop and ease
participation as each framework user should now PHP and can therefore
help with the framework) but having said that: Ask Zend, not this list,
if you want something from Zend.

This all said: I agree that some structures here are bad and might be
improved but mind one thing: This community is quite open (everybody can
subscribe to this list and participate, and often git accounts are
thrown out relatively fast) which leads to a quite heterogeneous field
of people all having different interests and aims (as I mentioned above
already), you criticize this as "missing vision", one can see the same
thing as "too many independent visions" - everybody here has a reason
and goal of some kind for his/her contributions. Aligning them all the
time is tough and requires compromises. Constantly. But you won't find a
single vision which a majority would support and which wouldn't drive
too many contributors away while still deserving to be called a vision.

johannes

As I answered on Anthony's post, there is not much need for waking up,
or moving the talks to a forum, or discussing the problem to death here.

The problem is clear, and everyone involved on this mailing list is
aware of it to some degree. The only way this can be solved is if the
offenders self-censor and think twice before posting emails. This thread
is yet another example of abuse IMO. Every reply here is wasting a ton
of people's time, and we end up discussing discussion instead of making
progress.

For having been involved in the Rust community recently, I find that
their Code of Conduct [1] is great, and if everyone tries to follow it
discussions remain on point and civilized.

[1] https://github.com/mozilla/rust/wiki/Note-development-policy#conduct

I wish everyone would just take a deep breath after reading something
that makes them angry, and take another long one before hitting send
with a hurtful reply. If someone acts like a dick send them a link to a
code of conduct, either publicly or privately, and ignore everything
else they said. It's been internet wisdom for ages to not feed the trolls.

So if you want to do something useful: draft an RFC with a clear code of
conduct, put it to a vote, promote it. And if you don't agree see above,
take a deep breath and do not waste time answering this email to tell me
an idiot.

Cheers

Where's Rasmus, the so called benevolent dictator, to actually dictate
and handle the internals? Yes Rasmus, you're making money out of PHP
yet I haven't seen a comment from you in the past months. Wikipedia
doesn't list you as hibernating.

Rasmus abdicated his potential role as BDFL years ago. PHP doesn't have
a BDFL. That is, arguably, part of the problem.

Then there's that 'little' community of framework developers called
FIG which tried to do some standardization in the way things are done
in userland but guess what. It took 2 years or so for anyone here to
actually think we might really want to add PSR-0 to core. And people
here still have issues with that because it's not in the PHP 'open
spirit' (of the internals). Granted, FIG could do much better but hey,
they follow the example set here by you.

Actually, as far as I'm concerned the Internals free-for-all process is
a great example of everything FIG should avoid, and some of us have been
working very hard to avoid the trap of "be like internals" (as was the
initial model we've been trying to move away from). It's a great object
lesson in how to not run a dev community.

I'd say sorry if that sounds harsh, but I'm not really sorry about it. :-)

Or better yet, ask someone like Facebook to take over and that's it.
Maybe they'll be interested in doing that since they had to rewrite
HHVM two times to get more performance out of PHP.
If you don't like Facebook, let Microsoft take over if they are
interested. They have contributors here, they have some programming
languages under their belt.

We don't need one company taking over PHP. However, nearly all projects
eventually spawn a NFP company to at least help coordinate it, if not
drive it.

Or just dismiss the project completely and let the community take over.

But please, stop with these:

• nah, today is not a good day for this patch/ thread
• we have a leader already
• we have people contributing
• look ma' charts are growing, we are still ahead of others
• I'll just be against everything today as I didn't had enough sugar
  in my coffee
  attitudes as it's really not productive for developers and companies
  that are still using PHP.

As others in this thread have hinted, there are multiple roots to the
problem. A process that sucks (although admittedly not as badly as it
did before RFCs) is one root. A lack of shared vision is another.

When a new feature is proposed, or a controversial fix considered, by
what metric is it judged? What is the goal we're shooting for with
PHP? Is the goal "the easiest to pick up web language", or "the most
powerful web language", or "the fastest performing web language"? Guess
what: Those are, quite often, mutually-exclusive. Which matters more?
Ask 5 people on this list and you'll get 15 answers. That's no way to
run a project, or a community.

Here's another root: PHP may not be a commercial entity, but it still
has users and customers. The first rule of usability is "know thy user;
thou art not thy user", and the first rule of good user-centric or
customer-centric development is "thou art not thy customer".

PHP's customers are people developing IN PHP, not developing PHP. A
serious project needs to focus on what its users want/need/will benefit
from, not what its own developers want. Yes, this is a mental shift for
those working on the project. Yes, this can be hard. No, it's not
always fun.

But the curse of success is that you don't get a choice in whether or
not that shift has to happen. It's a shift that happens TO you, whether
you want it to or not. At that point a lot of developers may drop out
because it's not fun anymore, and feels like work. This happens.
Perhaps it should happen more, as long as there are customer-focused
people to replace them.

(Yes, I have lived through that transition in Drupal. It's still in
progress. Yes we lost people from core in the process. In the end, the
project is stronger for it.)

--Larry Garfield

PHP is a collective mind. Any dictatorship would mean a degradation for it.
If you don't like how it's managed, there is an easy path:

1. Earn authority.
2. Propose a change.
3. Implement it.
4. Maintain it.

Start with 1.

Good day internals,

This morning I read something that's not fun:
https://twitter.com/ircmaxell/status/376027280562073600

Yet another good contributor leaves this community (not the whole PHP
community) because of the way things are done here.

It's true that this is an open source project and everyone can join
and leave whenever he/she wants but like Anthony says, this project
needs more leadership, more vision and definitely a better management.
Someone said that there's no one coming forward or trying to change
things, I may not be the right person to do this but at least maybe
I'll wake up someone who can take action and change things.

Here's some facts:

• a couple of months ago named parameters was a taboo subject, I know
  because I've asked for it and everyone went silent, now we have a RFC
  discussing it
• we had a RFC for autoloading functions but people just can't
  understand how to provide feedback and at the end of the day it
  resulted in a contributor leaving because of the murkiness here
• we have a bunch of RFCs waiting for feedback and being trolled to
  infinity by people with their own agendas
• having a RFC to make a language change requires to have a patch
  which if you don't know C and internals you got no chance of doing.
  And if you do know C, PHP internals will drain the soul out of you
  before doing something
• there's no clear objective for what PHP has / will have / will not
  have / will not ever have.
• there were patches proposed by Facebook, and others, that are / were
  rejected, delayed or ignored. Who heard of Facebook anyway, they have
  just one website with a billion users probably running on a a couple
  of Galaxy Note 3 and 2-3 iPhone 6 as a load balancers, my cat can do
  better I tell you.

Where's Rasmus, the so called benevolent dictator, to actually dictate
and handle the internals? Yes Rasmus, you're making money out of PHP
yet I haven't seen a comment from you in the past months. Wikipedia
doesn't list you as hibernating.

Where Zend | The PHP Company? It's their name, no? They are making
money out of PHP brand, certifications and training? They've added the
opcode cache and that was the single biggest thing they've did in 7
years? Feel free to correct me if I'm wrong.

Then there's that 'little' community of framework developers called
FIG which tried to do some standardization in the way things are done
in userland but guess what. It took 2 years or so for anyone here to
actually think we might really want to add PSR-0 to core. And people
here still have issues with that because it's not in the PHP 'open
spirit' (of the internals). Granted, FIG could do much better but hey,
they follow the example set here by you.

For me this PHP 'open spirit' is just a way of saying: I don't want to
have my head full of real issues so I'll just ignore them and let
others handle them.

Look at other languages. Take GO for example, which is done by the
other big noobs on the market called Google.

If you want, you can actually start and contribute to the language in
less that a week from learning the language! There's documentation
inside their sources (shocking! I know). There are pages talking about
their language decisions and why they do(n't) support certain things.
PHP has some rather prehistoric documentation about its internals and
that's it. Ok, PHP is written in C not PHP that's why it's harder to
contribute to it but it's not like there's documentation for internals
anyway. Or maybe, just maybe, they actually have some good language
design, who knows?

And I know what you'll say:

• yet another one making some smoke, lets ignore him;
• who cares about you complaining, PHP is still the most spread
  language for servers
• PHP releases very often with new things for developers that they
  want / use / need.

But you really expect this to continue forever? If so you are plain
ignorant and you shouldn't be part of this.

So, either you care about PHP and wake up or leave and let others take
over.

Or better yet, ask someone like Facebook to take over and that's it.
Maybe they'll be interested in doing that since they had to rewrite
HHVM two times to get more performance out of PHP.
If you don't like Facebook, let Microsoft take over if they are
interested. They have contributors here, they have some programming
languages under their belt.

Or just dismiss the project completely and let the community take over.

But please, stop with these:

• nah, today is not a good day for this patch/ thread
• we have a leader already
• we have people contributing
• look ma' charts are growing, we are still ahead of others
• I'll just be against everything today as I didn't had enough sugar
  in my coffee
  attitudes as it's really not productive for developers and companies
  that are still using PHP.

---

Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

hi Florin,

This morning I read something that's not fun:
https://twitter.com/ircmaxell/status/376027280562073600

Yet another good contributor leaves this community (not the whole PHP
community) because of the way things are done here.

For what Anthony said he did not leave.

It's true that this is an open source project and everyone can join
and leave whenever he/she wants but like Anthony says, this project
needs more leadership, more vision and definitely a better management.
Someone said that there's no one coming forward or trying to change
things, I may not be the right person to do this but at least maybe
I'll wake up someone who can take action and change things.

Here's some facts:

• a couple of months ago named parameters was a taboo subject, I know
  because I've asked for it and everyone went silent, now we have a RFC
  discussing it
• we had a RFC for autoloading functions but people just can't
  understand how to provide feedback and at the end of the day it
  resulted in a contributor leaving because of the murkiness here

I do not agree here. I read and re read this thread again and all I
can see is one developer trying to get and provide all information to
make an informed decision. The mistake was to discuss in a circular
way for way too long. I, for one. should have interrupted this
discussion, post my thoughts or opinion as well and ask to update the
RFC accordingly.

• we have a bunch of RFCs waiting for feedback and being trolled to
  infinity by people with their own agendas

There are controversial RFCs, why we need to discussions, drafts, etc.
before voting. But we suffer from the circular discussions problem way
too often. I can take part of the blame as I did not participate nor
followed enough discussions to avoid this problem.

• having a RFC to make a language change requires to have a patch
  which if you don't know C and internals you got no chance of doing.

Well, I cannot help here. Unless I have time and needs for the given
RFC. That's how things work in 99.999% of all OSS projects I
contribute to. It is by no mean a way to block something, but simply a
fact that we have to live with.

And if you do know C, PHP internals will drain the soul out of you
before doing something

We have to improve that, not sure how right now but have some ideas
(RFCs, voting process, release process goals were to solve this exact
problem or part of it).

• there's no clear objective for what PHP has / will have / will not
  have / will not ever have.

true, I don't think it will ever have a master plan.

• there were patches proposed by Facebook, and others, that are / were
  rejected, delayed or ignored. Who heard of Facebook anyway, they have
  just one website with a billion users probably running on a a couple
  of Galaxy Note 3 and 2-3 iPhone 6 as a load balancers, my cat can do
  better I tell you.

Which patch from Facebook have been ignored or rejected? I can't
remember any of them.

That being said, I really do not think a patch is better or should be
accepted because <big company XYZ> proposes it.

Facebook is huge but their needs barely matches the needs of our
users. Tey do have great ideas, but they have to propose them like any
other contributors.

Then there's that 'little' community of framework developers called
FIG which tried to do some standardization in the way things are done
in userland but guess what. It took 2 years or so for anyone here to
actually think we might really want to add PSR-0 to core. And people
here still have issues with that because it's not in the PHP 'open
spirit' (of the internals). Granted, FIG could do much better but hey,
they follow the example set here by you.

There was a RFC (autoloaded thing if I remember correctly), it got
rejected. We must accepted this decision. Not happy with our choice?
Well, back to the roots, be a contributor and you can vote. I know it
sounds weird to point it this way, but at the end of day this is how
we can change PHP.

For me this PHP 'open spirit' is just a way of saying: I don't want to
have my head full of real issues so I'll just ignore them and let
others handle them.

Not for me. But I do not participate in discussions where I have no
clue or don't see what to discuss but say yes or no. I then simply
wait for the votes.

Look at other languages. Take GO for example, which is done by the
other big noobs on the market called Google.

If you want, you can actually start and contribute to the language in
less that a week from learning the language!

I gave many talks about php, how to contribute, etc. My personal
record is 4 new contributions during my talk (less than 45 minutes).
To contribute does not mean you have to know C, there are many other
ways, many of them do not even involve internals discussions.

And I know what you'll say:

• yet another one making some smoke, lets ignore him;

I do not consider what you say as "smoke", but the tone is not the one
I would have used, not while trying to solve a "tone" problem on this
list, in my humble opinion.

• who cares about you complaining, PHP is still the most spread
  language for servers

Right, but I do care about complains, as long as they are actually
valid and constructive.

• PHP releases very often with new things for developers that they
  want / use / need.

Indeed, and recent huge changes in how we work allow that. is it bad?

But you really expect this to continue forever? If so you are plain
ignorant and you shouldn't be part of this.

No, but what do you actually propose?

So, either you care about PHP and wake up or leave and let others take over.

No thanks, I won't leave. But again, what is your solution?

Or better yet, ask someone like Facebook to take over and that's it.
Maybe they'll be interested in doing that since they had to rewrite
HHVM two times to get more performance out of PHP.

Over my dead body. The day a commercial company actually own PHP, I
will leave, without any delay.

If you don't like Facebook, let Microsoft take over if they are
interested. They have contributors here, they have some programming
languages under their belt.

Be sure I will ask them this week, it happens I'm at their HQ these days ;-)

But please, stop with these:

• nah, today is not a good day for this patch/ thread
• we have a leader already
• we have people contributing

We do. Maybe we need even more to create a balance.

I would also suggest you to look at the NEWS file or release notes for
the 5.4 and 5.5. Almost all major new features have been done by new
contributors! If that's not a sign that things have change, even only
a little bit, then I have no idea what I am doing here.

• look ma' charts are growing, we are still ahead of others
• I'll just be against everything today as I didn't had enough sugar
  in my coffee
  attitudes as it's really not productive for developers and companies
  that are still using PHP.

As I agree on many of the points in this post, I can't and never will
agree on his tone. This is exactly what creates issues with new
contributors, or between core developers.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org