Re: Package competition

Sergio Carvalho wrote:

Lukas Smith wrote:

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.

If a proper case could be made as to why the new API makes sense, then there is no problem. Usually its just lack of interest for cooperation. I know you are disgruntled and I really think that Daniel should somehow find the time to review your code, evne of he just comes to the conclusion that he disagrees. Understand that with the acceptance of the new major version the older one is implicitly getting deprecated. Maybe in the end we need to view your package as an alternate approach and not as a new major version. In this case we would need to find a new name. However questioning the key principles of PEAR in such an inflamatory way is not going to get you much further.

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.

You are wrong to believe that peer review ends at package acceptance. Alot of people comment on commit mails. Alot of people comment on usage. And we also have the QA team to assist in maintaing high quality after a package gets accepted.

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.

Sorry, but I disagree. The result would be less contributions. Less feeling of responsibility. Less identification with the code. And lot more confusion for users. The choice we offer is using PEAR or not using PEAR more or less (sometimes we offer different approaches). That is plenty of choice, users can look at hotscripts if they want even more choice. Maintaince of orphaned packages would skyrocket if we just open the flood gates and let in anything that looks like a short term improvement.

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).

While that is so, I think alot of people see some of the problems I list above. Additionally CPAN has been around just a tad bit longer. I recently wrote an article for phpmag that will enventually get released online for free, where I explain where we are coming from and why we have the fundamental principles, atleast from my POV. regards, Lukas