[wp-hackers] Less than Core, More than Plugins/Themes: Proposing Optional Modules.

[Mike Schinkel]

"Lynne Pope" <lynne.pope at gmail.com> wrote:
> Even though these are proposed to be optional modules my 
> experience with other FOSS projects has shown that...

But FOSS projects are by their very nature fluid and there is collective learning over time. Structure this thoughtfully and it becomes less ultimate work on the core team instead of more.  

Have the core team delegate to "module teams" and give them the authority over that module. This allows the core team to really focus on core features instead of addressing what would essentially be less core but that lots of people want.

> ... when a core team has to support optional modules 
> development becomes a bit of a "chicken and egg" situation, 
> where code goes into the core to support the optional modules 
> and module development and compatibility issues can end up 
> impacting on decisions made about the core. 

That would be inevitable, and desirable, no matter what structure is made. When plugin developers have valid needs the core must evolve, how is this different?
The whole point of evolving the core is to make it a better platform; without actual needs driving the platform evolution, but value is there to the evolution?  Your concern appears to be a good thing, not a bad thing.
 
> I am far more in favour of the core team simply providing 
> the hooks and extending the API to make development for 
> the different areas of interest easier - for third parties ;)

The problem is that needed hooks have been "voted down" because it will "bloat the core."  The point of the proposal is to give those things aren't right for the core but that really do need some standardization and dependability have a place to go.

What's the decision flow?  

   Is it right for the core? 
      -> Yes -> Into core
      -> No -> Is it shared Infrastructure/APIs?  Does the community benefit from having "one" vs. "many?"
         -> No -> Make it a Plugin
         -> Yes -> Make it an Optional Module

What I'm basically asking for are specialized APIs (and some commonly valued functionality) that are not right for the core but by definition don't achieve defacto-standardization if they are implemented as one-of-many plugins.

-Mike Schinkel
http://mikeschinkel.com/