In this recent post to his blog, Chris Hartjes answers his request for a "rant topic" by responding to a question about "how to not suck at PHP" (from Travis Northcutt).

I thought about this question for a while and have some thoughts on what it really means to know how to not suck at building things using PHP. In my never even remotely humble opinion I think the key is to understand what PHP is really good at.

He talks about how PHP had the early-adoption advantage at first with Apache, but how things have changed so much since then. Now, he proposes, PHP's popularity and usefulness is based on what it can do as a language without messing with frameworks at all. He's worried that, once someone picks up a framework, it'll become so ingrained that they won't know what "plain old PHP" can do (or how to work with it).

So my advice to Travis is that he should worry about learning to use PHP like glue and correctly identify the problems he is trying to solve NOW instead of worrying about the problems he might have to solve later. There will be time to fix your problems. Some of those will be solved by using tools that are not written in PHP, but PHP can still glue them together.

In a new post to his blog today Anthony Ferrara looks at the (heated) discussion that's popped up around having the PSR-0 autoloader standard included as a part of the PHP core. He gives his reasons (three of them) why he's not for the decision.

Recently there has been a rather heated and intense discussion on whether the PSR-0 autoloader "standard" should be included as part of the PHP core (in ext/spl to be exact). I've tried to stay out of the discussion and have successfully done so. Until today. I feel that there's something that's been missing to the discussion. So rather then posting this to the internals list, I feel it's better served by a blog post on the subject. So here's my take on it.

As mentioned, he's not in favor of the inclusion for three different reasons:

• It's inconsistent with current PHP functionality and would bias development one way or another
• It's not an actual standard, just a loosely defined practice based on functionality already in place
• There's noting for core to gain by adopting it and could cause problems trying to make things fit a one-size-fits-all solution.

On the Agile Toolkit blog today there's and interesting article with a slightly misleading title - "How to Earn Money with Open Source?" It talks less about strategies of how to monetize your open source project and more about how other projects are doing it and why a good core team is important.

OpenSource is an amazing phenomena, but how safe open-source projects are? Would commercial project be safer over the community-supported project? Frameworks can't exist without their core team and In this article I look at how different PHP frameworks are supporting their core developers.

He talks briefly about the need for a good, solid group of core developers on a framework (or really any product) to provide a stable foundation if a product was created with it. Four projects are mentioned - Zend Framework, CodeIgniter, Symfony and Agile Toolkit - and why, because of the backing they have from a company and a large group of developers (and contributors) they're not "yet another framework" that'll disappear over time.

Making new frameworks is fun, however, if you share framework with others, be responsible about the support. Make realistic goals and try to have a plan for a next few years. If you are the author, think who will support the community when you decide to move on.

Kevin Schroeder has a new post to his blog today asking "Why PHP?" - not so much a "why you should chose PHP for your development", more of a why PHP is the way it is.

Today on twitter there was a conversation going on about the responsiveness of the core PHP developers to PHP users. [...] This post isn't necessarily to correct perceived errors, to stand behind correct statements, or to state what I believe the problem is. Rather, it is to add something to the conversation that I don't think I've seen much of. The Twitter conversation was, for me, more of a contemplation kickoff and so the purpose of this post is to propose some thoughts for consideration. I don't have sufficient karma to propose changes directly, but I have bet my career on PHP and I want to see it beat the crap out of every language out there.

He points out that most of the opinions out there seem to be of the "what" PHP is rather than the "why" PHP is. He notes that the discussions about the core development (and developers) that's been happening recently is more of a symptom of a larger problem - an unclear definition as to what PHP is and what problem it's there to solve.

Court Ewing has a (slightly inflammatory) post to his blog that shares some of his opinions on why he thinks PHP is broken and a few thoughts on how it could be fixed. He's edited the article since its first publishing to include some clarification of his original ideas.

Before getting into the original post, I wanted to a comment made in his edit with an apology for the original post coming across as more of an "irritated user" than an unopinionated observer.

PHP's development process has been broken for a long time, and the failures of that process have swelled since the first ripples began to appear many years ago. [...] This is no surprise given the very fluid history of PHP though, and the lack of any sustainable processes may have even been one of the key things that allowed PHP to evolve so quickly into one of the most used programming languages in the world. But that early success doesn't make the PHP development process any less broken.

He covers a few points where he has issues with the PHP project including the release management, test coverage and recent issues with bugs in releases. He gives suggestions on how things could be made better - a detailed release process, a voting process for new features and a emphasis on good code and tests in the core. He also notes that he thinks more contributors in the mix isn't the solution. While it's encouraged to join the project, he suggests that the current core development group are the ones that should work the hardest on making things better.

Be sure to check out the comments for some great responses from the PHP community - both for and against the statements from the original post.

In a new post to his blog Marco Tabini poses an interesting question - is PHP running out of itches to scratch in the evolution of the language?

think it's fair to say that the pace at which PHP core is being developed has slowed down considerably over the past couple of years, while the development of many projects based on it, like programming and application frameworks, has sped up and continues to grow at a fast pace. But this doesn't mean that we're running out of steam. The PHP ecosystem is simply refocusing outside of core, where it has a lot more freedom of action.

He suggests two reasons as to why this slowdown might be happening - first that there's not a sense of strong leadership in the core development group (a feature of the project done on purpose) and the change to move new library support out to PECL and PEAR instead of directly into the core of the language.

The risk facing us, as I see it, is not that Drupal, or WordPress, or whoever may decide to fork PHP or abandon it altogether. Rather, the problem is that there is no real way for these projects to provide upstream positive feedback to PHP core.

Elliot Haughin has posted some of his thoughts about the huge amount of changes the CodeIgniter framework project has been going through lately including moves to Bitbucket, the "Core" versus "Reactor" branches and how he sees it all as "rather messy".

It was just a few months ago that the CodeIgniter community began to explode with a torrent of frustration that CodeIgniter simply wasn't progressing as a framework. There were also a few prominent developers considering abandoning the framework in favour of more active alternatives. [...] Before we go patting ourselves on the back, and heralding the reactor as a great success, there's a much wider question we need to look at: 'Are people actually upgrading?'.

He notes that, based on his experiences, people don't seem to be upgrading to this latest release and that several people still see Reactor as a "beta" and not a viable upgrade alternative. He suggests three things he think could help - a good upgrade guide, a stop of support in libraries for non-Reactor codebases and encouragement to use mercurial more (cloning the repo).

The day has finally arrived for the CodeIgniter fans out there - EllisLab has officially released CodeIgniter 2.0.0 in two versions - the Core and Reactor branches.

Today EllisLab and the CodeIgniter Reactor Engineers are proud to announce the first official release of CodeIgniter 2.0.0, which is being released in two flavors.

The "Core" version will be the branch that EllisLab uses for their internal applications and will be a bit slower moving. The "Reactor" branch, however, is more community-powered and headed up by a set of Engineers that will guide the framework and work to make it its best. Also mentioned as new in the post are the upcoming ability for users to contribute directly to the user guide, the creation of a standardized Authentication library and a more object-like model setup. If you're interested in the Reactor branch and want to try it out or contribute, head over to the bitbucket account for the project.

Over the weekend Stanislav Malyshev asked a question on the StackExchange.com Programmers section as an open request to all of those working with PHP - what features would you like to have in PHP?

Since it's the holiday season now and everybody's making wishes, I wonder - which language features you would wish PHP would have added? I am interested in some practical suggestions/wishes for the language.

By practical he meant something that's possible, something that doesn't make PHP "not PHP", a change that would require breaking existing code and something that doesn't change the language or some "interesting aspect" of it. There's some interesting responses ranging from the completely coherent out to some ranty things like "I wish PHP was designed properly". Handy things like named parameters, dereferencing, syntax tweaks to make things more readable, unicode support and lots, lots more. Take a look at the full post and maybe contribute your own if you have some great ideas.

Phil Sturgeon, one of those selected to a spot in the Engineer group of the CodeIgniter Reactor community branch, has posted a few thoughts of his own about the moves EllisLab has made and the reaction from the community he's seen.

Since what some have referred to as "CodeIgniter-gate" EllisLab's have done a great job of listening to the points raised by me and other members of the community and in part I believe we have effected change. [...] Good news right? Hell yes. This is exactly what the CodeIgniter community has been looking for. EllisLab need to keep their core version working for themselves of course and have always suggested that if a feature is to be integrated then it needs to be heavily tested first.

He follows this with a "but" in the form of a few common comments from the community - unfortunately negative. He also mentions the UserVoice forum where developers can suggest new features and hash out ones suggested by others. If you'd like to contribute code, you can still fork the main repository for now and push back with pull requests.