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

[Carl Reed]

Hi Howard -

Some clarification on GeoRSS. As one of the original 5 who defined and
documented GeoRSS, I disagree with some of your statements. The OGC had
zero (0) input or oversight of the GeoRSS development. Sure, at the time
Raj and I were OGCs staff and the others were OGC members. And later,
others (non OGC) joined the discussion. The group decided to define GeoRSS
outside the OGC process - but still based on the consensus of the group.
There were never any license or IP issues. GeoRSS was released under CC
Attribution ShareAlike 2.5.  The original GeoRSS collaborators recently
agreed to move to CC Attribution ShareAlike 4.0. Under the OGC Community
Standard P&P there is no (zero) requirement to transfer ownership or
intellectual property to the OGC - just the rights as per CC 4.0. Further,
there is no requirement for the OGC to take over maintenance. Finally,
there is no requirement for normative changes to the document - unless an
error is encountered.

The GeoRSS White Paper I wrote back in 2006 or so has a detailed history of
the development and final deployment of the GeoRSS spec:
http://portal.opengeospatial.org/files/?artifact_id=15755

Regards

Carl


On Mon, 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.
>
> > 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
> _______________________________________________
> Standards mailing list
> Standards at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/standards




-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

"When the power of love overcomes the love of power the world will know
peace." Jimi Hendrix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/standards/attachments/20170130/626e846b/attachment.html>