Re: mission statement thoughts for PEAR

Greg Beaver wrote:

Users: PEAR should be a repository of high-quality, well-documented code. PEAR should provide self-contained libraries that can be used to implement solutions not already built into PHP - PEAR should extend PHP, not duplicate it PEAR should provide PHP-only alternatives to non-standard extensions PEAR should provide full-scale applications to handle infrastructure-related PHP needs (phpdocumentor, etc.) PEAR should require a high barrier to the "stable" label, requiring full docs, full unit tests, and API review PEAR should have an easy-to-understand and community-based review system of all packages PEAR should seek to support PHP development in general by concentrating on interoperating with other solutions out there, such as eZ Components, Zend Framework, Cake, Symfony, Solar - to make it as easy as possible for users to switch and to coordinate libraries from different sources.

I agree. My dream is also that PEAR will eventually also be looked at when PHP internals decides to integrate functionality into PHP itself. We currently have very little of this (PDO, Date, Filter, HTTP)

Developers: PEAR should be a hotbed of innovation as well as a source of stable code, supporting and rewarding active developers with fame and space to host and to advertise their code. PEAR should encourage cooperation between developers to provide simple, unified API coordination so it is easy to plug in any PEAR library. PEAR should provide an "alphaworks" where there are looser restrictions on entry

I do not think we should have an alphaworks. There are plenty of other places where you can tinker with alpha code/ideas. If they are not yet sound enough to be adopted by the PEAR community, then so be it.

PEAR should provide mini-communities within PEAR organized around like packages (all HTML processing packages, all PEAR installer infrastructure packages) where developers can coordinate better, and support this within the pear.php.net website.

I think the key thing that should change for developers is that we move to a more hierarchal structure in order to cope with the ever increasing number of developers. This means every category should be a subproject which appoints people that can work on decisions for all of PEAR. Currently its very difficult to ever get any sort of agreement. Its more a question of by sheer luck only having people active on the list that happen to agree and not because there is actually agreement in the community. Aside from that I think we should become more proactive when it comes to adopting new major versions of PHP. Based on the mission statement that PEAR should extend and not duplicate PHP, we should start with a clean slate for every new PHP version. The old code should be made compatible as much as possible of course. But we should use every new major version as a point where we throw out anything where we duplicate or where we rely on deprecated functionality and where we push the limits of what can be done with all the new shiny goodies in the given new major version. regards, Lukas