Package competition (was: Ajax PEAR package)

From: Date: Wed, 13 Jul 2005 19:45:46 +0000
Subject: Package competition (was: Ajax PEAR package)
References: 1 2 3 4 5 6 7  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-38620@lists.php.net to get a copy of this message
Lukas Smith wrote: > Sergio Carvalho wrote: > > We sometimes do deprecate old packages, like phpdoc. Generally the aim > is to make the packages that get accepted fairly well designed and > flexible, which usually allows interal refactoring to improve the code. > > Furthermore the no overlapping code is not triggered when something > tries to achieve the same thing with a new approach, that approach can > be smaller footprint (see Cache_Lite) or with a broader scope (see > MDB/MDB2). A new approach can simply be a new API. You know, as I do, that a new package with a simpler API than one in PEAR would be shot-on-sight rejected. Not that I'm defending an open acceptance of packages that differ in API only. That would lead to excessive fragmentation. I'm just pointing out that PEAR leaves competition out of the equation for package quality. Without competition, there's little incentive to keep quality -- since peer review is done at package acceptance only. Forfeiting competition seems to me plain wrong. Were there competition for developers to hold a slot (package name) in PEAR, and most activities being discussed as PEAR-QA would happen naturally, as peer pressure brings top-notch packages to the top. PEAR would soon have all packages documented and all packages following newer guidelines as they appear. > Anyways .. I dont see the problem. Play with it or not. If you need > motivation about PEAR and its success look at the stats page and realize > we were below 10 million earlier this year: > http://pear.php.net/package-stats.php Thats one view. Another is to compare PEAR's success with CPAN's. CPAN has much much higher visibility among perl developers than PEAR among PHP devs. Cpan has reached the point where it is considered *the* source for perl packages, where the same can't clearly be said about PEAR (one needs to look no further than this thread). I honestly do not believe I can change PEAR's no-overlap policy. The current model works, and most people resist change. However, the failure to recognize that PEAR could fly much much higher shocks me. Don't take my criticism negatively. I highly appreciate PEAR's success. I appreciate it so much I'd like to see it get better than it is. I prefer to look where can we be, not how far we came. Cheers, -- Sérgio Carvalho > > regards, > Lukas >

« previous php.pear.dev (#38620) next »