Category Archives: questions

Codes past, still present (updated 8/21/2019)

At lunch yesterday, I was asked in what year the earliest code ASCL has was written (or was first created). I didn’t know off the top of my head, but thought probably in late 70s. (The earliest I ever pursued was from the 60s, IIRC, & though I found an working email address for the woman who wrote it, which was amazing in itself, she no longer had the code, alas.)

But the question got me to wondering, so in a quick look, here’s what I found: three codes that were initially created in 1978:

Cloudy (ascl:9910.001)
AIPS (ascl:9911.003)
ADIPLS (ascl:1109.002)

All of these have undergone further development and are still in use, as indicated by citations to them in papers published this year.

Are these the most long-lived codes we have? Are there codes that were started even before 1978 that are still in use? Probably. Maybe part of the Starlink (ascl:1110.012) code base? Something else?

If you know of one or can find one in the ASCL with a history that goes back further than 1978, please let us know in the replies.


UPDATE, August 21, 2019


Screenshot of tweet about the STARS code and its origins in the early 1970sYes! There is one code that goes back even further, to 1972. Warrick Ball (@warrickball), a postdoc at the University of Birmingham (U.K.), replied on Twitter that the stellar evolution code STARS (ascl:1107.008) got its start in 1971, and the 1972 article which describes the code is listed in the ASCL entry for it. The code is still in use and was cited earlier this year. There’ll be dark chocolate heading Dr. Ball’s way as soon as the weather cools off; kudos to him for finding the answer to this question!

Licensing your code

“Each developer holds copyright in his or her code the moment it is written, and because all the world’s major copyright systems—including the US after 1976—do not require notices, publishing code without a copyright notice doesn’t change this.”1

In the recent code sharing session at the AAS 223 meeting, both Alberto Accomazzi and David Hogg mentioned the difficulty of dealing with code that did not carry any license, copyright notice, nor sometimes even author information with it. Such code is difficult to share for transparency, reuse, or expansion. Letting people know whether and how they can use your code and/or share it is a kindness not just to them, but to the community and even yourself, whether you want to retain copyright on the code, choose one of the copyleft licenses, or make your code public domain.

Just beginning to think about licensing and trying to wrap your head around it? TechSoup offers a good introduction on licensing in Making Sense of Software Licensing, and I’ve previously mentioned A Quick Guide to Software Licensing for the Scientist-Programmer from PLoS in our list of general articles that may be of interest to astronomical software users.

If you already know you want an open source license for your open source software (OSS) but don’t know which to choose, the Choose a license site describes different popular open source licenses; it is a good resource for getting an overview of each of them. The Open Source Initiative also offers information on licenses and has a FAQ that is useful for clarifying such terms as copyleft, public domain, open source, and free software in addition to others one runs across when considering licensing.

Interested in retaining copyright within a collaborative free software project? This white paper from the Software Freedom Law Center identifies best practices for doing so. And if you’re thinking about changing a code’s license, you may want to read Bruce Berriman’s informative post, with plenty of resources in it, on his Astronomy Computing Today blog.

What resources have you found helpful for licensing? I am very interested in knowing, and hope you will please share them; thank you!

1 http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html

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

How long should you keep your codes? And your data?

I’m currently working on a report for the Preserving.exe: Toward a National Strategy for Preserving Software summit held at the Library of Congress in May. My head is filled with the reasons and ways (and lack of ways) to save software discussed at the meeting, and by software, I don’t mean necessarily astrophysics codes, oh no! All kinds of software: mainframe HR software and VisiCalc and Doom and old browsers and dBASE and … well, everything.

This has dovetailed nicely, or perhaps alarmingly, with recent readings, including a blog post by Kristin Briney titled How Long Should You Keep Data? and the Retraction Watch post which inspired it, JCI paper retracted for duplicated panels after authors can’t provide original data, about a 2007 paper which recently had one figure retracted because the authors could not provide the data from which it was generated.

Jon Ippolito of the University of Maine was at the summit and wrote about it in his blog post The Ex-files: how long will our software last?

How long indeed? And if you wanted to retrieve data from 2007, would you be able to even if you had the data files? Would you still have the tools available to get into them? In astronomy, probably so; with FITS, astronomy is better off than many sciences. Elsewhere, maybe not.

How long will astronomy software last? That might be unknowable; perhaps a better question, then, is how long should it last?