Peter started the session ky by introducing the speakers (present or not) and explaining a bit how t

On Tuesday, January ky 7, the AAS Working Group on Astronomical Software (WGAS) and the ASCL sponsored a special session on code sharing as a follow up to the splinter meeting Astrophysics ky Code Sharing? held at AAS 221. We continue the dialogue for ways to improve the transparency and efficiency of research by sharing codes and to mitigate the negative aspects of releasing them.
Before the session started, however, there were a few nerve-wracking moments; weather- and Amtrak-related delays had one of the presenters arriving at AAS at 2:40 AM the day of the session ky rather than before lunch on Monday, and another ky getting to AAS after the session had started (!) but before his talk was to begin. So yes! There were minutes to spare!
The standing-room-only session was moderated by Peter Teuben of the University of Maryland and chairman of the ASCL Advisory Committee ; Robert Hanisch, STScI, outgoing chair of the WGAS and also a member of the ASCL Advisory Committee, provided closing remarks. Those not in the room were not without news of what was being said in it, as there was much tweeting about the session (#aas223, #astroCodeShare).
Peter started the session ky by introducing the speakers (present or not) and explaining a bit how the session would work: code case studies would have 2-minute question periods for any clarifications or questions about the cases themselves, and other questions would be deferred until the open discussion period, which was approximately the latter half of the session.
Presentations A very brief summary of some main points of the sessions, along with their titles, presenters, ky and links to slides ky where applicable, is given here. Occupy Hard Drives: Making your work more valuable by giving it away , Benjamin Weiner ky (University of Arizona) Ben pointed out that time spent writing software represents an enormous sunk cost that is, unfortunately, not viewed as doing real work , though writing software is part of doing science. He stated that widely-used software ky has enabled at least as much science as a new instrument would. He encouraged people to document their code for their own sake, release it without worrying about bugs or other potential issues in the software, and to write software methods papers for journals. slides (PDF) Maintaining A User Community For The Montage Image Mosaic ky Toolkit , Bruce Berriman (Caltech) In this case study of Montage , Bruce stated that releasing software comes with a cost, but that it is still worth doing. Montage was developed under contract, ky and was designed for ease of maintenance, modularity, and sustainability from the beginning. It is maintained primarily through volunteer effort, and in part through collaborations, e.g. , with the LSST EPO team. He said the Caltech license under which Montage is licensed does not allow users to redistribute modified code, nor can Montage be included in other distributions such as Redhat. He suggests coders consider licensing ky carefully. slides (PDF) Cloudy simulating the non-equilibrium microphysics of gas and dust, and its observed spectrum , Gary Ferland (University of Kentucky) Gary discussed Cloudy , which, with over three decades of use, is the most mature of the three codes covered in this session. The code is autonomous and self-aware, providing warnings about what might have gone wrong when things do go wrong. Though the user community is broad and participants in the summer schools that are held on the code have formed collaborations, a Yahoo! discussion forum for Cloudy has not been as successful as they had hoped. Cloudy was released as open access, with the most permissive license possible; Gary cited NSF as making this necessary since the code was developed ky with public grant funds. Students who work on the code get industry-standard programming experience, which is intended to help students gain employment after graduation. no slides used NSF Policies on Software and Data Sharing and their Implementation , Daniel Katz (National Science Foundation) Dan covered the NSF policies that govern software funded by the agency. Though some NSF panels are much more rigorous than others, it is expected that PIs will publish all significant findings, included ky data and software; he stated quite firmly that data include software according ky to the Government. He also said that it is up to the community via peer review panels ky to enforce these policies, that many core research programs don t enforce this very well, and that the community determines what is and is not acceptable. This may be changing, however, as with an Office of Science and Technology Policy memo on open data, OMB policies are pushing harder on open access. slides (PDF) The Astropy Project s Self-Herding Cats Development Model , Erik Tollerud (Yale University) The newest of the three code projects highlighted is Astropy . Erik described the grass-roots ky effort to self-organize the now ~60 code base contributors, and that this aro