[OSGeo-Discuss] [Geo4All] Draft of Open Letter on the importance to protecting independent peer review frameworks for Scholarly publications of Scientific Associations

[Peter Baumann]

Dear Maria,

On 25.07.2018 10:06, María Arias de Reyna wrote:
>
>
> On Wed, Jul 25, 2018 at 9:57 AM, Peter Baumann <p.baumann at jacobs-university.de
> <mailto:p.baumann at jacobs-university.de>> wrote:
>
>     Hi Christian,
>
>
>     while I could not agree more to what you say there is one point to
>     disagree with:
>
>
>     On 24.07.2018 18:43, Christian Willmes wrote:
>>
>>     Dear Suchith,
>>
>>     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.
>>
>>     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.
>>
>>     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.
>>
>>     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.
>>
>
>     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.
>
>
>
> 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.

that's not what software engineers would do normally. If you feel a tool has a
bug you'd
- try to isolate through a minimal failing example
- possibly try with another tool (in the case of PostgreSQL, maybe try MariaDB)
for verification
- definitely contact the support list (in the case of PostgreSQL, Regina & friends)

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.

Good software engineering practice is to work specification-based, not by trying
to hack yourself into code.

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.

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.

cheers,
Peter





>
>
> _______________________________________________
> GeoForAll mailing list
> GeoForAll at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geoforall

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: p.baumann at jacobs-university.de
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: baumann at rasdaman.com
   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)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20180728/2d660e76/attachment.html>