Re: On PEAR quality issues and natural selection

Hi - I just had to add my .02 here, since I've also felt pretty disappointed in PEAR. Sure, on one hand I don't contribute to PEAR & so I don't really have a right to complain. But on the other hand, PEAR does have a responsibility to represent the PHP community, and I'd say that the image PEAR portrays is not one I'm proud to be associated with in any way: it's one of fragile egos picking apart great contributions in the name of making things consistent with a vision that doesn't exist -- except apparently in the minds of the people rejecting proposals. Paul M Jones wrote:

A solution? Make PEAR a package manager/installer. Also a public repository in charge of namespaces. Insist on complete test coverage and documentation rather than rejecting on grounds of duplication. If a module became unpopular or has too many a bug, record this fact and make it public. Let the library self select.

http://forums.devnetwork.net/viewtopic.php?t=17235&start=15 (lastcraft, Sat Mar 06, 2004 2:50 pm) I have to say I like this idea. It is, of course, a complete re-purposing of the PEAR ideal. But it would open up both the competitive fronts while at the same time retaining quality standards (coding standards, documentation, etc).

I think this is absolutely a good idea and if PEAR doesn't do it, someone else will. ZZ/OSS is about to release a package installer that will provide for installing packages from remote systems; people will be able to create their own repositories of PHP apps or mirror existing repositories. This is a huge advantage over PEAR, because it truly makes package distribution a *community* affair. PEAR is anything but a community. All that's missing right now from ZZ/OSS is the commandline installer; I want to help build that using ideas from Phing,-- only wish I had more time. <rant> Why would anyone want to go through the minefield of egos on PEAR-DEV to get the PEAR stamp of approval when they can distribute their application using other means? I for one, have no idea what the "PEAR stamp of approval" adds to a package other than a stigma for bloat, crippling BC-requirements, over-rigid styleguide, soon a "big brother" QA team, and a very basic distribution system -- seemingly soon to be made a dinasaur by ZZ/OSS. Some of those are harsh words, but I have to say that I have also seen tons of great packages get rejected. I don't know what business PEAR has rejecting good work on the grounds of duplication, since clearly PEAR has little or no coherent vision for what it's class library should provide. (and that's just a re-iteration of that same sentiment expressed in the forum) Many tools like DB_OO and DB_Table are extremely useful (at least for a certain audience) and could have been made widely available to many people by now, but have not been because authors of other PEAR packages feel that they duplicated code or competed with existing packages. So what? To use a recent example, the Maketext package is certainly a ludicrous idea from a linguistics perspective, but I think it would also be really useful for people who wanted to translate within a language family (e.g. Indo-European) and so I definitely think that it should be allowed into PEAR. Afterall, it's a port of an existing (and apparently successful) Perl package. </rant> Anyway .02 from someone who is not a PEAR contributor -- and honestly has no plans of being one, given the way it works right now. Of course, this is not a criticism of the packages on PEAR. I certainly use PEAR packages like Log and Benchmark and PHPUnit2 routinely; these are great tools. I would also have included in that list DB_OO if it had been accepted -- and definitely PHPTAL, which is an aweseome templating engine. Hans