Friday, 16 November 2012

Openscience.org

To explore how to carry out science in an open way, the best way to proceed has to be to find out who is already doing it and what lessons can be learned from their approach.

Today's post is based on my thoughts after looking at openscience.org. It's a website that hosts open source software for scientists, with  the majority of programs within maths, computational chemistry and life sciences. It also hosts a blog written by Daniel Getzler which gives pointers to good uses of open source within scientific research.

The concept of open source software is one that has existed for a long time and provides probably the closest working model of what my ideal research environment might look like. In fact, many of those writing open source software are researchers, who have a vested interest in as many people using their software as possible and little reason to restrict use or charge for their code.

What the open source software model tells us is that open collaboration can work and produce some really quite stunning results. Linux springs to mind - an entire computer operating system for free, mostly built by people in their spare time and given away for the benefit of many thousands around the world. Delving deeper, the structures used for software development can also be instructive. For example, the numbering of software versions shows a clear development and gives a staging point for other pieces of software to reference and establish compatibility. Bug tracking gives a nice method for community feedback, which might be feature suggestions or code deficiencies.

Where I see the most obvious application of these kinds of methods to experimental science is in protocols and standard operating procedures. If you are not familiar with these concepts, just think of them as the recipe for an experiment. Now imagine coming up with a new procedure for converting lead into gold. Under the current system, when you publish there could be all sorts of questions as to whether the protocol was robust. I have heard anecdotal evidence that in some fields important steps are deliberately missed out in papers to create difficulty for anyone trying to replicate the experiment. Now imagine that the protocol was published as a version 1.0 on a website similar to gihub or googlecode, or maybe something like these crossed with Wikipedia. On the download page there is soon a comment from Dr Rumpelstiltskin that his lab has successfully reproduced the results. This is confirmation that it works - under the current system no such feedback is possible without another publication that no-one is interested in reading. Later Dr Al-Kumis adds an improvement that increases the yield by 10%. With your permission the protocol is moved on to version 2.0. And so on and so on.

Ultimately your protocol can be used by many people, but you can still maintain ownership of it if you wish, or hand it on to others (i.e. keeping or sharing adminitrator rights). I think the move away from traditional publishing also allows for the addition of comments like 'this only worked with my left hand' which might be necessary for the protocol to work, but cause embarrassment in a published paper. I see no reason why this cannot be combined with peer review, the thing that many researchers value about publishing above all else.

And if you have any suggestions for an improvement on this method for publishing protocols, please let me know.

No comments:

Post a Comment