The PHP development migrated to a Git repository. With the integration with GitHub it became easier for non-core developers to submit pull requests with bug fixes and new feature improvements to PHP. Will this new possibility make it PHP core developers accept more contributions from non-core developers?

The episode also looks forward to the next release in the PHP 5.4.x series (5.4.1) and some of the stir that a recent post (to PHPClasses) about OOP caused in the community.

You can listen to this latest episode either via the in-page player, by downloading the mp3 or by subscribing to their podcast feed.

We at php|architect want to honor those who give of themselves so that we can work with PHP and in this great ecosystem. We are standing on the shoulders of giants and want to pause to say thank you. The full details can be found on the Impact Awards page. Voting is open through the end of March and is open to all php|architect subscribers.

The categories for this year's event are "Up & Coming", "Best Cloud Platform" and "Best PHP Application Platform". Nominees across all of the categories include Joind.in, PintLabs, AppFog, Pagoda Box Drupal 7 and SugarCRM. If you're a subscriber, get in there and vote for your favorites!

PEAR is about providing the PHP community with reusable, effective components - this has been our mission since day 1. If there is anything we can do to make that goal happen, to assist you as an individual or company, I would strongly encourage you to let us know - we're here to help.

They mention the work of two individuals that have done good work on a specific package, meldra and Gemorroj - perfect examples of how the move to Github has made it simpler to implement changes that have been "waiting in the wings" on the XML_Feed_Parser and Image_Barcode2 packages.

If you've had changes you've wanted to make to a PEAR package in the past but haven't ever gotten them submitted, there's not a better time than now.

Code coverage tells you how much of your code base is actually being tested by your unit tests. It's a very useful feature, but sadly, it slows down PHP's execution quite a lot. One part of this slowdown is the overhead to record the information internally, but another part is because I have to overload lots of opcodes. (Opcodes are PHP's internal execution units, similar to assembler instructions) They are always overloaded even if code coverage is not used, because it's only safe to overload them for the whole request.

These changes were from a combination of contributions from Taavi Burns and a new ini setting that will allow you to enable or disable the code coverage in XDebug. Benchmarking shows a good amount of time reduction in coverage runs - dropping anywhere from a few seconds to over a minute. He also mentions the idea of "modes", shortcuts to predefined settings for different types of reporting (like "profiling" or "tracing").

CodeIgniter is a community driven project and accepts contributions of code and documentation from the community. These contributions are made in the form of Issues or Pull Requests on the EllisLab CodeIgniter repository on GitHub.

There's a few helpful hints on things like submission guidelines, the PHP style guide for the project, PHP version compatibility, which branch to submit requests against and a quick how-too guide on getting up and running with git/github if you're not familiar with it.

Let me elaborate on [an important] point: Contribution. Most developers i know care about producing good code, especially then they are contributing to an open source project! Those people will respect your coding standard, naming scheme and every thing else that they can check for before sending you all patch/pull request. So try to make that part easy.

He talks about doing things the hard way - reformatting everything by hand each time someone contributes - or the easier way of enforcing the coding standard as a part of the contribution flow. He mentions PHP_CodeSniffer and the PHP Mess Detector as a part of a Jenkins installation (easily built from this handy project).

robably the second most common reason I've seen projects fail is because the client fails to live up to their commitments. No I'm not talking about hitting your payment milestones, I'm talking about delivering your content.

Without everything they need to get the job done, the developer(s) cannot hit the marks you both laid out in the contract. Show them that you're committed to the project by delivering your side of things too.

Don't be the reason that it misses it's delivery date. Also, don't expect your developer to work extra hours to get the project back on schedule just because you failed to meet your obligations.

For the past four years, a group of enthusiasts have been organizing an unconference about PHP and related web technologies in Hamburg, Germany. What started off as a gathering of only fifty people, has grown over the course of three years into an event, which has received much following and attention within the German speaking PHP community. [...] The mission of PHP Unconference Europe is to bring together an international group of around 200 people, who have detailed knowledge of PHP and related web technologies.

For 2011, they've set up the European unconference to provide a whole new group of those with tech-related interests to come together and present the topics they want to hear about. Contribution ideas can be made via their Contribution System. Topics already suggested cover topics like Phing, document generation with the Zend Framework, project management and working with spreadsheets in PHP.

The tickets are already on sale, so if you'd like to attend, pick yours up and reserve your spot today! The cost is £40/46 Euro for the two day event.

Leaders of the open source community are always trying to encourage others to contribute. Volunteer contributors are always in short supply, and most open source projects are driven by volunteers, so recruitment is a big component of any open source project lead.

One of his main points to add to Elizabeth's list was that the architecture of the application matters. He gives an example of a project (the Phergie IRC bot) that is well-architected and makes adding in new plugins simple because of planning. He also shares a few other suggestions to help encourage open source participation like good documentation, good involvement from project leads and mentoring the "newbies" to help get the ball rolling.

Open source developers don't write FLOSS applications because they have to, they write them because they want to. Motivation is not always driven by money, most of the time PHP developers do it for the joy of it.

He lists some of the motivation factors behind the work that a lot of PHP (and Open Source) developers do for and in the community like the potential to learn, credibility/notoriety, sense of purpose and the possibility of a financial reward. He also includes just a few of the Open Source projects PHP developers have contributed to the community such as WordPress, Magento and Gallery.