ASCL.net

ASCL News

• Working towards Sustainable Software for Science: Practice and Experiences

  The 2nd Working towards Sustainable Software for Science: Practice and Experiences workshop (WSSSPE) will be held in New Orleans on Sunday, November 16. The community was invited to submit short actionable papers for use in designing the workshop.

  Getting a community to adopt better practices doesn't usually happen overnight. The ASCL has looked at previous efforts to create code libraries or registries to try to find common barriers that may have inhibited widespread use of these services; the ASCL also has looked to specific management techniques adapted from business practice to encourage change. These findings and change management strategies are discussed in our #WSSSPE 2 paper.

  The WSSSPE site lists all of the freely downloadable accepted papers.

  This entry was posted in conferences, news, WSSSPE on September 22, 2014 by Alice Allen.
• ASCL at ADASS 2014

  The ASCL will have a poster at the upcoming ADASS meeting in Calgary on the recent enhancements to the site.

  This entry was posted in ADASS, conferences on September 8, 2014 by Alice Allen.
• Saving software

  "...some of the greatest artifacts of the [astronomy] community’s creative problem-solving are at risk of being lost."

  I believe this; a good thing, since this is what Peter Teuben and I wrote in We didn’t see this coming: Our unexpected roles as software archivists and what we learned at Preserving.exe, one of three participant reports in "Preserving.exe: Toward a National Strategy for Software Preservation."
  

  This report arose from a summit held at the Library of Congress on May 20-21, 2013 by the National Digital Information Infrastructure and Preservation Program. Our piece discusses the summit itself, some of what we learned there, and its impact on the way we think about the ASCL and our work. Among the ideas raised at the summit was that of software as a cultural artifact. We wrote:

  The Summit broadened our view and appreciation for software as a cultural artifact and as a method of capturing creativity in problem-solving.

  Now we see the loss of computational methods that result in research as a loss of part of astronomy’s cultural heritage. This isn’t happening just for astronomy, of course; the Summit made clear that it is happening for everything. With so much rendered digitally, whether born that way or migrated to a digital medium, without preserving the digital artifacts and the software (and sometimes hardware) to lift these artifacts from their digital storage, we risk losing our art, our music, our games, our prose, our data, and our histories, of daily life and activities, of solutions to scientific problems, of popular pastimes and play experiences, and even knowledge of our computer worries and angst.

  More on what we learned at the summit is available in the full report, which includes excellent pieces by participants Henry Lowood, Stanford University (The Lures of Software Preservation) and Matthew Kirschenbaum, University of Maryland (An Executable Past: The Case for a National Software Registry), an introduction by Trevor Owens, Library of Congress, and interviews of Doug White of the National Institute of Standards and Technology's National Software Reference Library and Michael Mansfield from the Smithsonian American Art Museum.

  PreservingEXE: Toward a National Strategy for Software Preservation

  This entry was posted in conferences, discussion, ideas, news on January 28, 2014 by Alice Allen.
• New papers to read

  It's not just astrophysics; other sciences are also grappling with issues surrounding software release, transparency of research, and collaboratively sharing codes.

  The challenge of software licensing came up in the AAS 223 Special Session on code sharing; ASCL advisor Bruce Berriman followed up on this issue with a post on Astronomy Computing Today, and I've recently run across A Quick Guide to Software Licensing for the Scientist-Programmer, which also offers some guidance on this important issue.

  This entry was posted in best practices, conferences, ideas, musings on January 20, 2014 by Alice Allen.
• Tweets from and about the code sharing session at AAS223

  The code sharing crowd took over the AAS Twitter feed, it seems, during the Special Session on code sharing at AAS 223. Bottom up is the best way to read these, as the most recent tweet is on the top, and please note they aren't strictly in order of occurrence and I likely missed some (there were so many!). I'm happy to add those I missed if someone tells me about them. Thanks to all those who tweeted throughout the session!

  1. ASCL ‏@asclnet 10 Jan
     @shaka_lulu I keep a list of articles of possible interest to #astroCodeShare folks here: http://asterisk.apod.com/viewtopic.php?f=35&t=21544 …. #aas223
  2. Lucianne Walkowicz ‏@shaka_lulu 10 Jan
     For those who were interested in the #astroCodeShare session: "Best Practices for Scientific Computing": http://www.plosbiology.org/article/info%3Adoi%2F10.1371%2Fjournal.pbio.1001745 … #aas223
  3. August Muench ‏@augustmuench 7 Jan
     Relevant to #astroCodeShare #aas223 RT @swcarpentry: Our 'Best Practices' Paper Has Been Published: http://software-carpentry.org/blog/2014/01/best-practices-has-been-published.html …
  4. Nuria Lorente ‏@NoTruerAlien 7 Jan
     @augustmuench @bruceberriman Absolutely, but NOT releasing code also comes at a price, which is often forgotten. #aas223 #astroCodeShare
  5. Zach Pace ‏@zpacefromspace 7 Jan
     Just got finished with an awesome breakout session at #aas223 on code sharing. The moral: your code may be crap, but release it anyway!
  6. Nuria Lorente ‏@NoTruerAlien 7 Jan
     Morin et al: Informative paper on Sw licensing for Scientist-Programmer. MT @augustmuench: http://bit.ly/QlZKDP #astroCodeShare #aas223
  7. Chrissy Madison ‏@cmmadiso 7 Jan
     See. It happens! RT @bathompso: Pulling a @cmmadiso: my phone has 1% battery after the #astroCodeShare session. #AAS223
  8. Ben Thompson ‏@bathompso 7 Jan
     Pulling a @cmmadiso: my phone has 1% battery after the #astroCodeShare session. #AAS223
  9. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
     Astronomical source code library: http://ascl.net #aas223 #astroCodeShare
  10. Adrian Price-Whelan ‏@a_p_w 7 Jan
      RE: writing quick/dirty code to get papers out. "Weeks of programming can save you hours of planning." #aas223
      
  11. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Working group on astronomical software: http://aas.org/comms/working-group-astronomical-software-wgas … #aas223 #astroCodeShare
  12. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Hanisch: there should also be a prize for software, esp since Webber prize is for hardware only #aas223 #astroCodeShare
  13. August Muench ‏@augustmuench 7 Jan
      .@AlexaVillaume note: that paper is for software. licensing of *data/papers* is distinct but VERY important thing. #aas223 #astroCodeShare
  14. August Muench ‏@augustmuench 7 Jan
      . @AlexaVillaume try this paper: http://bit.ly/QlZKDP #astroCodeShare #aas223
  15. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Licensing: BSD or MIT and forget about it- but we should discuss it more as community - @davidwhogg #astroCodeShare #aas223 cc @jonmccann
  16. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      @jonmccann crap I had to answer an email and missed license discussion. Maybe check #astroCodeShare tag if someone else got it
  17. Christopher Hanley ‏@chanley 7 Jan
      @eblur27 Projects should include a citations file in repo right next to LICENCE.txt and README. Make it easier to be cidted #astroCodeShare
  18. August Muench ‏@augustmuench 7 Jan
      so @aaccomazzi brings us back to licensing: unlicenced code is the WORST. @davidwhogg echos this point #aas223 #astroCodeShare
  19. Lia Corrales ‏@eblur27 7 Jan
      Hey #astroCodeShare, I still want to know how I should cite software I get through github. Could help with fluid contributor lists #aas223
  20. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Something to be gleaned from size of room v attendance v perceived necessary size of room & how code is valued. #aas223 #astroCodeShare
  21. Ben Cook ‏@bacook17 7 Jan
      Reference in #aas223 code sharing session. http://wssspe.researchcomputing.org.uk
  22. Kelle Cruz ‏@kellecruz 7 Jan
      #AAS223 lots of different ways to share code...but I really want to spend time and energy making it expected & common practice.
  23. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Comment in back: u make good science by making good investments- invest in quality code by encouraging code sharing #aas223 #astroCodeShare
  24. Kelle Cruz ‏@kellecruz 7 Jan
      #aas223 I care less about how we data & code share. tech will work itself out. I want to make it a *requirement* for funds and publications.
  25. Alexa Villaume ‏@AlexaVillaume 7 Jan
      A mortifying story of a misplaced 2 in a program causing 8 years of research going down the drain. Share your code. It'll be ok. #aas223
  26. Meredith Rawls ‏@merrdiff 7 Jan
      .@kellecruz If it's easy to share code & get credit, we'll do it. Reminds me of this: http://theoatmeal.com/comics/game_of_thrones … #aas223 #astroCodeShare
  27. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      There are more ppl in this room than were in the Kepler session I attended yesterday. #aas223 #astroCodeShare
  28. August Muench ‏@augustmuench 7 Jan
      @jradavenport 225: Panel: MMMMMM Q: FMMFFFMM A: all M except 1 comment by F audience #astroCodeShare
  29. August Muench ‏@augustmuench 7 Jan
      So @eteq is gonna drop the mic: papers have fixed author lists. software authorship if fluid and grows. Et tu, ADS? #astroCodeShare #aas223
  30. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Reply: if it goes on arXiv you can never update contributor list, so subsequent contributors don't get credit #aas223 #astroCodeShare
  31. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Prsa: would be great if announcement of code went up on arXiv (I think they often do as release papers, e.g. emcee) #aas223 #astroCodeShare
  32. August Muench ‏@augustmuench 7 Jan
      interesting point: Montage built under contract to NASA; astropy built by cats, hosted on a cat based website #astroCodeShare #aas223
  33. Meredith Rawls ‏@merrdiff 7 Jan
      Andrej Prsa implores everyone in #astroCodeShare session to post code on astro-ph every time you submit a paper. #aas223
  34. Meredith Rawls ‏@merrdiff 7 Jan
      My advisor has said not to "waste time" writing generalized code; contradicting this is troubling. Mixed messages. #aas223
      #astroCodeShare
  35. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Cost to sharing: making code useable by anyone req more time than just making it work for you then publishing w it #aas223 #astroCodeShare
  36. Meredith Rawls ‏@merrdiff 7 Jan
      Recurring theme of how do I maximize research productivity and make my code useable for others? Not an easy Q. #AAS223 #astroCodeShare
  37. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      That is, proprietary data sometimes equates to leverage- there is prob some analogy in code community- @davidwhogg #aas223 #astroCodeShare
  38. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      panelists doubt ppl are being hired for a specific code as opposed to skill, but must be analogy w proprietary data #aas223 #astroCodeShare
  39. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Q: how do we reward ppl in ways that don't req keeping code proprietary? As in, ppl get hired bc they have the code #aas223 #astroCodeShare
  40. Lia Corrales ‏@eblur27 7 Jan
      Sad I'm missing #astroCodeShare, but reports of a packed room and massive twitter coverage are letting me stay comfy in COS session #aas223
  41. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Besides, every little thing you think no one else needs- *someone* will prob find it useful #aas223 #astroCodeShare
  42. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      A: do what you need, if no one else needs it then that's fine, you haven't made anyone's life worse - @davidwhogg #aas223 #astroCodeShare
  43. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Q: what's the balance bt needing to make code work for yourself vs making it useful for everyone always? #aas223 #astroCodeShare
  44. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Comment in back: u make good science by making good investments- invest in quality code by encouraging code sharing #aas223 #astroCodeShare
  45. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Katz: not really, unlikely beyond a few years' horizon at a time #aas223 #astroCodeShare
  46. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      No long term stewardship of code like there is for results (i.e. pubs)- does NSF have plans for that? - @davidwhogg #aas223 #astroCodeShare
  47. Ben Thompson ‏@bathompso 7 Jan
      . @kellecruz starting off the #astroCodeShare question session strong. Why no AAS reps here? #AAS223
  48. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Do you use other people's codes? Do you modify them or use them as is? #astroCodeShare #aas223
  49. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Do you share code? If not, why not? #astroCodeShare #aas223
  50. Meredith Rawls ‏@merrdiff 7 Jan
      Thoughts, #aas223 #astroCodeShare ? pic.twitter.com/a3fAEgT3wU
  51. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Benefits: perceived priority on work, visibility & good will, citations, bug-catching, and moral high ground - DWH #astroCodeShare #aas223
  52. Alexa Villaume ‏@AlexaVillaume 7 Jan
      Releasing code establishes priority and good will. Benefit from bug catching. Also, you get to be smug. #aas223
  53. Laura Watkins ‏@laurawatkins_ 7 Jan
      @davidwhogg: if you're not embarrassed by the code you released, you released it too late. #aas223
  54. Ian Paul Freeley ‏@ianpaulfreeley 7 Jan
      If your not embarrassed by your code/website, you launched too late--Hogg #aas223
  55. Ben Thompson ‏@bathompso 7 Jan
      If you’re not embarrassed by your code, you’re releasing it too late #AAS223 #astroCodeShare
  56. Meredith Rawls ‏@merrdiff 7 Jan
      .@davidwhogg debunks cons to code sharing. Only real cost is email & support requests. He knows of NO example of being scooped. #aas223
  57. August Muench ‏@augustmuench 7 Jan
      hogg: "if you're not embarrassed by the code/website you put out there then you put it out there too late." so good. #astroCodeShare #aas223
  58. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Cost: embarrassment! You know your code is crap, but if yr not embarrassed you released too late. -@davidwhogg #aas223 #astroCodeShare
  59. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Costs: getting scooped? @davidwhogg knows of no cases of scooping caused by *release of code* #astroCodeShare #aas223
  60. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      All papers, grant writing, etc - not just code - are developed out in the open since 2005. - @davidwhogg #astroCodeShare #aas223
  61. Matthew Turk ‏@powersoffour 7 Jan
      @augustmuench Not all good or new software is developed using github. Platforms should be transcended by applications. #astroCodeShare
  62. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      And boom, @davidwhogg right on time. Also, who mic'd him? #astroCodeShare #aas223
  63. Laura Watkins ‏@laurawatkins_ 7 Jan
      +1 MT @augustmuench "and this fact terrifies me because we have no idea collectively what sharing should look like. #astroCodeShare #aas223”
  64. August Muench ‏@augustmuench 7 Jan
      and this fact terrifies me because education -- we have no idea collectively what sharing should look like. #astroCodeShare #aas223
  65. August Muench ‏@augustmuench 7 Jan
      Who enforces software/data sharing in astronomy? YOU DO! WE DO! PEER REVIEW DOES! not nsf/nasa. #aas223 #astroCodeShare
  66. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Its UP TO YOU to include good data management plan as part of panel reviews. The community must enforce importance. #aas223 #astroCodeShare
  67. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Data management plans in NSF proposals are required to detail how results/data/software will be shared. - Katz #astroCodeShare #aas223
  68. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      NSF policy for sharing research results: supposed to share not only the data and the results but the software #astroCodeShare #aas223
  69. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      NSF does include "products" in addtn to pubs in bio sketches, but could be better abt following up on code release #AAS223 #astroCodeShare
  70. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Do we have policies that mandate code release in conjunction w publication or receipt of fed funds? #aas223 #astroCodeShare
      
  71. August Muench ‏@augustmuench 7 Jan
      Software that enables all this new software: Github, Travis, Sphinx, Jenkins. #aas223 #astroCodeShare
  72. August Muench ‏@augustmuench 7 Jan
      Agreed. RT @kellecruz: .@augustmuench we need to make data/code sharing requirements part of AAS journal policy. those two things. #aas223
  73. Ben Thompson ‏@bathompso 7 Jan
      Testing code is an important part of code sharing. #aas224 session? #AAS223
  74. Kelle Cruz ‏@kellecruz 7 Jan
      .@augustmuench we need to make data/code sharing requirements part of AAS journal policy. those two things. #aas223
  75. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      If you build it, they will code - Tollerud #aas223 #astroCodeShare
  76. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Need infrastructure, a few software ppl to do housekeeping, let scientists do whatev & set expectations - Tollerud #astroCodeShare #aas223
  77. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Most ppl who have contributed code to AstroPY have never met each other - all via @github - Tollerud #astroCodeShare #aas223
  78. Ben Thompson ‏@bathompso 7 Jan
      Almost 60 people (who have not met) have all worked together to build @astropy #astroCodeShare #AAS223
  79. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      AstroPY: a python library for and by astronomers, developed by self-herding astronomers since 2011 - Tollerud #astroCodeShare #aas223
  80. August Muench ‏@augustmuench 7 Jan
      I hoping that we see some cool diffs between the @astropy and montage *support* networks in the open discussion in #astroCodeShare #aas223
  81. August Muench ‏@augustmuench 7 Jan
      . @merrdiff "research objects" is I think the new age terminology. #aas223 #astroCodeShare
  82. David Morrison ‏@drmorr0 7 Jan
      @merrdiff Best advice I have: learn to use Git (or SVN, if you must), and use it for every single piece of code you write. #astroCodeShare
  83. Ben Thompson ‏@bathompso 7 Jan
      Astronomers are cats. #astroCodeShare #aas223
  84. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      I have used this exact cat herding graphic in Erik Tollerud's talk in an LSST talk hehe #aas223 #astroCodeShare
  85. August Muench ‏@augustmuench 7 Jan
      the @astropy project -- cat herding software development from @eteq at #astroCodeShare #aas223
  86. Ian Paul Freeley ‏@ianpaulfreeley 7 Jan
      Damn it--tweets from code sharing session sounded cool, but I got here late and now crowd out the door. #aas223
  87. Alex Parker ‏@Alex_Parker 7 Jan
      I'm nodding so vigorously at the #astroCodeShare tweets that I might need to ice my neck later.
  88. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Standing room only for #astroCodeShare at #aas223
  89. Dr Chris Tibbs ‏@chris_tibbs 7 Jan
      Love the fact that my timeline is currently full of great tweets about code sharing and EPO #aas223
  90. Kelle Cruz ‏@kellecruz 7 Jan
      #aas223 ok, maybe 20% women in code sharing session but still disproportionately tweeting. #interesting
  91. Alexa Villaume ‏@AlexaVillaume 7 Jan
      "I wrote my first fortran code when Apollo 12 was on the moon." #aas223
  92. August Muench ‏@augustmuench 7 Jan
      Decision to code Cloudy in C++ was partly motivated to use industry grade lang & give students real world job ops! #astroCodeShare #aas223
  93. Meredith Rawls ‏@merrdiff 7 Jan
      Learning about the CLOUDY code, but speaker has no visuals :( Jokes that the code can be opaque; "C++: write once, read never." #aas223
  94. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      Complaining astros aren't comp scientists is like saying they shldn't learn math bc they aren't mathematicians #astroCodeShare #aas223
  95. Timothy Pickering ‏@te_pickering 7 Jan
      #preach! RT @shaka_lulu: I'll paraphrase @mjuric here: code is to modern astronomy what calculus once was. #aas223 #astroCodeShare
  96. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
      I'll paraphrase @mjuric here: code is to modern astronomy what calculus once was. #aas223 #astroCodeShare
  97. Kelle Cruz ‏@kellecruz 7 Jan
      #aas223 could someone in the back of the code sharing session do a quick attendance & gender count? I'm in the front row...
  98. Jessica Lu ‏@jlu_astro 7 Jan
      @kellecruz Tell me if you figure it out!
  99. Kelle Cruz ‏@kellecruz 7 Jan
      #aas223 code sharing room is packed! I'm curious what brought them all here...
  100. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
       A: Abysmally. - Berriman #aas223 #astroCodeShare
  101. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
       Q: how much do you think we fail to educate our young researchers to write good code? #astroCodeShare #aas223
  102. Ben Thompson ‏@bathompso 7 Jan
       Q on why students are not educated on how to write good code (or code at all!) #AAS223
       We have all failed here.
  103. August Muench ‏@augustmuench 7 Jan
       The code base under question is Montage http://bit.ly/1aELvEz , dev'd & now volunteerly supported by IPAC scientists #aas223 #astroCodeShare
  104. August Muench ‏@augustmuench 7 Jan
       "Releasing your code comes with a price" -- @bruceberriman Hmm, let's see if this pivots to the positive+solutions! #aas223 #astroCodeShare
  105. Lucianne Walkowicz ‏@shaka_lulu 7 Jan
       Lastly, resist the pundit-technician divide. - Weiner #aas223 #astroCodeShare
  106. August Muench ‏@augustmuench 7 Jan
       I completely agree with @cloud149: a lot of our concerns about sharing code are "pseudo" or hypothetical problems. #aas223 #astroCodeShare
  107. Michelle Collins ‏@michelle_lmc 7 Jan
       We are failing to teach students how to write GOOD code in astronomy. Need to do better. Some programs in place, but not standard #aas223
  108. Laura Watkins ‏@laurawatkins_ 7 Jan
       "Do we do enough to teach our researchers how to write good code?" No. Fundamental skills but so many are left to learn alone. #aas223
  109. Kelle Cruz ‏@kellecruz 7 Jan
       #aas223 really interesting that nearly 100% of the women in the code sharing session are tweeting...all 4 of us. #exaggerating
  110. Laura Watkins ‏@laurawatkins_ 7 Jan
       Standing room only at the code sharing session. Apparently this is more popular than anticipated (this can only be a good thing)! #aas223
  111. Meredith Rawls ‏@merrdiff 7 Jan
       Astrophysics code sharing session 225 at #aas223. Let's stop re-inventing the wheel. Our hardware is built to last; why not software?
  112. Michelle Collins ‏@michelle_lmc 7 Jan
       Oh, there are no women on the code sharing panel. Are we not sharing code? I'm currently not, but i'm here to learn how to #aas223
  113. Ben Thompson ‏@bathompso 7 Jan
       Excited for the Astronomy Code Sharing session. Wondering what to do with all my research programs. #AAS223
  114. Erik Tollerud ‏@eteq 7 Jan
       #aas223, Tues@2pm: talking about lesson's from @astropy on how code can be shared, along side @owlice @davidwhogg @bruceberriman @cloud149
  115. Benjamin Weiner ‏@cloud149 7 Jan
       My talk "Occupy Hard Drives" for code session Tues 2 pm #aas223 is here: http://bit.ly/1acClmg @davidwhogg @bruceberriman @owlice @eteq
  116. ADASS ‏@astroADASS 7 Jan
       Follow discussion on astronomy code sharing at the #aas223 meeting using #astroCodeShare hashtag.
  117. Benjamin Weiner ‏@cloud149 7 Jan
       Tues 2pm #aas223 I aim to provoke on astro code sharing and why we don't respect software with @davidwhogg @bruceberriman @owlice @eteq

  118. Astropy ‏@astropy 6 Jan
       At the #aas223? Don't miss Tuesday's 14:00-15:30 session on code sharing - including a talk by @eteq about @astropy!

  119. David W. Hogg ‏@davidwhogg 6 Jan
       Tues at 2 see @owlice Hanisch Teuben @cloud149 @bruceberriman Ferland Katz @eteq and me get all crazy about #code sharing at #aas223 in NH5
  This entry was posted in AAS, conferences, discussion, ideas, special sessions on January 13, 2014 by Alice Allen.
• Astrophysics Code Sharing II: The Sequel at AAS 223

  On Tuesday, January 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 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 rather than before lunch on Monday, and another 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 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, and links to slides where applicable, is given here.

  • Occupy Hard Drives: Making your work more valuable by giving it away, Benjamin Weiner (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 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 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, 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 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 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.
    slides (PDF)

  • 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 data and software; he stated quite firmly that data include software according to the Government. He also said that it is up to the community via peer review panels 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 effort to self-organize the now ~60 code base contributors, and that this arose out of a common goal: to streamline astronomy tools written in Python, as having eight different packages to do the same thing means that 7/8s of the effort was wasted effort. He stated that technology now exists that provides good support for such an effort, including GitHub to manage the processes of many developers, Travis for testing code, and Sphinx for documentation, which is written as the code is written. He pointed out that agreement on the problem was the key in getting the effort to come together and that consensus, guidelines, and expectations make it work.
    slides (PDF)

  • Costs and benefits of developing out in the open, David W. Hogg (New York University)
    David started out by saying that everything his group does is open --  all papers, grant proposals, comments, and codes -- and has been since 2005, and that this was a pragmatic, not an ethical decision. He stated that the negatives others give for not releasing code -- getting scooped, embarrassment, time, e-mail and support requests, licensing -- are overplayed, and that since the public is paying for this, we should return the products we develop to them. He doesn't know of a single case of someone's getting scooped because he/she shared code. Rather, the benefits that sharing openly provides, establishing priority, visibility and goodwill, re-use and citations, feedback and bug-catching, and having the moral high ground, outweigh the overplayed negatives.
    slides (PDF)

  Discussion
  After David's presentation, Peter opened the floor for questions and discussion, and Kelle Cruz from Hunter College was ready! Kelle said that AAS should require code release and then asked whether anyone from the AAS journals was present. There was not.

  

  Kelle then suggested to Daniel Katz that the NSF should take stronger role in enforcement. Dan said he will see what he can do to get astronomy reviewers training for what to look for, and that he already does this for his area. David Hogg said there aren't any mechanisms for long-term stewardship of software and asked whether the NSF was looking at this. Dan said it is not at this time, and that the NSF generally avoids long-term commitment of funds.

  Someone in the back of the room pointed out that protection of code can also lead to the protection of errors, told a sad anecdote to illustrate that point, and commented that code sharing fosters improvements in coding practice. In response to a question about whether it was worthwhile to share very specific code, David answered yes, just post it, that if it's not useful to others, so what? But it just might be! And Benjamin Weiner suggested the code be put in GitHub.

  Two questions came from someone else in the back of the room, one on whether export control restrictions (ITAR) would be changing; the second question relayed that PhD students write a code for their thesis but then protect it because, in their perception, the code makes them employable, and did the panel have anything to say about that? Erik Tollerud made the point that people are hired for the skills that went into creating the code, not for a particular code. David replied that he has seen this with data, that proprietary data does sometimes give someone leverage for employment. Dan answered the ITAR question by saying that changes in ITAR were probably not going to happen soon.

  Another attendee asked about the cost of making code shareable, of what that cost is, and felt that the panelists had swept it under the rug. Ben replied that it's a community problem, the community needs to reward it, and there needs to be a values change. In the meantime, put it out there anyway; clean it up if you can, but put it out. David agrees there are costs, but the benefits are more substantial than the costs. The cost is not very large and the upside is larger than the downside. Bruce thinks it is worth the effort to plan upfront; that will save time/money later on. This is harder if the code is not initially planned, but one should try to address this when possible.

  Nuria Lorente, who was following the session from Australia through Twitter, tweeted that "NOT releasing code also comes at a price, which is often forgotten."

  Andrej Prsa from Villanova made a strong appeal to post code to arXiv; he stated that astro-ph should be open to other things beside preprints. Someone else pointed out that arXiv doesn't necessarily agree. David said that he put the documentation for emcee, the MCMC hammer on arxiv and that gets cited. Erik made the point about additional contributors to a software development project such as Astropy don't get credit if they are not on the author list on the paper uploaded to arXiv. Alberto Accomazzi from ADS mentioned that updating the author list on arXiv was a way to fix that and give others credit, even though that will not be reflected on ADS.

  Someone commented on the need for some sort of code sharing infrastructure to help with sharing. David commented that he wants all flowers to bloom, but some flowers are more valuable than others. Erik said that better search engines over time will help, that Astropy is more findable because of better search engines and because more people now link to it. It was mentioned that with more code sharing, finding useful codes may become more difficult as the signal to noise ratio goes down.

  Alberto Accomazzi brought up the uncertain provenance of code, code that does not have a license, and sometimes no author, attached to it, and stated that it is hard to deal with because it cannot be shared. This was echoed by David, who pointed out that a lack of a license for a code can prevent release. Bruce suggested a licensing workshop would be a good idea, and this idea got traction among attendees. The recent re-licensing of yt was brought up. Dan Katz looks specifically for licensing information when looking at proposal, and it's clear to him that many people don't know what they are doing on this and could use guidance. David suggested that people use BSD or MIT licenses if they know nothing about licensing.

  Peter Teuben then brought the discussion to an end and turned the podium over to Robert Hanisch for closing remarks.

  Session wrapup
  Robert Hanisch reiterated that software sharing is fundamental to the dissemination and validation of research results, and though there are carrots and sticks for software sharing, the sticks are not very strong. He also pointed out that nothing within the funding agencies offers support for software development and that there is a disconnect between national policy and implementation. Journals at best only encourage code release, too; they do not require it. A sociological change is necessary; in the meantime, he hopes those attending will just put codes out there!  The benefits outweigh the costs.

  He talked also about opportunity for change; as of Sunday January 5, the Working Group on Astronomical Software has Frossie Economou as its new chair, and that over the weekend, the Council of AAS had suggested that the WGAS be elevated from a Working Group to a Division within AAS. He had requested that the Council have the WGAS offer a prize specifically for software, and though the Council did not accept the idea upon presentation, Bob noted that a Division can award prizes independently. Having a Division focused on software will also provide more visibility for it, and on this hopeful note, the session ended.

  ... though the discussion continues...

  My thoughts (just a few)
  This is the fourth discussion session the ASCL has arranged; previous sessions include one at AAS 221 and two at the previous two ADASS meetings. (Links to materials or discussion from previous sessions are below.)

  I was glad to hear several of the presenters say the concerns people have about releasing their codes are overplayed. I was particularly happy when David said that if people would only go ahead and release their imperfect software, other people would see that released codes are also imperfect and thus feel more emboldened to release their own imperfect work. Yes! Lose the fear, gain the codes! It really doesn't need to be perfect; Nick Barnes, among others, have written eloquently, or amusingly, on this subject already. Astronomical software wants to be free; please release it, let it show!

  It was hard for me to stay silent when the need for a code sharing infrastructure was mentioned, not because I disagree with the need -- I believe the need is very great! -- but because the ASCL is trying hard to help with that. I've looked at other similar efforts tried over the years, and either they have started, lived (usually briefly) and in one case, even flowered, and died, or they still exist but are mostly silent and their efforts in code sharing dormant. The ASCL has been around since 1999 and is indexed by ADS, and use of it has been increasing. It's not perfect, but it does work and is actively growing.

  I believe that science should be as transparent as possible, that code release (absent ITAR and other truly compelling reasons) even if only for examination, not reuse, is part of this transparency, and that ultimately, code release is better for code authors, especially if the astronomy community works together to make it better for them. Code sharing can make astronomy more efficient, too, which is especially important in the current financial climate.

  Finally, I want to thank Peter for moderating the session, Bob for offering closing remarks, and the most excellent Ben, Bruce, Gary, Erik, Dan, and David for presenting at this session and also for not protesting even one time about the innumerable emails they received from me from May on. I also have to thank our wonderful volunteer whose name I did not get, alas, for her great work and for counting the 149 (!) attendees, the AAS for accepting the proposal in the first place, and the amazing people who sent this session literally around the world through their tweets. Thank you!

  AAS 221 Astronomy Code Sharing? links
  Announcement
  Omar Laurino joins Astronomy Code Sharing panel
  Brief blog post
  Astronomy Computing Today post
  Slides used at meeting: Google Doc  PDF

  ADASS XXIII (2013) links
  Announcement
  Our eight questions
  The eight questions that were discussed/links to discussion notes
  Pre-print of proceedings paper

  ADASS XXII (2012) links
  Birds of a Feather session
  Resources used/linked to for ADASS
  Pre-print of proceedings paper

  This entry was posted in AAS, codes, conferences, discussion, news, special sessions on January 13, 2014 by Alice Allen.
• What to do with an astronomy code? Share it!

  The poster I'm presenting at AAS 223 is below. Please stop by poster 255.25 on Tuesday; I would love to know whether you share your codes and why you do or do not.

  
  Abstract: Now that you've written a useful astronomy code for your soon-to-be-published research, you have to figure out what you want to do with it. Our suggestion? Share it! This presentation highlights the means and benefits of sharing your code. Make your code citable -- submit it to the Astrophysics Source Code Library and have it indexed by ADS! The Astrophysics Source Code Library (ASCL) is a free online registry of source codes of interest to astronomers and astrophysicists. With over 700 codes, it is continuing its rapid growth, with an average of 17 new codes a month. The editors seek out codes for inclusion; indexing by ADS improves the discoverability of codes and provides a way to cite codes as separate entries, especially codes without papers that describe them.

  Authors: Alice Allen, Astrophysics Source Code Library
  Alberto Accomazzi, Smithsonian Astrophysical Observatory
  Bruce Berriman, California Institute of Technology
  Kimberly DuPrie, Astrophysics Source Code Library
  Robert Hanisch, Space Telescope Science Institute/Virtual Astronomical Observatory
  Jessica Mink, Harvard-Smithsonian Center for Astrophysics
  Robert Nemiroff, Michigan Technological University
  Lior Shamir, Lawrence Technological University
  Keith Shortridge, Australian Astronomical Observatory
  Mark Taylor, University of Bristol, UK
  Peter Teuben, University of Maryland
  John Wallin, Middle Tennessee State University

  This entry was posted in AAS, conferences, news, poster on January 4, 2014 by Alice Allen.
• ASCL at AAS 223

  The ASCL will be at the AAS meeting in (not quite) Washington, DC next week; I'll be handing out (non-glowing) pens like crazy at both the ASCL poster (255.25, titled You’ve Written a Cool Astronomy Code! Now What Do You Do with It?) and the Special Session (more information below) on Tuesday, too. I hope you'll stop by the poster to say hi, talk codes, and grab a pen!

  The AAS's Working Group on Astronomical Software (WGAS) and the ASCL are holding a Special Session on code sharing that includes presentations and an open discussion. Peter Teuben and Robert Hanisch will moderate the session, which will be held on Tuesday, January 7, 2:00 to 3:30 in National Harbor 5, Gaylord National Resort and Convention Center.

  The panelists and topics for the session are:

  Benjamin J. Weiner, Occupy Hard Drives: Making your work more valuable by giving it away
  G. Bruce Berriman, Maintaining a user community for the Montage Image Mosaic Toolkit
  Gary J. Ferland, Cloudy - the non-equilibrium microphysics of gas and dust, and its observed spectrum
  Daniel S. Katz, NSF policies on software and data sharing and their implementation
  Erik J. Tollerud, The Astropy Project's self-herding cats development model
  David W. Hogg, Costs and benefits of developing out in the open

  After the presentations, Peter will open the floor for questions and discussion; at the end of the discussion, Bob will summarize the themes and points and will close the Special Session.

  We'll be tweeting, too, especially during the Special Session on Tuesday: @asclnet or #asclnet. See you (in person or online) next week!

  This entry was posted in AAS, conferences, discussion, ideas, news on January 2, 2014 by Alice Allen.
• ADASS BoF working documents

  Peter Teuben moderated today's BoF, which asked participants to brainstorm ideas for dealing with three categories of concerns: factors which inhibit code sharing, factors which encourage sharing, and overall community issues. The questions were in yesterday's blog post, along with a link to the introductory slides for the session. One of the questions posed was not selected for discussion; another was proposed by participant William O'Mullane (what tools are available for sharing code?).

  Each discussion group discussed one of eight questions; people were given the opportunity to move to another group for a second discussion. Scribes captured the ideas and comments of participants; the resulting documents can be found by following the links below.

  My thanks to Jessica Mink, Kimberly DuPrie, Omar Laurino, Mark Taylor, Bruce Berriman, Bob Hanisch, Kai Polsterer, and William O'Mullane for scribing, to Nuria Lorente for tweeting about the session, and to Peter Teuben for his leadership!

  Please feel free to add your own comments directly in the documents!

  Messy code Google doc Expectations of support Google doc University policies Google doc Recognition by citation Google doc

  Impact Google doc Journals and funding agencies Google doc Community at large Google doc Tools for sharing code Google doc

  This entry was posted in ADASS, conferences, discussion, ideas, questions on October 2, 2013 by Alice Allen.
• Eight questions...

  ... are being posed in the Ideas for Advancing Code Sharing (or A Different Kind of Hack Day) Birds of a Feather (BoF) session at ADASS. The eight questions ask how to deal with three categories of concerns: factors which inhibit sharing, factors which encourage sharing, and overall community issues. The questions are below; do you have answers to them? Please share them if you do!

  The introductory slides for the BoF are available online. We will post what comes out of the discussions shortly after the BoF.

  Mitigating inhibitors
  How do we encourage release even if the code is "messy"?
  How do we reduce expectations of support when coders don’t want to support code and still encourage code release?
  How can universities be convinced to change policies which prohibit software publication?

  Increasing incentives
  What can we do to encourage citations for codes?
  Beyond citations, what can we do to give code authors recognition for writing and releasing their software?
  How can we measure the impact of a code on research and its value to the community?

  Community factors
  What roles might journal publishers and funding agencies have in furthering code release, and how can the community influence them to take on that role?
  What else can we do to have code release recognized as an essential part of research reproducibility

   

  This entry was posted in ADASS, conferences, discussion, ideas on October 1, 2013 by Alice Allen.