One of these days I’m going to show my python code to someone who actually programs in python for a living. They’re going to laugh. Laugh and laugh and laugh… and laugh. And then cry.
David’s not the first scientist I know who’s said this, for example, I heard almost the same thing from Cameron Neylon last year when he was presenting to my final-year Web Research group. Cameron (who’s an advocate of Open Science) was demonstrating how he’d hacked up a bit of python to show the growth of Open Access publishing, but at the same time apologising that he’s originally a Bio-Chemist so the code does a job, but doesn’t necessarily do it as well or as ‘beautifully’ or efficiently as it perhaps might.
These are both examples of sharing code after its development. There are big advantages to publishing experimental code such as this during its development:
- It encourages peer review of the experimental process earlier in the project which may reduce the potential for errors due code not doing what is intended.
- It provides third party developers with the opportunity to be involved in research by actively contributing to the code by improving it, even if they are not specialists in the subject being studied, their specialism in software development adds orthogonal value.
- It provides subject specialists with opportunity to see how their code has been improved so they can learn from this and write improved code themselves next time, possibly seeing new solutions and experiment-options as a result.
Historically (however) it’s common that experimental code is published either:
- after papers are written and results are published, or
- never (even if there are good intentions to do so, time and funding dry up and the code dies alone). There may also be historic reasons why it’s not possible to publish code: often research organisations have little experience with Free Software so IPR fears can inhibit the potential openness of any project, but, the more open projects there are, the more opportunity there is for understanding to grow, fear to wane, and open science to blossom.
So, in the near term, developing non-critical code openly may be the best way forward. If researchers can get in the habit of developing tools, utilities and other small projects openly then that may be the first step to encouraging all scientists to think and solve problems as part of a global ad-hoc developer collective.