[development] google just pwned the brochureware site industry

Benson Wong mostlygeek at gmail.com
Thu Feb 23 20:40:48 UTC 2006


On 2/23/06, Jeff Eaton <jeff at viapositiva.net> wrote:
> This is a potential problem for places like Bryght, but I don't see
> Google really competing with mambo/joomla/xoops/drupal/phpnuke.
>

There are plenty of shops out there doing well with their own homebrew
CMS system with a fraction of drupal's deployments and feature. The
issue isn't technology, it's service and support. Technology doesn't
have value, solutions do.

On that note, I want to rant about Drupal a bit. Drupal has a very
impressive amount of geek brain power behind it. The node system, the
hook system, the module system, the new FAPI, all of that stuff is
extremely clever. Very smart stuff. However, featurewise, that stuff
is really only important to developers. I think there needs to be more
focus on solving real problems.

Featurewise, this is what I'm missing in Drupal core:

1. Pluggable authentication support. I'm talking about a user.module
that uses LDAP, or Kerberos, or whatever for authentication, and
doesn't need to maintain an external user record.

2. i18n and l10n support in core. Just started looking into this, and
just started looking at Jose Reyero's i18n module. Apparently doesn't
need to patch against core anymore, but need to investigate more.

This is what I think is needed for the project:

These are obversations from reading through the dev list. This is
mostly addressing my confusion of where responsibilities lie.

1. Better deligation of responsibilities.

 - A core team: Handles core development, approves user contributed
patches, etc.

 - A security team: maintains old releases and back ports bug fixes,
not functionality.

 - A release team: handles release timelines, documentation, and all
the responsibility of making the latest version of drupal ready for
public consumption.

 - A contributions team: provides support for contributors. Maintains
the contributions list, isn't there a better way than one _long_ list
of modules?

Does the buck stops at Dries on the direction and organization of
Drupal development? It seems to me that Drupal has gained enough
traction and popularity that a development, maintenance and support
model needs to be decided on.

Some off the top of my head:

The FreeBSD model - I outlined it above.

The OpenBSD model - One supreme dictator, lots of hackers. (i think)

The Linux model - Here's a core, everything else is up to you. Drupal
is like a distribution now, I dunno if this model would work.

The Commercial Model: probably wouldn't work.

Ben.


More information about the development mailing list