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

[Howard Butler]

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.

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

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

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

Howard
http://pdal.io