[development] Drupal as an API: where the value is ...

[Khalid Baheyeldin]

[New title, since it is a new topic. Was "Privatemsg needs a better
maintainer".]

On Wed, Mar 26, 2008 at 8:18 PM, Larry Garfield <larry at garfieldtech.com>
wrote:

> I would phrase it differently; core is trending toward a more
> engine-centric
> nature, with implementations built on top of it in contrib.  Since the
> engines are the harder code and usually contain the trickier bugs, that
> actually works out.  The really complex/ugly stuff goes through the core
> gauntlet, while contrib can, hopefully, get smaller and simpler as it's
> just
> ways to piece together or tweak the engines.
>
> At least that's what I hope is happening / will happen. :-)
>
> On Wednesday 26 March 2008, FGM wrote:
> > Note that coupling this observation with the trend towards a leaner,
> more
> > feature-limited core, makes the value proposition of drupal more
> > problematic: if core unbundles features to contrib in order to obtain a
> > better and more performing core, contrib cannot but remain of lower
> > quality, and the overall value to potential users becomes lower between
> a
> > small and excellent core, and a haphazard mix of contrib modules, only
> some
> > of which are of quality comparable with core.
>

I am in the camp that core should be more about APIs, than ready to use
stuff. How
these APIs are used should be left for contrib.

Contrib has been an innovation test bed for Drupal. Many of the
"applications"
and even interesting frameworks have been in contrib. Think of
ecommerce/ubercart
and CiviCRM: those are what people use and want.

Think about Views and CCK, and if they were in core: would they develop so
quickly with core being only committed to by a few people?

Things that have proven themselves in contrib become candidates for core,
and
this happened already for OpenID and Triggers. They were easier and faster
to prototype, test, mature and then they go into core.

Look at how many Feed/Aggregator we have now? Hopefully soon they will
consolidate into one good thing that makes it to core.

Core should not be bloated with "applications" where there are more than
one way of doing things, and people would never agree on the right way.
It should provide some basic modules, yes, but not more functionality in
core that can be covered by contrib in more than one way.

So, the value of Drupal core is in providing powerful, flexible and clean
APIs,
letting contrib run wild with them, then selectively taking pieces back in
core
to become enablers for more innovation in the future, whether they are APIs
or applets or whatever.

This strategy has worked well for us, and there is no reason to change it
for
the time being, unless the landscape changes and it requires changes.

For me, Drupal is a web application framework, and that is where its power
is.
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080327/3b884e20/attachment.htm