This comment follows and summarizes some offline discussions.  First I want to express my appreciation for the journals efforts to promote open science. My concern is that an overly principled approach becomes artificial and creates a false sense of openness with out addressing the real problems, which are cultural.  First I would address this point in general, and then more specifically for the manuscript at hand.



For the general issue: a strict and formal approach to this issue creates a bureaucratic solution (or attempted solution) to a cultural problem. The cultural problem is open science.  Using frozen repos to provide snapshots of an implementation only creates the appearance of reproducibility.  Worse is that it puts the onus on the implementation rather than the idea.   I say 'appearance of reproducibility' because most complex codes only run on the machines they were developed on.  We estimated that we spent a good person year porting a version of ICON that ran on NV GPUs (P100s) on Piz Daint, to Juwels Booster which used A100s and a different software stack.  We estimated we spent 15 person years to get ICON to run on a different architecture (chip vendor and compiler) on LUMI.  So for all practical matters, for the complex codes, where really implementing an idea one's self is difficult, posting the code snapshot to a repo becomes a bureaucratic act that often is a misleading waste of time and energy.



Meaningful reproducibility is a manuscript that describes the methods well enough that someone can reproduce the results.  Here the results are not the exact numbers that the author produces, but the ideas that the numbers are used to advance.  Ideas should not depend on the details of the implementation and if they are then they are not robust, and this sort of testing is something the scientific process is designed to sort out.  Simply posting code snapshots, if they run at all, confuses the implementation with the idea, and there is a real scientific interest in having them separated.  



Furthermore having code as part of a living repo, for instance as a tagged version in an open development on GitHub (or similar), provides a much more organic connection between the developers and eventual users of a code, as the users can then contribute, incorporate bug fixes and so on.  If a bug fix changes the numbers but not the conclusions of a study it isn't something that should imply an addendum and comment in the journal, but it might change the conclusions of a different study that someone else does, and if so they should be rather directed by the manuscript to the open development as the reference on record. 



How we share our science  is a cultural issue.   GMD would do itself and the community a great favor by revisiting its policies, something that could be initiated by through an  open discussion.  In revisiting this I would rather look for ways to communicate best practices, by highlighting authors and reviewers who practice them.   In the end however, we don't want to restrict the field of ideas by saying that we don't want contributions that only present the idea but not the implementation.   If our policies become overly prescriptive we effectively make assumptions that have the effect of making science less open.



As for the more specific issue.  The  concern with EDMOND seems to be that the authors can retain editing rights and hence delete their repo after posting it.  Why not simply ask the authors to say that they won't delete the code on the repo.  I understand that moving the trust issue from the authors to the maintainers of the repo seems to give an additional layer of protection, but we also know there are many cases where data is deleted from public repos accidentally by the maintainers.  We also know that institutions that maintain repos will go out of business, so why do we emphasize institutional trust rather than personal trust and behavior.  All the more so why this singular focus on the implementation of an idea (the code) which in the end is supplementary.   Maybe this distinction is more clear if we recognize that no one would envision that every implementation of the same idea merits publication.  The idea not the implementation is the contribution.



In the present case a practical solution would be to work with repositories to give them more options to support good practice.  All the more so if the repositories are funded by major underwriters of the journal, as is the case here with MPDL being a major supporter of the Copernicus journals.  I ask the chief editors to take these points into consideration and review their policies, and also let the manuscript proceed through review as they do so.   In the end if they decide not to revise the policies, or if a satisfactory solution cannot be worked out with EDMOND, then we as authors would be faced with the decision to comply (upload a snapshot to zenodo)  before final publication.