Recently, PEAR went out of beta. Here is an announcement excerpt :

The PEAR development team is proud to announce that PEAR finally is out of its long beta period. As of PHP 4.3, the PEAR installer is installed by default. Unix support is considered stable, while Windows and Darwin are still of beta-quality.

I'm still not convinced by the PEAR initiative. There is at the moment 5 database abstraction layer, 2 templating solutions, 2 internationalisation package (not classified in the same category) and 2 tools for documentation generation (not classified in the same category). As always in open source, effort duplication is the norm. The PEAR core contains the package management and error handling... My feeling about this is that the error handling must be provided by the language, and this kludgy solution only brings confusion. Of course when the PEAR effort started, PHP5 was not in sight, but there was no reason for such twisted things.

What annoys me more is that since PHP doesn't have any notion of packaging or namespacing, I'm reluctant with this notion of package. All the "packages" are based on the assumption that they are physically located in the include_path, which tends in the real world to have all your files in one directory: messy. Last rant, where is the documentation? There are 2 documentation generation tools, and there is no online documentation? What's great with CPAN (PEAR's goal is to be the PHP's CPAN), is that for any package, you have API documentation and a synopsis.

As always I expose cons first, so let's start the pros. The PHP community is not really a community, because PHP is too easy. There are no initiation rites like in Perl, nothing to make you feel there is a right way. First you have two ways to extends PHP: modules (GPL forbidden, thanks Zend), written in C, and PHP code. There are more than 100 official modules as of today. This is the extension reference, and since the PEAR packages are treated differently, they can not be considered as serious as the modules. On the other side, much more PHP code is written daily than modules, and it would be sad to not organize this stuff. PEAR is an attempt to do this, and as such it has to be supported. Since PEAR's primary concern is PHP code, it could well in the future become the basement for a coders community. The maintainers have contributed enough code to not be lamely attacked by me, but long is the road. Perhaps PHP is a too loose language to really work well with a central code repository.

Not many pros in the previous paragraph, may be I'll find stronger argument for it.