[drupal-devel] Project management contribs: Bundles: grouped modules.

Aran Clary Deltac aran at arandeltac.com
Fri Feb 18 23:09:55 UTC 2005


> Op vrijdag 18 februari 2005 17:52, schreef Ross Kendall:
>> Just for the non-official contrib modules, not for the high quality
>> integrated modules.  You can't tell me that you do not use the ratings
>> on sourceforge.net to help you find software.
> Continuing on the rating discussion:
>
> Yes I do use that rating. But SF lists thousands of projects. Drupal only
> less
> than hundred. And we should better make less projects, that are of higher
> projects, thaen to have hundred vapourwares.

In my experience the number of projects plays a much smaller role than how
rigorous the process is to include the project on the listing service (in
our case the drupal web site).

1) For example, with a couple clicks of a mouse on sourceforge you can
have a project space created and let it sit there for a year before you
submit anything.  Even when you do you can set the status to
production/stable at any time without any community input.

2) On the other extreme is Perl's CPAN where to include a module in the
listing you must propose your idea and are heavly scrutinized by the more
senior module maintaners.  The process to get a module on CPAN is almost
scary if you are doing it for the first time.  Yet CPAN has many thousands
of modules, and most of them are of a very high caliber of quality because
of this process.  There is duplication, but not too much, and the
duplication tends to spur on innovation (like windows vs linux).  So so
coders will just have to live with submitting patches.

This second model is the one that I would like to see drupal take.  Most
drupal users are scared of the word CVS, and the idea of writing PHP is
just unheard of.  So, with that we already have 75% of the people canceled
out from submitting half-baked modules.  The next step is to heavly
scrutinize anything that gets in, but once its in the developers need to
be absolutely trusted to do a good job and clean up after themselves.  If
they don't they get a quick slap and all eyes are on them for a while.

Aran


> Case: My client has a deadline, requires some "easy"mentod to add images
> to a
> node, and hires me to do so. I have three options:
> 1) start yet another image-node project, commit the code after finsishing.
> 2) take one of the exsiting projects and modify it to my needs, and send
> diff
> files to the maintainer.
> 3) contact the maintainer and work out an idea where we will both (and
> others
> too) benefit from.
>
> IMO, case 1 and 2 might be contributed, but *only in my sandbox*. Only
> case 3
> should be contributed back.
> Yes, I beleive SF needs rating because of the overall poor quality of the
> projects in there. Its a common OSS problem, but we do not need to have
> that
> on Drupal, since we are small and aimed at one niche. We can prove that
> even
> OSS projets can work in a more efficient way, and that OSS can be
> organised
> too. After all: anarchy is nice to start off with, but some structure is
> far
> better for all parties, and has a much higher quality ratem, ass well as
> far
> higher efficiency. (at least that is my opninion)
>
> Regards,
>  Bèr
> --
>  [ Bèr Kessels | Drupal services www.webschuur.com ]
>





More information about the drupal-devel mailing list