PEAR has had a lot of issues, but recently the PEAR community is addressing them. For instance you do NOT have to deal with the PEAR process if you want to use PEAR to distribute your code. You may setup your own channel* and do whatever you please. Secondly PEAR is in the process of setting up it's packages at Github to make it a lot easier to collaborate on code.
I think these changes are great and PEAR's future is looking a lot brighter due to the people driving these changes.
*Personally I think it's a good idea to have some kind of vetting process in place. If you look at for instance the WordPress plugin repository as an example of a repository without it you'll notice loads of crappy plugins or abandoned code. I presume that with a vetting process (and maintainer process) one could prevent this from happening.
The process of adding channels and installing from them isn't too bad, but it's still additional friction. You can't do "pear search foo" and hope to find what you're looking for. Moving system-to-system you have to re-add all those remote channels you depend on.
Moving to Github is a good move. Opening up some sort of "PEAR commons" where the requirements aren't as arduous as PEAR proper would go a long way.
When package dependencies are tracked explicitly there's a very natural, Page-rank like effect that pushes the best, most reliable packages to the forefront because everyone depends on them. Just look at npm's "most depended on" list: http://search.npmjs.org/ You can look at any package and see what other packages depend on it.
PEAR's curation process feels a lot like Yahoo's of old's curated link database. npm's feels a lot like Google's "anyone can publish, we'll track dependencies, the good stuff will surface".
Comments
PEAR has had a lot of issues, but recently the PEAR community is addressing them. For instance you do NOT have to deal with the PEAR process if you want to use PEAR to distribute your code. You may setup your own channel* and do whatever you please. Secondly PEAR is in the process of setting up it's packages at Github to make it a lot easier to collaborate on code.
I think these changes are great and PEAR's future is looking a lot brighter due to the people driving these changes.
*Personally I think it's a good idea to have some kind of vetting process in place. If you look at for instance the WordPress plugin repository as an example of a repository without it you'll notice loads of crappy plugins or abandoned code. I presume that with a vetting process (and maintainer process) one could prevent this from happening.
The process of adding channels and installing from them isn't too bad, but it's still additional friction. You can't do "pear search foo" and hope to find what you're looking for. Moving system-to-system you have to re-add all those remote channels you depend on.
Moving to Github is a good move. Opening up some sort of "PEAR commons" where the requirements aren't as arduous as PEAR proper would go a long way.
When package dependencies are tracked explicitly there's a very natural, Page-rank like effect that pushes the best, most reliable packages to the forefront because everyone depends on them. Just look at npm's "most depended on" list: http://search.npmjs.org/ You can look at any package and see what other packages depend on it.
PEAR's curation process feels a lot like Yahoo's of old's curated link database. npm's feels a lot like Google's "anyone can publish, we'll track dependencies, the good stuff will surface".