Package competition (was: Ajax PEAR package)
| From: | Sergio Carvalho | 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
>