In reply to Justin.

Justin - Please pardon my Devil's Advocate-ness for the sake of this sub-thread / discussion. (I want to be clear: This is not push back. I for one believe the WP framework product should be mature enough at this point - i.e., 10+ yrs - to begin to address such issues.) That being said...

It feels like apple and oranges to me. Many would argue that standardization can and does squash innovation, or at least the ability to experiment. On the other hand, (data) portability - which btw perhaps isn't the right word since the data is staying put, it's the plugin that's changing - allows the eco-system to thrive more or less unregulated (if you will).

Off the top of my head...

Step 1 - An intra-plugin export / import standard. (In my mind, provide a class / toolkit so implementation is uber ez for devs.) Again, for example, the plugin is config'ed in dev and it's easy to export and import those baseline setting into staging / production. That (XML file) would provide a level of transparency as to what data the plugin is generating / using.

Step 2 - As the various approachs to a given solution become clear, chances are good one plugin author - in order to gain market share - is going to write a sub-plugin (?) that will migrate data from competitor A over to their plugin. I believe a couple of the SEO plugins kinda do that now, yes?

Step 3 - Eventually, the market settles out (if you will) and the deviations slowly become standardization. I'm not sure what the proper economic term is but I'll go with: Competitive Cooperation (if you will), or perhaps Cooperative Competition :) That is, (for example) "Well, if I do X, Y and Z like industry leader plugin #1 then that's one less thing to convert / migrate." Or something like that. Currently, in theory that's possible but WP's general Wild West mindset doesn't see value in NOT inventing the wheel, eh?

That being said, if nothing else some sort of actual documentation standard would certainly help. Trying to figure out someone else code (e.g., what a given meta data element actually represents) shouldn't take prayer and monk-esque chanting, as it often does now.

Such a level of transparency is also a benefit to end users in a buy beware sorta way. I'm not saying they'll read it, but devs knowing they are "exposed" has a tendency to influence behavior.

p.s. Ping me if you want to take this up offline. I don't want to hi-ijack Ms. Gooding's article, nor suck up your time responding to my madness.