[development] D7 contrib module development

[Marcel Partap]

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