<div dir="auto"><div>Dear Peter,<div dir="auto"><br></div><div dir="auto">Thanks for the explanation, I'm a software engineer and I know very well how the process work. SQL is indeed a good example of a good standard almost everyone follows. But I would bet that's an exception in software. </div><div dir="auto"><br></div><div dir="auto">I raised the intended bugs thing because in recent years it had been very common to find intended "bugs" in proprietary licensed software to steal data or open ports to monitor usage. You never know how that will affect your tests. When you use software that you don't know what is doing in the background, you can't be really sure what the result will be. </div><div dir="auto"><br></div><div dir="auto">Kind regards, </div><div dir="auto">Maria. </div><br><br><div class="gmail_quote"><div dir="ltr">El sáb., 28 jul. 2018 19:48, Peter Baumann <<a href="mailto:p.baumann@jacobs-university.de">p.baumann@jacobs-university.de</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Dear Maria,<br>
</p>
<div class="m_-4920521315573284083moz-cite-prefix">On 25.07.2018 10:06, María Arias de
Reyna wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jul 25, 2018 at 9:57 AM,
Peter Baumann <span dir="ltr"><<a href="mailto:p.baumann@jacobs-university.de" target="_blank" rel="noreferrer">p.baumann@jacobs-university.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Hi Christian,</p>
<p><br>
</p>
<p>while I could not agree more to what you say there is
one point to disagree with:<br>
</p>
<span class="m_-4920521315573284083gmail-"> <br>
<div class="m_-4920521315573284083gmail-m_2576443925540070409moz-cite-prefix">On
24.07.2018 18:43, Christian Willmes wrote:<br>
</div>
<blockquote type="cite">
<p>Dear Suchith,<br>
<br>
I understand your point, and I also support your
views on this, but this is from my perspective a
too personal/particular issue, as to have it as an
"OSGeo open letter". Also, because this is more of
an ICA and not so much an OSGeo issue, I think. <br>
<br>
First, I would keep it more general. You address a
particular issue (UN SDG book published by esri),
and also some personal background (this should not
matter to the addressed subject). I would
recommend you keep it from being personal and
denouncing proprietary GIS vendors. If a company
plays by the rules of science, there is nothing
wrong about that company publishing a scientific
book. I.e. almost all book publishers are
commercial companies with interests somehow and
somewhere.<br>
<br>
You need to “attack” scientific “wrong doing” by
that particular company in conducting the editing
and publication of that book. Publishing books if
done correctly is not wrong, even by a vendor with
vested interests. But if you witness, for example,
that submissions using open source GIS solutions
are disadvantaged against the submissions using
products of the proprietary GIS vendor publishing
the book, that would be the point to raise and
attack.<br>
<br>
Second, better write about how it should be done
to avoid this negative “Fake Science” things from
happening. Here the idea of Open Science and
Reproducible Science is key, i.e. the most
openness and transparency possible. We just need
more transparency in science and also in the whole
process of editing/reviewing and publishing a
book. And this is where OSGeo can contribute.
Basically, real reproducible and open science is
not possible without open source software. If you
can’t see how something is implemented, you can
not really reproduce the results.<br>
</p>
</blockquote>
<br>
</span> No. Open science and open source software are
fundamentally different things. For example, if you
derive stats from some data set via SQL it does not
matter whether it comes from open-source PostgreSQL or
from proprietary Oracle. Because the SQL language in its
syntax and semantics is standardized, and it is assured
thereby that both systems will deliver the same results.
So standards actually are a prerequisite for science to
be comparable, but surely not open source.<br>
</div>
</blockquote>
<div><br>
<br>
</div>
<div>If you use proprietary products and can't verify that
the result is not due to a bug (even an intended bug ),
you are missing an important step on verifiability. Open
Source (as in "I can see the code") is an important piece
of open science.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
that's not what software engineers would do normally. If you feel a
tool has a bug you'd<br>
- try to isolate through a minimal failing example<br>
- possibly try with another tool (in the case of PostgreSQL, maybe
try MariaDB) for verification<br>
- definitely contact the support list (in the case of PostgreSQL,
Regina & friends)<br>
<br>
Unless it is some simple scripting issue you (that is: I) normally
don't stand a chance to dive into the code. Honestly, would we /
could we spot a bug in the source code for executing an index-only
plan of a distributed SQL query, after heuristic and cost-based
optimizers have done their work? I could not.<br>
<br>
Good software engineering practice is to work specification-based,
not by trying to hack yourself into code.<br>
<br>
And both of that _can_ work well with both open-source and
proprietary tools. Again, SQL is the shining example: a good
specification says it all.<br>
<br>
BTW, why do you raise, on the fly, the accusation that there may be
"intended bugs"? Any evidence for this? I'd like to learn more about
such cases.<br>
<br>
cheers,<br>
Peter<br>
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite"><br>
<fieldset class="m_-4920521315573284083mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
GeoForAll mailing list
<a class="m_-4920521315573284083moz-txt-link-abbreviated" href="mailto:GeoForAll@lists.osgeo.org" target="_blank" rel="noreferrer">GeoForAll@lists.osgeo.org</a>
<a class="m_-4920521315573284083moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/geoforall" target="_blank" rel="noreferrer">https://lists.osgeo.org/mailman/listinfo/geoforall</a>
</pre>
</blockquote>
<pre class="m_-4920521315573284083moz-signature" cols="80">--
Dr. Peter Baumann
- Professor of Computer Science, Jacobs University Bremen
<a class="m_-4920521315573284083moz-txt-link-abbreviated" href="http://www.faculty.jacobs-university.de/pbaumann" target="_blank" rel="noreferrer">www.faculty.jacobs-university.de/pbaumann</a>
mail: <a class="m_-4920521315573284083moz-txt-link-abbreviated" href="mailto:p.baumann@jacobs-university.de" target="_blank" rel="noreferrer">p.baumann@jacobs-university.de</a>
tel: +49-421-200-3178, fax: +49-421-200-493178
- Executive Director, rasdaman GmbH Bremen (HRB 26793)
<a class="m_-4920521315573284083moz-txt-link-abbreviated" href="http://www.rasdaman.com" target="_blank" rel="noreferrer">www.rasdaman.com</a>, mail: <a class="m_-4920521315573284083moz-txt-link-abbreviated" href="mailto:baumann@rasdaman.com" target="_blank" rel="noreferrer">baumann@rasdaman.com</a>
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
</pre>
</div>
</blockquote></div></div></div>