Re: On PEAR quality issues and natural selection

Hi, Yes, perhaps my post was too extreme and may have clouded my intended meaning. Also, my criticism was not backed by any suggestions, so I'll trey to do that too. Lukas Smith wrote:

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.

Are you sure this observation still holds true since the creation of the PEPr system?

Yes, absolutely. From my perspective PEPr has changed nothing about what gets accepted or rejected; (Do you think it has?) it's just made the process more systematic. It hasn't even changed who can vote, has it? I guess I'm basing my criticism on the idea that PEAR is not an open community -- far from it. I do not see anything coherent about the libraries that PEAR provides and yet I see a lot of selectivity in what gets allowed to be part of PEAR. My suggestion is this: allow anything that meets basic documentation and code quality requirements to be part of PEAR.

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.

I am sorry about the ZZ/OSS installer it simply no replacement. It doesnt handle PECL at all. It also doesnt have a command line interface. It does application handling very well. We will try to get there too. Channel support is being worked on as the next big step.

ZZ/OSS is not there yet, true. I mentioned that it's missing the CLI component, but it will get there -- and it will be better than PEAR's installer precisely because it is OPEN, because I can create a repository of DB-related PHP5 applications and other people can mirror them. This is a far superior idea (IMHO) to the controlled-repository model that PEAR provides.

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)

Wow that is harsh. However if you think that BC is BS then appearently you have a different vision indeed. if you think the QA team is the "big brother" then I can even less understand your reasoning. But I guess while PEAR strives to be for everyone, reality seems to tell me that it may strive towards this but it will not reach this goal.

I didn't say BC was BS, but I did say that PEAR's BC requirements and recommendations are crippling. The idea that Daniel fixing an obvious bug in DB broke backwards compatibility is ludicrous. Why should he have to commit to sloppy API until next major release just because some developers made errors that happened to work with an older DB version? That's crippling code quality. That's more of a tangent to the topic, though. I'm also less concerned with the QA team, really. I think the problem is more that there needs to be such a team at all -- see below. PEAR does not strive to be for everyone! If it did, it would be a far more open community. It would accept packages regardless of whether they were "almost the same" as existing packages. It would ensure that anyone who had taken the time to write clean code and document it could have their package available through PEAR. This is operating under the "more open" assumption rather than the "more controlled" model (e.g. of JFC).

From all I have seen most proposals actually make it into PEAR.

Even if that's true, imagine how many more people would be making proposals if PEAR weren't renowned for being an ego-driven, closed community? Think about all the PHP tools out there ... why are so few of them PEAR packages?

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>

This is a good example of where I would have hoped for the developers to cooperate with the developer instead. Alot of what these packages do overlaps with DataObjects. Of course they are different in some ways. But these differences could have been merged into DataObjects. Instead the developer chose to push their implementation.

Yes, I don't see DataObjects integrating these changes. This brings me to another point, though; a lot of the competition would be removed if there was less ego on PEAR. Another way of putting this is that anyone who is a developer on a project should be allowed to commit changes to that project. This is also related to the bugfix issue.... why can't anyone who is granted developer status on a project fix bugs on that project!? I highly encourage anyone working on my projects to fix bugs. They don't need to "ask me permission" to fix documented bugs; this is ludicrous. Obviously the direction of a project needs a manager, but it doesn't need a micro-manager. Cheers, Hans