[development] D7 contrib module development

[Khalid Baheyeldin]

On Mon, Mar 9, 2009 at 11:28 AM, Marcel Partap <mpartap at gmx.net> wrote:

> We've always had stuff that falls off the face of earth. So what? The
>> caravan continues on ...
>>
> Sorry but i don't consider that a logically valid argument.
>

What I meant is modules come and disappear all the time. This
experimentation has proven to be healthy, and the project is healthy despite
that.

It is not a negative to have unmaintained modules and such, given that
others are thriving.


>
>  The very first module I contributed (feedback) illustrates a point: It
>> was started in 2002 by someone called "barry". I had it working I took
>> it over in 2004 with totally new code for Drupal 4.5. Then "fago"
>> overhauled it a lot in 2006. Over time, the contact module in core came
>> along, and I stopped using feedback. Then in 2008 "sun" took it over and
>> repurposed it with new code.
>>
> Well good that process worked out than, btw i am actually using the module
> ;)
> But from the experiences gained, how would you design such a module from
> scratch?


In the four instances, the code was rewritten from scratch, preserving the
name and often obsoleting the prior functionality.

How could it be integrated with other modules, what could be factored out
> into 'frameworks' (/library modules) ?


It happens naturally. For example userpoints started as an application, then
people wrote more applications for it, it was all in a single project. Later
we took out the community contributions and split them into the
userpoints_contrib project. Then we split off ANY and ALL applications (what
used to be userpoints_basic, now userpoints_nc) leaving only the API in the
project.

Views started the same way with splitting off the bonus pack ...etc.

What I am saying it happens naturally as people realize that they are
evolving their pet project into an API/Framework over time.


> That is the stuff each of the drupal code contributors needs to think about
> as early as possible in the D7 cycle, which would be right about.. _now_!
>
>
>  The "too many modules in contrib syndrome" can be taken as confusing,
>> excessive, ...etc. but can also be taken as a sign of a healthy and
>> vibrant community.
>>
> Sure. But what is the prior goal of the Drupal project? To create a healthy
> vibrant community? Or to create the best open source CMS CODE out there
> (best accomplished through a healthy vibrant community)?
>

The vibrant community leads to the best open source CMS code.

Creating the best CMS code does not mean that the default download be
bloated with hundreds of modules that not everyone will use.

As I said: kernel -> distros. One for education, one commerically supported,
another for high traffic sites, another for whatever.

It is working out ...


>
>
>  So what if we have a few extra gigabytes of code? So
>> what if they become unmaintained?
>>
> Uhhm sorry i don't share that so-what mentality.


You miss the fact that this is an ecosystem, and you have all kind of
relationships: symbiosis, parasitism, commensalism, ..etc.

You can't dictate what happens in contrib without stifling the innovation
that this ecosystem has.
We can nudge people to work together but we can't force them to.


> I want to have *all* the functionality spread over slightly different
> modules with the same purpose, combined into one flexible solution. And i am
> quite sure i am not the only one.
>

You are advocating the "one true way". But without letting people
experiment, that one true way could be the one with less features, with a
non-committed maintainer, could be buggy, ...etc. You don't know until you
put it out there and let the ecosystem decide. Who will decide the one true
way? Committee? Hierarchy? Nope, sorry. Don't want that in a community led
project. Might as well go to commercial CMSs then.

What we can do is let things evolve for a while and then naturally a winner
or two will emerge from the fray. As disconcerting this is to some, it is a
sure way to have a proven solution for the problem space.


>
>  If we raise the barrier or block new entries we will be shutting
>> ourselves off from being the platform for the new chx or the new
>> merlinofchaos.
>>
> Woow stop for a minute please.. so you're saying people like chx or
> merlinofchaos are not capable of adapting to coding standards and qualified
> to contribute code which can be worked on to raise over the ready-and-useful
> barrier to be included in the official Drupal repository?
>

No. I am saying is that without seeing people contribute for some time you
don't know before hand if they will turn to be a drive-by contributor of a
so-so project, or the author of the next big hit.

And it is not only about technical prowess, it is about how you work with
the community, are you committed to the community and Drupal, do you
encourage others who use/contribute to your project, and much more. All that
cannot be seen just from the first contribution adherence to coding
standards.


>
>
>  It does not matter ... if it is the wild wild west, then let it be. It
>> is a small price to pay for innovation and the power of the masses.
>>
> But the thing is, sometimes innovation needs channeling. Granted, in the
> early phases of the industrial revolution it would have been
> counterproductive to regulate machines and processes in any manner, simply
> because not enough practical experience had been gained. But once a certain
> level of sophistication is reached, there is no way you want to live without
> agreed standard interfaces and common norms. Imagine todays industries
> without all the ISO standards for screws, bearings, gears, quality
> management.. What do you think which kind of a car would you drive if none
> of them would exist?


Fair point, standards will arise across CMS's too, such as the new proposed
CMIS that makes them interoperate. There are differences in an information
world than an industrial one too (capital required, barrier to entry, ...)

But the argument is : are we at that point yet? Is it now? I don't think so
myself.

But within Drupal, I don't see we are the point where we have a central body
.

Later maybe? Perhaps. But not now. When you see a majority of the community
cry for that, then it is time to re-evaluate.


> In my opinion with D7 we have reached that level of wild life experience to
> benefit from a more ordered development process. To say again, why trade in
> quality for quantity/speed? Most people will be quite happy with D6 for
> years to come.
>

Again, you see "now is the time", I see "not now".

As for D6, it will not get security support forever. So those who use it are
on their own after D9 comes out, whenever that is.


>
>
> rgds 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
>



-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090309/72459333/attachment.htm