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

[Lynne Pope]

2009/2/3 Mike Schinkel <mikeschinkel at newclarity.net>

> "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.


Because FOSS projects are fluid and people come and go, there is no
guarantee that the number of people around in the future will be able to
sustain a core + modules + plugins + themes.
What is less ultimate work for the core team this year could become a real
noose around the necks next year. WP is currently enjoying high popularity
with 3rd party developers, but this may not always be the case. Basic risk
management for the project should always include sustainability.


> 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.


The problem with "lots of people" is that this is unquantified. We know lots
of people want a good, solid blogging platform. Many seem to use it as a
framework for their own development. If the ideas forum is anything to go
by, most people must be pretty happy with what WP does now - there are not
too many new features being requested there. The rest of us are looking at
what we do with WP, but this does not necessarily project out to what the
masses want or need.


> > ... 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.


This holds true only when meeting the needs of the module does not have a
negative impact on extensibility. Unfortunately, it often does.


> > 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 ;)
> ......
>
> 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.


I understand where you are coming from and may even be inclined to agree
sometime. At the moment though it kinda seems a bit like putting the cart
before the horse, so to speak. *If* we had some standardisation across
plugins and documented methods to avoid collisions, optional modules would
probably not be needed. Dependencies are a real problem and coding standards
are a real problem. I'm not sure modules are the best way to address these
kinds of issues.

Lynne