[development] google just pwned the brochureware site industry
Jeff Eaton
jeff at viapositiva.net
Thu Feb 23 21:45:46 UTC 2006
> -----Original Message-----
> From: Benson Wong [mailto:mostlygeek at gmail.com]
>
> 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.
Last I checked, Google wasn't the industry leader in service and support
unless that means something different than what I understand it to mean.
Those homebrew CMS systems you mention are probably, it's worth noting,
better at what THEY do than Google's CMS system is likely to be. Why?
Google's services, for all their coolness and spiffiness, are NOT about
customization or building application-specific solutions.
That's what I mean when I say that Google's hypothetical future CMS will
be better at what it does than joomla/mambo/xoops/drupal/phpnuke -- but
it will be far worse at duplicating all the things those customizable
cms systems can do. It's certainly possible that Google will get into
the managed hosting business, but I doubt that one.
> 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.
News flash: developers added those features in order to solve real
problems. Look at individual Drupal-based sites to see what I mean.
Downloading core and staring at it has never been, and will never be,
the way to judge whether Drupal 'solves real problems.'
> 1. Better deligation of responsibilities.
>
> - A core team: Handles core development, approves user
> contributed patches, etc.
Dries and Steven, with help from an active group of 'inner circle' devs
who know the system very well.
> - A security team: maintains old releases and back ports bug
> fixes, not functionality.
chx, with help from others, IIRC.
> - A release team: handles release timelines, documentation,
> and all the responsibility of making the latest version of
> drupal ready for public consumption.
That horse is dead. Very, very dead. Everyone knows and this one isn't
going to fall through the cracks.
> 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.
I'm all in favor of stripping even more features out of drupal core,
leaving it more API oriented, and leaving it up to others to package
'distributions'. With the new .install files for modules, it wouldn't be
difficult, either. Install core, drag the 'distibution package' to the
drupal/sites directory, change the url and database in the settings.php
file, and you're ready to go.
--Jeff
More information about the development
mailing list