Bringing open source to astronomy March 28, 2009Posted by Sarah in astro 2.0, science.
Tags: astronomy, computing, software
A very interesting paper was posted on astro-ph this week on software development in astronomy. Authored by Benjamin Weiner of Steward Observatory in Arizona and many colleagues, the paper is one of many on the State of the Profession submitted to the 2010 Decadal Survey for astronomy and astrophysics (lots of interesting papers in this category, check out the full list here). The position paper describes a problem that I think is well known in the astronomy community: that software development for instruments and large simulations is not adequately funded, and that the developers do not get the recognition they deserve for their extremely valuable work. They call for changes in the way that software development is tackled in research. I entirely agree.
The vast majority of astronomers in active research write computer programmes at some level, and as many of us all dealing with similar problems – statistical analysis of datasets, n-body problems, to name a couple – we all end up writing bits of code that has been written before (perhaps better). There’s nothing wrong with this, it’s just a huge waste of time and effort. We use the internet every single day for our research, yet when it comes to sharing software, the amount of (useful) code on the web is puny compared to what astronomers produce – and it’s often hidden away on 10-year old personal webpages. Much of it is not shared at all. If we can manage to catalogue and distribute observational data to all corners of the globe, surely we can do something similar for software?
A serious problem somewhat related to this is the systematic under-appreciation and under-funding of software development when a new instrument is developed. As the development of a pipeline and analysis tools is often one of the last stages of an instrument project, it gets rushed to compensate for time and budget overruns. These tools are often written by postdocs whose contract can run out before the job is done. Also, those postdocs may have a career to think about, which means they need to write papers. For those papers they’ll need to do some research leading to publications in prominent journals, and developing software, like building instruments, is not considered to be “hard science”. Those that are passionate about and excellent at developing software are treated like second-class citizens rather than “elite scientists” because they lack the scientific credentials (publications).
In the last decade or so I think organisations like ESO and the STScI have brought changes in this. Pipeline development for ESO telescopes, for example, is handled by ESO, so that a common data reduction and analysis platform exists for data for all VLT instruments. This has undoubtedly improved the situation as the development is done by specialists. But it’s not exactly ideal either. ESO will develop the data reduction environment but usually the instrument was built by a consortium of institutes in the member countries, not by ESO. Developing a good pipeline critically depends on understanding every quirk, nook and cranny of the instrument, its optics, its detectors. That’s the kind of knowledge only the scientists and engineers who’ve spent years designing, assembling, testing and calibrating it, have. So in this model there can be a disconnect between the software developers and the instrument scientists.
A further disconnect arises between the software developers and the users. Observers wanting to push the limits of an instrument’s capabilities frequently find the standard pipeline doesn’t provide the precision they need in, say spectral wavelength calibration or sky subtraction. And rather than work with the organisation to get improvements put in place, they develop alternative pipelines and analysis tools specifically suited for their science goals. While good science results from this work, I’ve spoken with software developers who are frustrated by the lack of feedback they get on the products they deliver to the community.
One suggestion Weiner and his colleagues make, and one that I like very much, is to set up a central software repository similar to those used for distributing open source software, like SourceForge. This seems like an excellent idea. It would give astronomers a centralised place where they can search for software tools that colleagues have written, and for developers it provides an excellent means for bug tracking and making their software better from the users’ feedback. Moreover, it would encourage new collaborations, perhaps between disciplines that cope with the same problems in different fields. Why not integrate it with the Virtual Observatory platforms that are becoming ever more powerful data mining tools – a direct link from a dataset to a repository of analysis tools that others have developed for it?
Another way for software developers to get more recognition for their work is publishing papers about their work. Currently this is only really possible once it has produced rigorous scientific results. That can take years. Other suggestions the authors list include better training at undergraduate and graduate level, including software releases in publications, and better institutional support for researchers that are talented at writing software.
I think this paper highlights a very important issue for the future of astronomy research, and I’m very happy to see it written. I hope it gets the attention it deserves.