On 09/11/2013 05:44 AM, Florin Patan wrote:
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 Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to