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

[Jeremy Clarke]

Lots of great points being made here. I think I'm personally leaning
towards the status quo on this one though.

Some bullets:

* The plugin ecosystem squeezes more work out of volunteer developers
than core. Obviously it would be nice if we could all sit back with
absolute confidence that everything we need will always be provided to
us for free, but that would overload the core development team. As it
is prestige, notoriety, etc. are available to people to create or take
care of important plugins. They take on responsibility because they
need the thing, and we all benefit. This is the 'caring' DD32 was
talking about. I think if optional functionality is moved into core
there would be less people putting time into it (though obviously i
have no proof).

* Core moves slowly: I think that lots of plugin devs like having full
control over their work. They would do less work if they had to go
through the hoops you have to jump through to get patches committed to
core. It is frustrating and time consuming, which is good because it
keeps quality high and weeds out people who aren't committed to the
long-term stability of core, but not necessarily the best place for
groups to collaborate around important shared functionality.

* core should not be managing teams of module devs - this is pretty
obvious to me but Mike's description of having teams working on the
modules sounds like a management nightmare. The core committers are
very busy looking at one function at a time as previously stated. The
whole ecosystem right now is a kind of anarchic meritocracy that runs
based on tickets rather than people and I think it works pretty well.
I think asking the devs to go around kicking the teams awake is a very
bad idea. If anything they should just make note of the truly
important plugins and offer friendly advice and encouragement and help
to them as needed in an informal way, just like they currently do to
developpers who work on important parts of core and take
responsibility for them.

* If the API sucks lets fix it - The whole discussion about a paradigm
shift towards moving API into optional modules I think misses the
point entirely. The things that get turned down for core aren't API
they are uses of the API. If you make a consistent argument for a
given bit of API and do the work to implement it then there's a good
chance it will get committed. In my experience when I ask for a hook
that is really needed I get it as long as I write a patch and convince
people why it's important. When it is turned down it's usually because
there is already another place in the code that can do what I need.

* Drupal modules are a clusterfuck. No personal offense meant to any
Drupal developpers or users out there, but my experience with that
platform gives me no particular confidence in the kind of system you
are describing (which is exactly how Drupal does its business). Their
modules are often abandoned, out of date, bug-ridden and also crappy.
They end up feeling like design-by-committee in a very annoying way
and ultimately aren't that much more consistent than the better WP
plugins. They also always feel pretty handicapped by their slavish
acquiescence to the Drupal API (which covers everything like you
propose). They somehow manage to all feel awful to use because they
are built that way, unlike WP plugins which (while it can be
annoying!) vary widely, from the ugliest plainest most useful thing to
the elaborate extravagant plugins that you love to use.


I think that the solution to these issues isn't a paradigm shift but
rather little steps towards encouraging the kinds of behavior that is
good for everyone and discouraging the behavior that isn't.

Some ideas that wouldn't change the big picture but would help fix it:

 * Make the plugin pages on extend more development-focussed - I'm
constantly wishing I had access to some kind of bug tracker where I
could post patches or bugs on extend. I think there might be a trac
set up automatically somewhere but it's invisible from the extend page
and no one uses it as far as I can tell. The wp forums is NOT the
right place for development, and extend should be doing something. It
would make it easier for different users to work together to solve
shared problems (and would make it easier for concerned users without
problems to help their unknown-neighbors). Ideally the dev would have
the ability to turn off the development stuff IF they had another link
or place to forward users.

* Have plugin reviews for api compatibility - Maybe this could be a
party idea for those who want more fun in between Wordcamps,
"Wordpress Hacker Plugin Review Night". A lot of the issues you
describe basically come down to "Devs aren't using the api properly".
In all your examples I could think of API ways to accomplish them
(store tweets in posts table with 'twitter' as type, for example). A
more dev-focussed extend would also make this easier, as people could
come together to put friendly pressure on plugin devs to clean up
their act.


-- 
Jeremy Clarke | http://simianuprising.com
Code and Design | http://globalvoicesonline.org