[development] Encouraging Collaboration
dan at civicactions.com
Fri Nov 18 16:43:22 UTC 2005
One of the biggest selling points of Drupal (IMHO) is the sheer number
of contributed modules (and developers behind them). One of the biggest
drawbacks is the amount of stuff that doesn't work *right*. It seems
that there are a number of forces at play here -
1) What is out there? While I love going through the list of
contributed modules there is so much out there that I have no idea where
to start sometimes.
2) Core vs. Contrib - This pattern seems to be mainly about general vs.
specific - but it is also about quality vs. quantity. It seems that
quality vs. quantity needs more attention.
3) Who is this product for? Drupal is a very mature product - but it
seems like it hasn't grown up yet :) - which is kinda cool - and kinda
infuriating. I think that there needs to be a better definition of who
this product is for - is it for the people who spend most of their time
developing/contributing to it? Is it for web developers? Is it for
webmasters? Is it for end-users? At the end of the day we all sit
somewhere in a very long chain which starts with dreamers and ends with
a person at the end of a wire plunking at their keyboard.
4) How do things get done around here? The only sure way to do anything
is to do it yourself - which is fine - but it limits participation (see
3 above). There are a bunch of different possible solutions to any
given problem (like the one pointed out in Allie's email). However
without a roadmap it is difficult to know which way to go.
Here are some specific things that might work to solve this problem -
1) Right now there are three module categories -> core, modules,
sandbox. Perhaps there should be another? "community modules" - being
stuff that the "community" endorses? Perhaps by a straight up or down
vote of contributors? I know this is radical.
2) There could be a "reviews" blog attached directly to each module -
I'm sure this is an old discussion - sorry for bringing it up again. I
would love to see Allie's notes from her investigation of the "Amazon"
modules so I knew what was in and not in each module.
IMHO Drupal is going through some growing pains - Dries pointed this out
in Amsterdam when he talked about the phenominal growth of the
community. There is a lot of work to be done. Here's one last idea -
perhaps what is needed is a community manager? Someone who is committed
to full-time work on Drupal and is directed by a clearly agreed upon set
of deliverables. We would chip $$ in to pay for this as an experiment -
and honestly I think that in a community this size it would be trivial
to raise $$ to do this. Of course this entire email is worth less than
> The 4.7 / Forms API upgrade is going to create a learning curve for
> many module developers, and some of the less-active module owners may
> not have the time and inclination to make the switch. That could be
> good news.
> A lot of these efforts are "learning experiences" that are not being
> maintained at all. Some of the authors can't be reached, and if
> you're too polite to overwrite those modules you start new. Some
> developers feel that it's more rewarding to have their name in lights
> than to collaborate on a module that's more useful and stable
> overall. Some people just don't play well with others.
> As an alternative to upgrading, some module developers could look at
> modules with similar functionality and try to help upgrade and
> enhance those. Do we really need 3 Amazon modules? 6 "mail this
> thing" modules? (one of these is my fault) Can the Flikr Block
> module be part of the Flikr Module? The list is endless.
> This is a big problem for new Drupal users and old timers alike.
> It's not clear which modules are being maintained and how well they
> work. A few months ago, I tried all the Amazon modules and
> discovered that each gave me about 60% of a solution. I finally just
> dropped the idea if using Amazon at all. I'm sure this sort of thing
> happens a lot, and we never even hear about it.
> I'm not saying that any of these modules deserves to die, or that
> they can't possibly be bringing anything new to the table, but I
> would offer these suggestions:
> - As part of the call for upgrades 4.7, recommend that module
> developers try to combine efforts
> - Encourage people to maintain TODO lists for modules so that
> others can understand overall goals and see if added functionality
> would be useful
> - Encourage people to archive and retire their abandoned projects
> from CVS.
> Allie Micka
> pajunas interactive, inc.
> scalable web hosting and open source strategies
More information about the development