Software systems and software publications

7feb7bbc3605d995c6099de0e25b4b99?s=47 David W Hogg
January 06, 2017

Software systems and software publications

As given at #AAS229 in the Special Session on sofware organized by Alice Allen (ASCL).

7feb7bbc3605d995c6099de0e25b4b99?s=128

David W Hogg

January 06, 2017
Tweet

Transcript

  1. 1.

    relationships between software publications and software systems David W Hogg

    (NYU) (MPIA) (Flatiron) twitter:@davidwhogg GitHub:davidwhogg
  2. 2.

    example 3x3 quadratic-fit method for centroiding stars in the SDSS

    photometric pipeline Lupton et al, 2000-ish; Vakili & Hogg, arXiv:1610.05873
  3. 3.

    three related publishable entities a software system or pipeline a

    publication primarily about that system
 (pure software publication) a “science” paper that also describes the system
 (paper with a software component)
  4. 4.

    citation of software cite the source code (eg, via ASCL)

    cite a pure software publication cite a paper with a software component
  5. 5.

    benefits of writing a pure software publication serves as discoverable

    documentation preserves ideas in the code legitimizes the code; distinguishes it from competitors gets you refereed citations for your software work
  6. 6.

    example our emcee paper (2013 PASP 125, 306) has >1000

    citations and is getting 40 per month
  7. 7.

    costs of writing a pure software publication takes time and

    money produces a publication that some don’t respect distracts from other scientific or career goals
 (this is an opportunity cost)
  8. 8.

    time scales different costs and benefits accrue on different time

    scales eg, the time cost and the documentation benefit accrue immediately eg, the preservation of ideas benefit and the opportunity cost accrue over very long time scales
  9. 9.

    #LTFDFCF how you weigh costs and benefits depends strongly on

    your career stage and also the importance (to yourself) of your software work
  10. 11.

    the world is changing respect for pure software contributions is

    much, much higher than it was even 5 years ago (let alone 10 or 20) (Thank you, AAS community:
 Some of my students bet their careers on this.)
  11. 12.

    benefits of writing a paper with a software component preserves

    ideas in the code, or some of them legitimizes the code; distinguishes it from competitors refereed citations for your software work situates the software in an appropriate scientific context
  12. 13.

    appropriate scientific context (I know this isn’t a talk about

    open-source software, but:) one of the biggest costs of releasing a software system is time spent batting down inappropriate uses
  13. 14.

    costs of writing a paper with a software component takes

    time and money (probably) doesn’t serve the documentation value of a pure software publication
  14. 15.

    double jeopardy I don’t like the idea of refereeing the

    software systems in addition to the papers about them. I don’t like the statistical editor comments on data analysis papers submitted to the AAS Journals.
  15. 16.

    benefits of having no traditional publication save time and money;

    no refereeing headaches either citation of the software is direct citation of the relevant work the ASCL and ADS and GitHub have made all this very easy
  16. 17.

    costs of having no traditional publication documentation remains necessary citations

    are (currently) unrefereed (and less respected, perhaps) uncertain long-term value of citations; preservation issues hard to distinguish your software system from competitors
  17. 19.

    advice when you release software, explicitly state how you want

    it cited, alongside or very near the license statement
  18. 20.

    conclusions for me, the benefits of producing traditional publications are

    legion (though sometimes a bit intangible) both pure software publications and papers with a software component are very valuable the (new) direct cite-ability of software does not much diminish these benefits