Thanks for the excellent input Ben! > 1. Have a core team managing the namespace, testing, and > telling people about duplicated functionality. Does CPAN do that? I see a lot of duplicated functionality. not that that's a bad thing, different strokes for different folks I always say. But a nice summary of similiar modules by an impartial would be nice (witness the numerous templating modules on CPAN... how do you pick?). > 2. Have a standard tool ("perl -MCPAN -e shell") to interact > with CPAN. Agreed! What makes it *king* is the dependency checking and automatic installs of dependencies. (although it doesn't always work...) > 3. Have the standard installation save important local > information in a way that module authors can use. you mean for bug reporting? > 4. Have a standard directory layout decided at installation > for where things go. agreed. key. > 5. Have a standard method of inlined documentation, > automatic regression tests, etc. key. especially the regression tests. > 6. Have a standard packaging tool (h2xs) for producing > modules in a standard format. (Making the entire > "make Config", "make", "make test", "make install" > process standardized across modules.) would probably have a huge impact on people placing their work on RAA. the biggest drag is getting something "distribution ready" pure grunt work, rubyites (and perlites) don't want to be bothered by such drab work. > 7. Have a standard way to check versions, state > dependencies, and so on. Do you mean that the user could say: puts $class.version; $class.depends ? > 8. Have a standard tool to check whether you have > indeed done it right. okee dokee > 9. Have a standard bug reporting mechanism for installed > modules. Amen. I'd add the obvious: good search mechanism and good hierarchical organization. CPAN has that (although it does break more than it should IMHO). Also, I know there is a movement to categorize applications as well as modules on CPAN. That is also a good idea. -joe