[development] D7 contrib module development

[Kyle Mathews]

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.

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.

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.

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.

Kyle

Research Assistant
eBusiness Center @ BYU
kyle.mathews2000.com/blog


On Sat, Mar 7, 2009 at 9:03 PM, Marcel Partap <mpartap at gmx.net> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090307/30042a82/attachment.htm