Why open source works...

A couple of recent examples in the PHP community have reaffirmed my faith in the open source development model: the PEAR proposal process, and the delay in the 5.2.0 release.

Example #1: PHP's PEAR project

Over the past month I've been working on a couple of PEAR proposals (File_MARC and Structures_LinkedList). When the first proposals went public, I waited anxiously for floods of positive feedback and constructive criticism. Heh. After a few days of near-silence, I waited anxiously for any feedback, then poked around on IRC (#pear on EFNet) to see if anybody was awake. Well, it was the end of summer in the northern hemisphere, so perhaps I was being a bit too hasty...

The feedback started coming in, and it was right on target. Comments ranged from improving the coding style to stay in step with PEAR coding standards, to name changes to allow other (as-yet non-existing) variations on my packages to co-exist in the future, to possible improvements (type hinting, yeah!) and plain old corrections (object reference hangovers from an earlier PHP 4.x cut at the same project). As a result, I am much more confident in my code, and I'm almost ready to put the proposals out for a vote. So thank you, PEAR folk, for using your eyeballs and brains to surface the bugs and help me improve my code.

Example #2: PHP's filter extension

The release manager was just about to roll what he called the final release candidate of a brand new minor version increment of PHP -- 5.2.0 -- when I noticed that the function names for the new core functionality of the filter extension didn't follow the PHP coding standards. Given that this is an extremely important addition to PHP (it helps application developers improve the security of apps), I sent an email to the PHP internals mailing list asking whether the function names should be changed to follow the standard, provided a suggested set of changes, and offered to create a patch that would implement the changes. The suggested set of changes gave people something concrete to chew on, and although the suggestions will probably be thrown overboard in favour of shorter names, it served to illustrate the problem to light.

In a commercial organization, such a late request for changes to enhance usability in the long term [STRIKEOUT:wouldn't stand a hope in hell] would probably be filed under "future considerations". But in the open source world, even the co-founder of one of the commercial entities that depends on PHP-related services for revenue recognized the problem and recommended delaying the release until the problem was resolved. At this point, it looks like the primary filter developers are close to agreement. In the end, I believe common sense will prevail over the imposition of an arbitrary deadline. Props to the PHP developers.