[consulting] DrupalCOM: European Small Business distro

Bèr Kessels ber at webschuur.com
Fri Dec 16 15:42:23 UTC 2005


Thank you for replying, Dries.

First of all I think My intend target audience is *not* that CEO with some 
spare time and an Apache server sitting in her serverroom. 

I intent to:
* use this as our (sympal.nl) basic install. we might even call the 
profile/distro Sympal. :)
* provide this in an SVN/CVS/drupl project or so, for *consultants* to grab 
and use. 

Op vrijdag 16 december 2005 10:01, schreef Dries Buytaert:
> > Now the funny thing with all this is: its so darn simple!. It is so
> > simple,
> > that drupal cannot do it! Drupal adds complexity all over the
> > place. And most
> > often the biggest bulk of the work lies in getting rid of that
> > complexity and
> > getting rid of all these pages, links, read-counters, attachement-
> > lists,
> > user-profiles, post-dates, and what more.
>
> Make no mistake.  Much of this is not specific or limited to small
> businesses.  It are core improvements.

Yup. I am aware of this. One of the things I really hope to achieve with this 
'thing' (lets not call it a distro yet) is to widen the possibilities of 
Drupal deployment, by limiting the default options :)

> I'd like to see most of the improvements that come out of this
> discussion to go straight into Drupal core!  No, not to a DrupalCOM
> distribution.  Why?  Because if you want to build a community
> website, an e-commerce website, a campaign website, a news website, a
> classroom website, or any other level 3+ website, you still need
> _all_ the level 3 functionality.  Everyone needs a contact form,
> everyone needs an about page, everyone has to manage one or two
> custom blocks, everyone has to create a navigation structure,
> everyone needs to upload some documents/images.  Everyone.  As easy
> to use as possible.

This is true. And would be ideal. Yet we (I at least) are in a similar boat as 
Bryght and CS. We have to get going fast. We cannot afford to always get 
everything trough the whole community process when there are targets and 
deadlines luring around the corner. 

But moreimportantly, Drupal Core has in this issue, too much. So I want to 
split the complete 'thing' into two separate issues:
1) the files and configuration
* Collect and develop the modules and themes that are required
* Remove the modules and themes that are certainly not required. 
* Configure the database (dump) to hold a ready-set-go configuration. That 
will probably even include some pre-made nodes containing 'click here to 
change your about us page' 

2) Hacking Core :)
* Fix up all issues that cannot be dealt with trough modules and a few themes.  
(think about i18n)
* Provide a default set of theme_foo functions to (re)move stuff

Both steps will produce helpfull code. Esp 2) will give us some usefull 
patches for core. But 1) might also give us some usefull small modules and 
themes, that can be used in Drupal itself, who knows.

For certain is, that Drupal core has still too much. Forums, profiles, queues, 
community blogs, etc. I believe they are good for Drupal itself, but must be 
remmoved from that 'thing'. That is stuff that cannot flow back into Drupal 
itself. 

But last, and certainly not least. I, and I guess no-one has the resources and 
infrastructure ready to do this outside of Drupal. Esp the step 2) should be 
held all in-Drupal, IMNSHO.

> None of the complaints or features in this thread were specific or
> limited to small businesses ... except for the business-specific pre-
> configured navigation structure, maybe.  The DrupalCOM distribution
> should be a 50-line MySQL file.  All the other improvements should go
> to core.

Not really. Many Drupal people come to Drupal for its flexibility, and its 
powerfull features. While the 'thing' s main aim is to hide -or eve do away 
with- that feature richness and flexibility. CEO's don't need taxonomy, they 
want a page listing all their services. And if that is done with a completely 
preconfigured taxonomy, or with a small module, is not yet up for discussion, 
IMO. 
Removing stuff cannot be done with a 50 line SQL file, unfortunately.

And if we were to say: remove profiles/archives/forums/foo/Bar from core 
others with other needs would rise and fight these decisions. Who says they 
don't need forums? Or user management? Or anything else?

> Keep in mind that Drupal 4.7 is what you'll have to sell to your
> customers in 2006.  If your business depends on Drupal, there is
> still time to get many small improvements into Drupal 4.7.0 (eg.
> improved default configuration, improved out-of-the-box experiences,
> improved interfaces, less configuration overhead).  All it takes is
> some of your time and resources and all of us (including your own
> business) get to benefit from it for months to come.  You better be
> quick though.

Drupal 4.7 is -as others mentioned too- a huge improvement in all this. we 
have added a lot of targetted, restult-oriented features and things (menu otf 
primary links- in menu admin, better block administration etcetc). And we 
have gained a huge amount of flexibility from a consultant point-of-view. 
but the thing that remains, is that for a brochure site, Drupal does still far 
too much. It tries to be both developer friendly and userfriendly. Both 
flexible and unfriendly.  Both bloggers and those that have never heard of a 
blog. Both modular/expandable and offer a wealthy core. that is good! And 
DrupalCom should be a distro that builds and uses that flexibility and power.

And hopefully we can make as many improvements that help Drupal grow. 

> > -- 
> Dries Buytaert  ::  http://www.buytaert.net/
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting

-- 
 PGP ber at webschuur.com
  http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc
 PGP berkessels at gmx.net
  http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc


More information about the consulting mailing list