[OSGeo-Discuss] The OSGeo response to the proposed "GeoServices REST API" document [was: Would you be concerned ...]

[Allan Doyle]

Thanks Adrian for your email with your reasoned explanation. It's not often people take the time to provide such a thorough analysis.

On May 9, 2013, at 1:56 PM, Adrian Custer <acuster at gmail.com>
 wrote:

> On 5/9/13 2:33 PM, Tim Bowden wrote:
>> On Thu, 2013-05-09 at 13:20 -0300, Adrian Custer wrote:
>>> Hey Cameron, all,
>>> 
>> ...
>>>    * The letter is only rejection of the proposal without offering an
>>>      alternative way forwards.
>> 
>> I strongly suspect the proposed standard would have received a much
>> better reception from the broader OSGeo community (with the diverse
>> viewpoints it typically has) if the proposal was more that a "take it or
>> leave it" (partial?) description of what ESRI has done and is going to
>> do anyway.
> 
> Undoubtedly. This was as undiplomatic as they could have been.
> 
> If there was at least some willingness to engage with the
>> broader community on interoperability within the standard (and how do
>> you have interoperability if you aren't willing to budge from a
>> pre-defined position anyway?).
> 
> And there would have been more participation at the OGC. Lots of folk were excited at the start but gave up when backwards compatibility was set in stone.
> 
>> 
>> Perhaps ESRI didn't realise their approach was going to come across with
>> an "up you" attitude (or maybe they did)?  The impression I've got it
>> that many people feel ESRI is treating the OGC as a "rubber stamp" body
>> (which very much implies arrogant contempt) regardless of the merits of
>> the proposal.
> 
> Much more likely, ESRI is trying to "push through" its standard, distinct from expecting the OGC to 'rubber stamp' it.
> 
> They knew from the get go they were going to face this opposition. The only question is who is stronger.
> 
> This is a good example of the limits of governance at the OGC. Really, a standard should not pass when there is concerted opposition to it. The process is designed to suspend when there is opposition (2 no votes), in an effort to build consensus. However, the ultimate decision is still a 50% + 1 vote; probably, it should be a super-majority of some kind.
> 

Having attended most of the first 50-ish OGC meetings and then a few here and there since, here's my perspective on the "limits of governance". The problem is not so much the process (or wasn't, back in the day, it's become much more byzantine since then). The main problem is that most TC members either have no programming/architecture background or their expertise is fairly specialized. That means that for any given proposal, a small percentage of the members really understand it. Then, when it comes to a TC vote you have people voting based not strictly on technical grounds but also on business interests, political interests, even social interests. On top of that, I don't think that member companies are very knowledgeable about the policies and procedures and don't really know how to use their memberships to their best advantage. Taken together, this can lead to some fairly dysfunctional results.

I believe that the Architecture Board (or whatever it's called now) was established in part to counter this effect. You'd have a bunch of knowledgable old hands benevolently watching over the output of the process who were going to make sure things hang together from a technical point of view. Perhaps the Architecture Board has been unable to provide sufficient guidance to the TC in this particular instance.

> 
> Hopefully I've got it wrong and ESRI really just botched
>> their approach on this one (why do I feel this is naive wishful
>> thinking?).
>> 
>> FWIW, I don't believe having an alternate incompatible standard must of
>> itself be a deal breaker, if the proposed standard genuinely represents
>> a viable attempt at interoperability.  After all, the wonderful thing
>> about standards is there are so many to choose from.  ;)  Lets just not
>> pretend it's about genuine interoperability unless that really is the
>> case.
> 
> I doubt anyone is that naive.

In the end, everyone wins if specs are vendor neutral but also allow vendors to differentiate themselves by providing different qualities in their implementations. If a spec is passed that is simply a thin veneer on top of an existing vendor's implementation, then that vendor has a head start over others. If the OGC members are collectively unwilling or unable to push back against this, then this kind of thing is the result. It's really a Darwinian microcosm within a mutually agreed upon set of rules. If the results are irrelevant, confusing, or outrageous, then over time the organization will suffer and become less relevant.

	Allan
> 
>> 
>> Regards,
>> Tim Bowden
> 
> cheers,
>  ~adrian
> 
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss