I often wondered if PHP would benefit from becoming a crowdfunded and non-profit org with a dedicated bunch of paid active core developers. By crowdfunding PHP, those devs could focus on cleaning up the core and bringing in the features the users want. Funding developers would allow for a much more organized development cycle.

You say

“However, the decision was made some time ago to close the door on building new libraries into core and instead shift them to PECL. This was probably the right decision (who wants a bloated and increasingly difficult to audit core?), but it was implemented without considering the fact that the average PHP user has neither the knowledge or inclination to understand how to install and run external libraries that they can’t download in PHP form and include in their scripts.”

I say: For the average user this doesn’t matter. They get their PHP from a distribution. Distributors package each and every extension individually. So for them there is no difference between an extension we bundle in core vs. PECL (except for the few we force on). The only difference is that PECL allows simpler, short, better release cycles than big PHP.

For users using our distribution aka. building themselves installing from PECL shouldn’t be a big task. Else there’s a bug to be reproted in http://php.net/install.pecl

You also say “Rather, the problem is that there is no real way for these projects to provide upstream positive feedback to PHP core.”

I say that there are many ways. I talk to many people at conferences. Others do, too. I see many contributors to different projects stating their opinion on internals. I send out “head up” mails for RCs to different project maintainers and get feedback from some … there are channels. But that always requires interest in both ends – and well, project maintainers are busy in their project and often also their job and family … like are we, but what would we as core folks be without out users?

In a way its nice that PHP core is settling down. Other then a few things like full utf-8 support it would give the people who develop around the core a chance to stabilize instead of race to add new core features and support into their code.

I think a missing piece of this puzzle is that PHP has not cultivated a strong upgrade habit (or maybe relationship in general) with what I consider their most influential customers, the shared web hosts. The situation is similar to when I wrote my PHP5 essay in 2007 — even if PHP.next adding something that would be amazing for WP, we couldn’t require it for headline functionality for a long, long time.

… while that’s the old Hen & Egg situation, Matt. As long as “you” don’t push the requirement for a new version hosters can be conservative, while as long as you are conservative “you” can’t depend on it.

btw. there are some hosting companies offering a wider choice of versions … and I hope virtualization will make these things simpler – let the user decide … while I fear the times when even more bad administered vistual servers are online, being hacked, used for spam and other things …

Although I do not agree with the ‘complete mess’ I feel that a lack of a strong leadership, or at least a public one, can leave PHP in a stale state with individual developers doing what they think is more important instead of what should be really done.

Don’t get me wrong we always want to do what we think it’s funny/challenging but I feel that there should be a more (public) balance between new features (tip: native type hinting) and house keeping (tip: how about monthly hackatons like ZF does to reduce the bug count?).

My suggestions:
a) Define a strategy for the releases (ex. monthly 5.3.X releases with bug fixes only)
b) Consider the possibility of voting for the most wanted bugs or features and
c) Create a donation campaign to fund those that the initial maintainer does not have the time nor the intention to solve in a near future

@Mario and @JohnDoe I’ve seen funded development play out in open source projects (namely Joomla) and it can quickly get nasty. Although it would seem like a great way of getting code out more quickly, it opens up several cans of worms:

1) Who gets selected to work on PHP as a full time job?
2) Who gets to decide who gets selected to work on PHP as a full time job?
3) What does the coder work on? Features that get funded? Whatever desired?
4) Paid help on the team can demoralize the unpaid volunteers.

@Joe LeBlanc:

> 1) Who gets selected to work on PHP as a full time job?

Ideally, the same bunch of people that do it now. But it’s C code, so anyone up to the task can do.

> 2) Who gets to decide who gets selected to work on PHP as a full time job?

The existing developers, since they are the team.

> 3) What does the coder work on? Features that get funded? Whatever desired?

Right now, the development process is internals owned. This would have to be opened up to make it community owned to some extent. I like how ZF does it with their proposals. I like the idea of sponsors optionally being able to tie funding to a particular cause.

> 4) Paid help on the team can demoralize the unpaid volunteers.

True. But whether and what they keep contributing or not is up to them. They dont get anything right now for their efforts either. Contributing is idealism.

Granted, I dont have a clear concept of how all this could work out in reality. But I do think something like a crowdfunded PHP.org has potential.

in my opinion PHP is currently not at a state, where the core development should slow down. there is lot’s of stuff in dev, which should be released anytime soon, for example: the closure-implementation is still not feature-complete, even though it was released a long time ago. on the other hand, the language itself should be polished and logically enhanced.

i will never understand, why the parser complains about …

$a = (new x())->y();

… or …

(function() {
…
})();

these are only a few examples, where PHP — in my opinion — ist not intuitive enough: with PHP you are always thinking, what PHP is expecting from you — not the way round, as it should be (and is with other language). utf-8 support, would be very important, too.

what i dislike with the PHP development process is the veto, that some core-devs apparently have. if they say no-no, it will not get into the core — no matter, how many other developers would like to see it … i am not participating in the PHP core development, (because i don’t have the needed knowledge), but i am following the development process and reading php-internals for many years now …

Firstly: Be aware that there are paid developers already. Oracle is funding some work, Zend is, … smaler companies are. Some other contributors are freelancers and are sometimes being paid by their customers to work on PHP. If you need something you can always look for such a freelancer and pay him.

But that’s not happening from php.net but aside. For good reasons.

Doing this from within the php.net adds tension. What’s the relationship between paid work and non paid work? – Do we have to accept patches since somebody paid for it? Can we reject it? What if the paid worker delivers a “bad” patch and another developer then fixes it? Right now what matters is code.

And then there’s an additional issue: If somebody contributes something in the current structure he usually cares. Which means it will be maintained. A per project paid worker is more likely to leave it as is once he is paid and look for the next project, which leaves the rest of the community with maintenance work.

I agree to some extend. I also agree that the exciting new developments are mostly happing outside of core, simply because its has become possible to todo this. That being said traits will give this another push.

The good news is that this could mean that core might have time to work on the better unicode support we all have been dreaming about.

Now as for PECL/PEAR being a mess. I can only partially agree there. The issue is just that for various reasons both projects do not have the visibility that they should have. This in turn also means that they get less love from the general community than they need to be shiny. So the discussions I have seen popping up more and more over the last weeks might solve this situation if we all come together again.

Though I do not think we should constrain ourselves to think in terms of PECL/PEAR as it is today. I think we should instead think what we would want php.net to offer to us in terms of sharing additional functionality not provided by core. I think DVCS, reST/markdown, the trend towards better testing and continuous integration, addition of namespaces have changed things so fundamental that we need to start thinking from scratch.

Totally agree regarding PECL. If something is in PECL, I ignore it because I know I can’t rely on it being available.

I agree and understand for the most part on this post. I thought I would chip in my two cents and help by illustrating an “itch” I’d love to see scratched on my blog. I would love to see if there would be a way we could implement some form of Object Notation into PHP.

http://www.justincarmony.com/blog/2011/04/12/php-itch-to-scratch-object-notation/

David: As you can’t about most bundled extensions. they can be enabled or not …

Certainly no! Just look at Python and Ruby and their amazing implementations of simple concepts like List Comprehension and Closures. Next to Ruby closures, PHP’s implementation is child’s play. And useless.

If PHP is slowing down, then it’s finally time to move to another language, one that is interested in growing.

There’s so much developer momentum that there’s no concern of PHP going away, regardless of the speed of core development.

Nevertheless, I agree that the PECL/Pear paradigm is confusing at best. There’s great stuff in there, but it’s difficult to know what’s-what and even the official PHP docs are little help in that regard. Even Perl’s CPAN is more straightforward, and that’s not saying much.

@Johannes: True, I’ve been bitten by that a couple of times. But your typical shared host does include *most* of core. I guess the difference is that for the average PHP install:
I’m surprised when things in core are disabled.
I’m surprised when things in PECL are included.

However, the overall problem remains the same. If you need something that has been disabled, you need to compile and maintain your own PHP, which is not something your average PHP developer would do.

“the fact that the average PHP user has neither the knowledge or inclination to understand how to install and run external libraries that they can’t download in PHP form and include in their scripts.”

Either you are programmer or not. If you are, you know such things. If you don’t you are not a programmer. Learn. Or Gtfo.

I think the main problem for PHP right now is that PHP project has outgrown its management model, or, more precisely, absence of management model. It is not adequate for a language that millions of people rely on to be guided by random posts on the list and obscure chats with random participants on IRC. It is no longer adequate to not have a plan, a release schedule, a set of criteria for discussing and deciding on features, not to have any process or even understanding who decides what. Sadly, it appears as most of the project participants are too busy to even care about it, let alone do anything about it.
Because of this, if you have some good idea (or think you have), it is not even clear what do you do next – ok, you can write a patch, then what?

David, I have barely seen a hosting company offering bz2, com_dotnet, dba, enchant, gettext, gmp, interbase, ldap, oci8, odbc, pcntl, pdo_dblib, pdo_firebird, pdo_oci, pdo_odbc, pdo_pgsql, pspell, readline, recode, shmop, snmp, sybase_ct, sysvmsg, sysvsem and sysvshm. For many of them there are good reasons not to have them (com_dotnet makes little sense on linux systems etc.) still this are 24 of 75 bundled extensions, so by far not *most* being enabled.

You said: “Without anyone to force PHP in a specific direction, the language has evolved haphazardly but comprehensively, which is what makes it so appealing to so many”
I say: “which also makes it easy to write insecure code and open your scripts up to hackers”