Hi fellow drupal devs, wanted to bring up a few points about module development for some time and i guess now that module development happens to be the hot topic of the day would be a good time.. While D6 is proving to be a great success and through contrib modules can be flexibly expanded to almost unlimited use case customizations, working with a whole bunch of modules on our site my experience is that quantity is not necessarily a good compensation for quality. Several problems just keep coming up: - modules spamming the watchdog table with E_ALL warnings - modules ignoring the style/documentation guide lines - applied insane programming(TM) techniques - undescriptive module names but by far the most serious one is - duplication (partial feature overlap with existing modules). There might be different perspectives on this but IMHO specifically for D7 this is not a good way to go. An example for this mess is the huge number of competing notification/subscription modules for D6 - each with a destinct feature set and of course incompatible to all others. While competition is a good thing, certainly having multiple similar D5 modules live on and slowly creep up the version ladder while fighting for the same 'market share' is hindering real progress (=feature innovation, code sanity and API excellence) more than it is promoting it. If we want D7 to become *THE* perfect open source CMS, maybe a change in the module development process can help guaranteeing a higher level of code quality. One possible option could be to go some steps towards the linux model, in which all patches have to be signed off by a small team of core developers. Drupal would not have to choose an official team of reviewers though - patches could be confirmed by a simple voting system, in combination with the already working automatic testing. The issue tracking system could be optimized for reviewing/auto testing/auto committing patches (more code centric). However the specific details: the point of that change would be to shift responsibility (=power) from individual module creators to the coding swarm of contributors. This would significantly lower the odds of b(rainde)ad code getting in and hopefully drastically cut down on duplication. Especially because of the to-be-expected great API changes in D7 and the resulting amount of code rewriting that has to be done, wouldn't it be a great point in time to get our act together and come up with a single bind-them-all notification framework? _One_ cleverly designed poll/decision extension? Merging/standardizing the various e-payment modules? Imho taking this direction in the long run will result in more coherent code and enable easier adaption to core API changes, also cutting down on user confusion - furthermore increasing overall D7 r0xorn3ss! What's your view on this? regards, marcel. -- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote: http://hfopi.org/vote-future