Hi, Starting with the thesis: "The way contributions are managed now is not suitable anymore. Esp. modules are growing out of hand, not only the amount of modules, but mostly the way modules conflic,t overlap and even completely duplicate one-another is a problem." We can only fix that with some effort and rearranging the way we handle contribs. I do not beleive we can solve this with code, or extra features on drupal.org. Allthough that might /help/, the real solution lies in management of this project. Note that I am /not/ (yet) addressing the part where users cannot find approporate modules for downloading: frankly I don't (yet) care about these users: they should just look better. Once we manage the contribs better, we can look into that. If it is still neccesary then. I see a couple of solutions, but I will only deal with one, here: bundles: definition: A bundle is a group of modules that have features in one area. A bundle is not a subcalssification of single modules, but a single entity. A bundle has only one project entry on drupal.org and it lives in one directory (+subdirs) in CVS. It is therefore downloadable as a complete tarball only. Modules in a bundle should be: * aware of oneanother. If A.module is anabled, B.module can hook into that, or use additional features, in addition to the features A.module already delivers. * reusing APIs. No duplication of code, re-use of optional .inc files. * never conflicting. enabling module A should never mean module B starts spitting errors. Module B should know that it must "shut off" certain parts, when module A is enabled. * Reusing databse tables. Currently most modules have private tables, tables that even often confilct with others. Weblinks, for example, should be stored in a single (set of) table(s), where all weblinks-realted modules (in the weblink bundle) will store and get their info. It makes no sense if relatedlinks.module stores weblinks in tableA, weblinks.module in tableB, blogmarks in tableC, flexinodes url.inc in tableD etcetc. The e-commerce modules are a good example of this. For 4.6 we hope to have weblinks into a bundle too, this would Project management-wise a bundle would imply collaboration of a few developers. These developers must communicate amoungs eachother, they should use a separate directory in the sandbox CVS area as well as devide issues and features amoungst eachother. Pro: modules within same range of features can be managed in a central place. Pro: modules within same range of features can be found in one central place PRo: modules within same range of features will work together. Together they make a single and *complete* set of functions. separate managed modules (what we have now) often have a lot of simil;ar features. Take for example amazon_serach.module and amazon_items.module both offer some way to add amazon ads to your site, both allow some amazon content to be published on your site, but features differ slightly. Also, they use some moduified 3rd party .incs, which are not shared, buyboth modules. Ideally we would split them up and have: * one module that handles all ad-serving from amazon. * one module that handles content serving. so thogether they make a complete system, instead of having to conflicting modules. Con: Contributions of custommade modules is impossible/hard. If a module was developed for yoursite.com only, it will most likely not fit within one of the bundles. Question of course is, if we should host these modules at all. Con: Second-level discussions need to take place. So some small mailinglists, or even simply a list of CC-ed mailadresses are needed for each bundle. I beleive this is no real problem as yet, in future some module on Drupal.org could take care of this. Con: It is hard to manage. esp because of the open nature of the contribs. WE cannot dissallow people to contribute their custommade.module ATM, and we will not be able to implement such a thing soon. Thus the bundle systems would require common sense and good agreemenents between contributors. Con: a user will have to download a complete bundle (lets assumne weblink bundle) even if she only wants to have relatedlinks.module (which is part of the weblink bundle). So, please tell me what you think of this idea, and if it is worth discussion on drupalCON, or even on the lists only. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]