[OSGeo-Discuss] Re: [Board] Open Source and Open Standards White Paper

[Adrian Custer]

Hey Seven,

you two are working on a position paper which is hard to write well! So 
please take the critique below as encouragement and ideas, if you have 
time, to perhaps help you improve the structure of what you are trying 
to write.

On 04/14/2011 08:55 PM, Seven (aka Arnulf) wrote:
> Folks,
> please be so kind and give this paper a moment of your attention:
> http://wiki.osgeo.org/wiki/Talk:Open_Source_and_Open_Standards

In discussing the 'open standards', your point 3 related to OGC 
standards is actually *not* a policy of the OGC. OGC policies would 
allow patent encumbered standards requiring license fees; it is only by 
luck(?) that no OGC standard has yet been that way. Similarly, point 5 
is not true. WMS requires a document returned in XML which follows a 
particular schema. We currently are working on a new approach which 
would allow flexibility in 'data storage model{s} or format{s}' but we 
are not there yet and regardless we will probably always require a 
finite number of such formats---their standardization is part of our 
mandate. Point 6 is something I am not yet convinced of: recently a 
standard has been approved which is wholly controlled by a single 
organization (a single person really); it is not clear yet how this 
process will evolve and if control will be distributed from that person 
to a community of some kind. So perhaps you can change the lead it from 
'standards which are' to 'standards which aim to be' or you might revise 
the list of points.

In introducing 'Open Source' you discuss, appropriately, the aspects of 
freedom important to some software that labels itself with that moniker. 
However, you never relate that back to the openness of the source---it 
might be worth mentioning that freedom implies access to the source (to 
read, to rebuild, to modify), thereby explaining the label 'open 
source'. The second paragraph, the typical clarification of 'free' in 
'free software', does not make so much sense here since you have adopted 
the label 'Open Source' rather than 'Free software.' The list of 
freedoms is also problematic since they are germaine to 'free software' 
but not necessaryly to 'open source' software. Probably, it would be 
better to list the 10 requirements of 'open source' software you mention 
in the third paragraph, rather than the four requirements of 'free 
software'. As Cameron mentioned, you then launch into the variety of 
production styles in 'Open source' projects but really you probably want 
to go from the list of requirements to a list of advantages: both of the 
artifacts (can audit the source) and of the projects which produce them. 
'release early/often' is not a good in itself, indeed it forces users to 
vet the software they acquire---you have to talk about the benefits that 
such an approach can bring. Finally you end the section with 'real Open 
Source software' which is starting to be a mess; if there is 'real' and 
'fake' then that will need to be front and center not a passing 
reference at the end of the section.

In discussing 'open data' I disagree with your 'The most prominent open 
geospatial data project is OpenStreeMap.' By far the open data which has 
had the biggest impact on GIS these past four decades in my opinion has 
been the longstanding tradition of the US government that its data, 
funded by the people taxed by the US government, has already been paid 
for and therefore is part of the public domain. Colaborative data 
acquisitions efforts are fascinating and full of potential but are not 
necessarily 'most prominent' outside of our circle and build on existing 
traditions which have been going on for a while (e.g. the national bird 
survey in the UK) which have massive communities (never underestimate 
the birders). So perhaps you could talk about the real holdings of 'open 
data' to which we have access today: the various geoids, the STRM and 
global bathymetry hodlings, the MODIS archives, the global 
self-consistent hierarchial shoreline database, and others. That can be 
contrasted with the massive holdings which exist but are limited in use 
in one way or another, i.e. 'dark data' or 'closed data'. Finally, you 
can certainly talk about the more recent, community driven efforts to 
accumulate 'mass market' data like the road networks but note that those 
collection efforts are focused on particular kinds of data. In other 
words, this section, if you are going to include it, needs love.

On the OGC position towards open source software, you probably have to 
distinguish between the official position (agnostic), the position of 
the members of the consortium (globally for the existance of such 
implementations) and the de facto position (the OGC could but does not 
allow free certification of open source implementations). The change of 
person in the sentence starting 'Our goal ...', paragraph 2, is out of 
place with the rest of the document (we don't know without work that 
'our' is 'the OGC').

"OSGeo encourages project developers to adopt open standards." How does 
this 'encouragement' happen? I have never seen this expressed anywhere. 
Indeed, OSGeo seems to have a rich tradition of encouraging 'roll your 
own' innovation rather than of adopting existing standards. There is 
even active hostility towards ISO standards because one has to pay for 
the documents. So to my mind this reads less as reality than as what we 
might want; the reality is more ambivalent. It is true that a massive 
amount of work at the OSGeo uses existing standards but perhaps, 
ironically enough, not so much the open geospatial standards.

The conclusion starts with some reference to "ICT" whatever that may be; 
it seems weak.



Overall, I suspect readers are more interested in 'what it does for me' 
than in 'what it claims to be.' Therefore, I would encourage you to 
relate how open standards and open source software help build large, 
distributed, robust, sustainable spatial data infrastructures (SDIs) and 
how they help organizations of different kinds participate in those SDIs 
(by coding their own software that follows the standard, by using 
existing software that follows the standards, or by building on the 
standards to provide new functionality). The paper currently reads more 
like a definition than like an explanation of 'how they can help the 
reader'. On the standards side it might be worth mentioning there are 
standards for semantics (the abstract series), for services, and for 
data formats which have different uses to different publics. On the 
OSGeo side it would be worth talking about the disparity of the efforts 
to mention the hetergenity of the relationships with standards.


Sorry for the missive; I subject you to it because it would take me much 
more time to distill it to its essentials than it will take you to read 
through this mail.

ciao,
   ~adrian