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

Tue Feb 3 17:21:30 GMT 2009

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

No it's not exactly as I desscribed; far from it. I worked in Drupal for 1.5 years and most Drupal modules are exactly like WordPress plugins. Anyone can add one, and (too) many do.  

Same is true with WordPress plugins. Are you forgetting how much crap there is in Extend? 

> They also always feel pretty handicapped by their slavish
> acquiescence to the Drupal API (which covers everything like you
propose). 

Saying that obscures the issue. WordPress has an API just like Drupal has a API.  The fact you don't like Drupal's API doesn't mean that having an API is bad. I'm not advocating a Drupal-style API, I'm advocating the ability to add things that can become standard that don't make the cut into the core because they are "too specialized."

Some of the things Drupal does *really well* is "standard" modules and shared APIs.  WordPress could learn from the good parts of that instead of taking it as a "not invented here" attitude.

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

I'm open to alternate solutions. I'm not married to the idea, just to getting a solution that works.

> Make the plugin pages on extend more development-focussed

Agreed.

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

Agreed. Frankly I'd like to have mailing lists that are specific to areas, ie. "wp-image-management", "wp-twitter-integration", etc.  I find mailing lists the most effective way to stay involved and one of the main reasons I moved from Drupal to WordPress.

> Have plugin reviews for api compatibility - 

I COMPLETELY agree with that.

> Maybe this could be a party idea for those who want more fun in 
> between Wordcamps, "Wordpress Hacker Plugin Review Night". 

BTW, I'm seriously considering a WordCamp for Atlanta later this year...

> A lot of the issues you describe basically come down to "Devs 
> aren't using the api properly".

Many, but not even half of the issues.

> In all your examples I could think of API ways to accomplish them
(store tweets in posts table with 'twitter' as type, for example). 

EXACTLY.  That's where the community process would be invaluable, and why I called for optional modules that would be on peer with core; that would get the community to discuss them (and it could be a sub-community.)  I too thought of "twitter' as a type but then I thought "What about Facebook Status Updates?"  So should it be "twitter" or "status?"  That's what the community would be invaluable to address and that doesn't get addressed for plugins; they just do whatever first comes to mind which is often not the best for long-term.

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

Agree too.

Anyway, given the pushback I've gotten from selected individuals (because I honestly don't think they really understand the proposal) I'm going to take a different approach. I'm going to instead start bringing up things that are needed and when told "No, that would bloat the core" I'll be asking why they can't be optional modules.

See my next email.

Further, I'll call for dependency management and auto-install of dependent plugins. Is there a reason we can't do that?

-Mike Schinkel
http://mikeschinkel.com/

----- Original Message -----
From: "Jeremy Clarke" <jer-wphackers at simianuprising.com>
To: wp-hackers at lists.automattic.com
Sent: Tuesday, February 3, 2009 11:37:42 AM GMT -05:00 US/Canada Eastern
Subject: Re: [wp-hackers] Less than Core, More than Plugins/Themes: Proposing  Optional Modules.

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
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers