Is anything working in PEAR?

Yes. If you have been living on a desert island and haven't already done so, it's time to take another look at http://pear.php.net to see what is up.

Newly elected PEAR Group member Josh Eichorn posted a blog entry, "How would you improve PEAR" recently. I was impressed with the response, it seems many people outside of PEAR are monitoring it and have thought about how to make it better. However, I was also not so impressed with the poor job we've done letting people know about the newest improvements to PEAR. In my comments, I listed as many as I could think of, but Josh pointed out that I would do well to post these comments in a more public setting, so here goes.

For those who are wondering, most of the suggestions made in the comments to Josh's blog entry are in fact already implemented or in the planning stages. There is really only one that is not:

1. SVN. CVS is here to stay, as we are dependent on cvs.php.net. HOWEVER, someone willing to donate dedicated hardware would pique our interest in having optional subversion hosting.

Things that are implemented already:

1. pear installer is capable of modifying php.ini, but it does require a binary package to be created with the dll.
2. PEAR_Exception is the error/exception base class.
3. Mentoring. The new constitution (http://pear.php.net/manual/en/constitution.php) requires mentoring of new developers.
4. package tags. This was recently implemented, in anticipation of the new collectives, and other useful purposes.
5. deprecated/unmaintained packages have been supported for a while now (see http://pear.php.net/DB for an example)
6. lightweight packages. See http://pear.php.net/MDB2 for an example. All of the database drivers are decoupled into subpackages. Structures_DataGrid is the most complex example of this de-coupling. The technical capability was not present before PEAR version 1.4.9 to handle this properly, and so most packages have not yet implemented this functionality.

The social issues are a real problem. I plan to make this my primary purpose as the PEAR president, separate from my work as a developer. We'll see how it goes, but I see a strong momentum shift in the makings here, which has been my dream for several years. It's exciting to see it moving forward so dramatically. I hope that more developers who see the potential and the things that can happen will join, it is only through the force of the will of people who believe in things like civility that PEAR will shift its culture to one that encourages innovation as well as stability.

One thing you can currently depend upon in PEAR that will never be changing is that packages marked stable will always work in a similar way, such that you won't find applications based on them suddenly breaking on upgrade. Innovation can always be provided without destroying the work of your users. Stay tuned for details of how things will be changing.

One of the paths that PEAR is actively recruiting developers for is converting a few key packages into new PHP5+ based code  (this means you). For example, HTTP_Request is a commonly used package that needs to be re-coded for PHP 5. We need a good database abstraction layer for PHP 5, and the PEAR Installer is almost ready for its next incarnation (codename Pyrus), details are on the roadmap (yes, another new feature of PEAR) at http://pear.php.net/bugs/roadmap.php?package=PEAR for version 2.0.0, and code in CVS at http://cvs.php.net/viewvc.cgi/pear-core/PEAR2. If you see a feature that you would like to implement, grab yourself a new account, assign it to yourself and upload a patch (yes, another new feature of PEAR).  If you do not already have an account, head on over to http://pear.php.net/account-request-vote.php.  This form can be used to get an account for voting in general elections as well as opening and commenting on bugs or uploading patches (yes, another new feature of PEAR).

It's a good time to get involved with PEAR, there's a lot of renewed vigor, and no ceiling in sight.