[New title, since it is a new topic. Was "Privatemsg needs a better maintainer".]<br><br><div class="gmail_quote">On Wed, Mar 26, 2008 at 8:18 PM, Larry Garfield <<a href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I would phrase it differently; core is trending toward a more engine-centric<br>
nature, with implementations built on top of it in contrib. Since the<br>
engines are the harder code and usually contain the trickier bugs, that<br>
actually works out. The really complex/ugly stuff goes through the core<br>
gauntlet, while contrib can, hopefully, get smaller and simpler as it's just<br>
ways to piece together or tweak the engines.<br>
<br>
At least that's what I hope is happening / will happen. :-)<br>
<div><div></div><div class="Wj3C7c"><br>
On Wednesday 26 March 2008, FGM wrote:<br>
> Note that coupling this observation with the trend towards a leaner, more<br>
> feature-limited core, makes the value proposition of drupal more<br>
> problematic: if core unbundles features to contrib in order to obtain a<br>
> better and more performing core, contrib cannot but remain of lower<br>
> quality, and the overall value to potential users becomes lower between a<br>
> small and excellent core, and a haphazard mix of contrib modules, only some<br>
> of which are of quality comparable with core.<br></div></div></blockquote></div><br>I am in the camp that core should be more about APIs, than ready to use stuff. How <br>these APIs are used should be left for contrib.<br>
<br>Contrib has been an innovation test bed for Drupal. Many of the "applications"<br>and even interesting frameworks have been in contrib. Think of ecommerce/ubercart<br>and CiviCRM: those are what people use and want.<br>
<br>Think about Views and CCK, and if they were in core: would they develop so<br>quickly with core being only committed to by a few people?<br><br>Things that have proven themselves in contrib become candidates for core, and<br>
this happened already for OpenID and Triggers. They were easier and faster<br>to prototype, test, mature and then they go into core.<br><br>
Look at how many Feed/Aggregator we have now? Hopefully soon they will<br>
consolidate into one good thing that makes it to core. <br><br>Core should not be bloated with "applications" where there are more than <br>one way of doing things, and people would never agree on the right way.<br>
It should provide some basic modules, yes, but not more functionality in <br>core that can be covered by contrib in more than one way.<br><br> So, the value of Drupal core is in providing powerful, flexible and clean APIs,<br>
letting contrib run wild with them, then selectively taking pieces back in core<br>to become enablers for more innovation in the future, whether they are APIs<br>or applets or whatever.<br><br>This strategy has worked well for us, and there is no reason to change it for<br>
the time being, unless the landscape changes and it requires changes.<br><br>For me, Drupal is a web application framework, and that is where its power is.<br>-- <br>Khalid M. Baheyeldin<br><a href="http://2bits.com">2bits.com</a>, Inc.<br>
<a href="http://2bits.com">http://2bits.com</a><br>Drupal optimization, development, customization and consulting.