About PEAR site's package process

Hi folks, I am Yo-An Lin, the author of Onion (PEAR package builder) https://github.com/c9s/Onion. Since from Perl, I noticed that there are not so many packages on pear.php.net or even on pear2.php.net. Till now, there are about 600+ packages on pear.php.net, but there are more than 100000+ modules and more than 9000 authors on the CPAN site of Perl. the numbers are from <http://search.cpan.org/>. I found the main differences are: 1. users can easily register account on CPAN, and upload their modules easily and free, there are no proposal process to proof module authors patience, and the modules can still can be reviewed, rating, given comments, to improve the quality. 2. to use a CPAN module is quite easy, you can review the api design from the synopsis document section at the main page of package, then check if it's good enough to use. like this: < http://search.cpan.org/dist/Moose/lib/Moose.pm> the Object-Oriented System. 3. CPAN tester site, which tests all CPAN modules, and generate a matrix test report (with different Perl versions and Platform), since PHP5.4 has big improvements and changes, package testing on different languages and platforms are very important. < http://www.cpantesters.org/distro/M/Moose.html#Moose-2.0401> And on PEAR site, if people want to upload a package, they have to post a proposal for this, and keep waiting for a review or discussion for days or weeks, this makes package uploading process longer. though this could filter out some ugly packages. but most people will lose their patience, and not going to upload new packages again. I deeply want to help the PHP PEAR ecosystem, I think there are 5 things need to do: 1. remove the proposal process and let packages can be review or rating. (let the packages be eliminated through selection and contest) 2. pick up an easier document format like Markdown for describing synopsis and tutorial, release note, change logs for packages. (keep the PHPDoc for API reference) 3. provide tester for reviewing package quality. 4. quality testing, use phpcs PHP_CodeSniffer to detect violations of a defined coding standard. 5. separate packages by vender names (this won't pollute global package name), let people can define their dependencies with vendor names. Once the process is improved, people will come to PEAR to release their packages more and more. There are many good references for this, like CPAN, or RubyGems. CPAN: http://search.cpan.org/ RubyDoc: http://rubydoc.info/gems , http://rubydoc.info/gems/abcrunch/0.0.5/frames RubyGems: http://rubygems.org/ Thanks :-) -- Best Regards, Yo-An Lin http://github.com/c9s