On PEAR quality issues and natural selection

Greetings, I had a "gut feeling" that something is not right with the PEAR QA team proposal [1], but wasn't able to verbalize it. Fortunately I came across a nice PEAR-bashing thread [2] in "PHP - Theory and Design" forum [3] which gave me a lot of food for thought. So here's what's wrong: The proposal tries to address the symptoms of the problem (unfixed bugs) instead of its cause. Now, what is the cause of the problem? Let's quote the two most interesting posts from the aforementioned thread, they were done by people well-known in PHP community, not the usual ignorant PEAR-bashers: Selkirk writes:

Another problem is that PEAR can't decide what it wants to be. Is it a library? Is it an application framework? Is it a loose collection of libraries? If you look at their five template implementations, you might think its a collection of libraries. Quickform implements validation, and so does a validation module. On the other hand, some attempt is made to have a cohesive whole.

lastcraft adds:

Unfortunately there is real rot within PEAR culture and I don't see it being sorted out any time soon. The fundamental problem is that it doesn't really know what it is. If it was a public package repository (like CPAN) then it would at least have potential. The trouble is that in the hope of getting reuse they have instituted a dev discussion list in which you have to get 5 votes and duplication of function is not allowed. The result is that the first person to announce does a land grab on a package. It doesn't matter how good a follow up package is, it won't get in. The voting system doesn't help either. I had the dubious task of monitoring pear-dev and it was painful. The other attendees will give the most cursory look at an incoming package. They usually don't understand the objective, find some relatively minor piece of duplication and then reject it. Some excellent work has been rejected by this self appointed club. MDB is a superb package, but had a hell of a job getting because of DB (fortunately it did succeed, not helped by the original author). To make matters worse unscrupulous owners can claim that a package actually falls under their own remit and they were going to release something anyway, again causing rejection. This is M$ style preannouncement. I have been a victim of this and I saw two other instances in three months. The only hope is usually to submit a nearby package and sneak something useful in under the banner. PEAR has this idiotic sheme because it also thinks it is a class library. Class libraries are not made this way, they are reworked by small talented groups. Class libraries are achieved by refinement and refactoring. You can only have refactoring with tests and shared ownership. That's when you get reuse and quality.

Now, how does this relate to the unfixed bugs? Simple: package maintainers do not feel *pressed* to fix them and no one else is allowed to. If the maintainer knew that having a bug opened for too long (especially with a diff attached) will eventually result in a proposal of a forked package with this diff applied, he will be much faster in applying it. If he knew that failing to respond to feature requests will lead to another package appearing which implements this requests, he will be more willing to allow a new contributor to work on "his" package. The solution: be honest and call the current PEAR a public package repository, remove the "no competitive packages" rule. The rule was not strictly enforced anyway: we have 2 DB abstraction layers, 5 template packages, 3 form handling packages and so on. Sometime after this "PEAR The Class Library" (PEAR Foundation Classes, PEAR2, whatever) can be created. The packages will be accepted into it from base PEAR on author's request, if they conform to a defined set of rules (stable status, fully documented and having a full test suite). The package ownership in this library will be shared (so the author loses some exclusive rights) among the developers who have the packages in the library --- thus an automatically created QA group of competent developers. Well, I am going to write an RFC for allowing competitive packages and publish it via PEPr. [1] http://marc.theaimsgroup.com/?l=pear-dev&m=108122891710123&w=2 [2] http://forums.devnetwork.net/viewtopic.php?t=17235&start=15 [3] http://forums.devnetwork.net/viewforum.php?f=19