RE following the linux model -- we already are. Linux has one "kernel" and how ever many applications built on top it that there are individuals interested enough to write one. We follow the exact same model -- Drupal's kernel (the core) has two committers and a core group of individuals who either maintain subsections of our "kernel" or know enough about core development to "sign off" on patches before they're added to core.<br>
<br>But in the Linux application space it's a wild wild west as far as quality standards go. There are many Linux applications of very high quality maintained by companies or dedicated individuals but again there's scads of poorly coded, poorly maintained duplicating applications available for Linux.<br>
<br>As Drupal matures, so will the contributed modules space. Already more important modules like Views see significant commercial support and have code quality standards as high as core.<br><br>I think forcing all contrib code to go through a central space is a really bad idea because a) it doesn't scale -- who wants to spend time reviewing someone's weekend hacking project? and b) it'd unfairly kill ugly baby modules which might mature into something significant. Innovation isn't "perfect" at the start.<br>
<br>Kyle<br><br clear="all">Research Assistant<br>eBusiness Center @ BYU<br><a href="http://kyle.mathews2000.com/blog">kyle.mathews2000.com/blog</a><br>
<br><br><div class="gmail_quote">On Sat, Mar 7, 2009 at 9:03 PM, Marcel Partap <span dir="ltr"><<a href="mailto:mpartap@gmx.net">mpartap@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi fellow drupal devs,<br>
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..<br>
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:<br>
- modules spamming the watchdog table with E_ALL warnings<br>
- modules ignoring the style/documentation guide lines<br>
- applied insane programming(TM) techniques<br>
- undescriptive module names<br>
but by far the most serious one is<br>
- duplication (partial feature overlap with existing modules).<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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!<br>
What's your view on this?<br>
<br>
regards,<br>
marcel.<br><font color="#888888">
<br>
<br>
-- <br>
"Obstacles are those frightful things you see when you take<br>
your eyes off your goal." -- Henry Ford (1863-1947)<br>
<br>
Change the world! Vote: <a href="http://hfopi.org/vote-future" target="_blank">http://hfopi.org/vote-future</a><br>
</font></blockquote></div><br>