[OSGeo-Standards] OGC vote on LAS 1.4 as a community standard

[Scott Simmons]

Howard,

> On Jan 30, 2017, at 9:28 AM, Howard Butler <howard at hobu.co> wrote:
> 
> On Jan 30, 2017, at 7:21 AM, Scott Simmons <ssimmons at opengeospatial.org> wrote:
> 
>> The “consensus-based standards organization” is the OGC,
> 
> This is true, but OGC is also a member organization that serves and is supported by its paying membership. A decade ago, OGC was widely bolstered by numerous open source implementations for its standards, and those open source implementations and their contributors were not given equal (or any, without full membership fees) seating at the table when it came time to constructing and ratifying specifications. There are now avenues for open source participation within OGC, but it is not clear those participants get to act as full members within technical committees. Regardless, the OGC sausage is mostly made during high-bandwidth, in-person meetings throughout the world, and many open source contributors do no not have the financial wherewithal to participate at that level.

OSGeo gets dedicated membership in OGC with more free attendees than are permitted for our other alliance partners. So there is opportunity to participate as full members of any Standards or Domain Working Group. Some folks are quite active in some of the groups, others less so.

> 
>> another (GeoRSS) was created by a small group of volunteers.
> 
> OGC's shepherding of GeoRSS and corresponding implementation and ownership confusion was a very significant event that shaped my active participation in community-oriented standards efforts like ASPRS LAS and GeoJSON. GeoRSS was frustrating experience. The lesson of GeoRSS was an OGC "community stamp" should not ever be a quitclaim deed to transfer the community management and ownership of the specification to OGC, especially if the community of implementations around that document is still actively using, engaging, and supporting it.
> 
> Like LAS and GeoJSON, GeoRSS initially came from the wider little-g geospatial industry from a subdomain that OGC membership were not really paying any attention. Once each gained some traction, they became more interesting to OGC membership, and the desire to do and say something about them became stronger. On one hand, it's a good idea to reference existing things and not iterate competing-but-different ones. On the other, the organizational impedance between OGC and the unique communities that birthed these documents and their implementation communities can cause trouble.

Your observation is spot-on: OGC membership as a whole often does not catch on to a concept or concrete effort until it has some traction. We are trying to be more proactive in watching for emerging trends in the industry (with a dedicated session at each of our quarterly meetings going forward) and also hope to bring in some of those concepts through the Community standards process.

> 
>> This is a new process in the OGC, so we don’t yet have a feel for how successful or not the efforts may be.
> 
> Please forgive some bad analogy. These community standards that OGC seeks to brand are like 14 hour BBQ. They were created over much longer time scales than typical OGC ones. Their fat is slowly rendered by multiple implementations continually iterating together. Their bark is hardened by real world consumption and use. Their flavor is heightened by the set of choices made at the beginning of the process that set them in motion.  Once made, they are pretty much done, and modifying their flavor, texture, or color afterward has the effect of destroying what made them great in the first place. As long as OGC's community program doesn't seek to change the recipe after the fact, or claim they made it in the first place, everything should be fine. 

Excellent analogy other than my brisket usually takes closer to 16 hours at my elevation. The Community standard process in no way wants to turn perfectly good BBQ into meatloaf. We require that each candidate be frozen and that updates only come to us as the originating community feels ready. However, we may want to add some potato salad and jalapenos on the side and use the Community standard as an ingredient in some new standard effort as a normatively-referenced component.

> 
>> Some of these Community standards may eventually come into the OGC for permanent maintenance (much like KML did, although that was a different process)
> 
> What does permanent maintenance actually mean?

There could be a case where a spec entered into the OGC as a Community standard and the originating body no longer wants to manage the spec, update, etc. That spec could then be considered for inclusion in the full standards track in the OGC should the larger community wish to see the work maintained.

> 
> Howard
> http://pdal.io <http://pdal.io/>
Thanks,
Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/standards/attachments/20170130/49bab7e0/attachment.html>