Topic: Use of External Resources for Standards development

Several suggestions have been made that the OGC should use external, online resources for its work.

A suggestion has been made that the OGC should develop its standards on GitHub.
  • PRO - The standard could be changed and modified ('forked') by anyone for their own purpose allowing for flexible changes.
  • PRO - The standard could be developed online.
  • CON - The whole purpose of having a standard is having a canonical document which changes only in carefully defined ways.
  • CON - The distribution of OGC standards across many locations would cause confusion.
  • CON - The reliance on external services adds the risk that OGC critical resources could be lost at any time due to changes in policy of that resource.
  • CON - Multiple incompatible deriviatives of the standard would cause interoperability issues.
  • CON - Standards could be developed in multiple, incompatible, non-interoperable formats.
  • CON - The text of the standard can already be taken and modified by anyone.
  • CON - The suggestion does not explain the ultimate purpose of this proposal, such as to use a distributed versionning system, to use the markdown or html format, or for another reason.
  • MIX - Developing internal SWG documents on public resources violates OGC TC rules on confidentiality.

Additional comment(s): 1)

Relations to other topics

Related to Topic..., since ...

Possible Actions

Discussion

I do not believe in this - on the contrary, this confuses, diverges, and ultimately kills the standardization idea. By definition a standard must favor a specific approach over all others. Does software get interoperable by putting it on GitHub? ;-)

-- PeterBaumann - 30 Jun 2013

I view this as a good out-reach effort to the developer community. While I respect the above feedback on confidentiality, there are a couple places where putting work on GitHub can help:

- Completed standards: Putting the result on GitHub would allow vendors to fork the original in order to document their vendor extensions to a standard. - Ad-hoc standards: collaborating on border line cases where a full standard may not be required (such as GeoJSON). - Engineering Reports: these are aimed a bit more for the developer target audience containing cold-hard implementation advise. Putting that level of content in GitHub as the perfect answer to Chris Homes rant on GeoPackage.

In all cases by using GitHub the OGC could track what ways the standard gets forked and view it as a feature request for the next iteration. There is no requirement to accept pull-reqeusts after all if you cannot sort out the IP consequences of contributions.

Aside: It can be done on the IP side of things - The Eclipse Foundation (operates in a very locked down manner which is extremely IP conscious) has recently sorted out a set of procedures to allow projects to function on GitHub while still respecting IP diligence: http://mmilinkov.wordpress.com/2013/06/20/embracing-social-coding-at-eclipse/

-- JodyGarnett - 01 Jul 2013


 

Consensus

The Leadership group has not yet discussed this topic.
Edit | Attach | Print version | History: r4 < r3 < r2 < r1 | Backlinks | View wiki text | Edit WikiText | More topic actions...
Topic revision: r3 - 30 Jul 2013, AdrianCuster
 

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding OGC Public Wiki? Send feedback