Breaking Changes
“A change in one part of a software system that causes other parts to fail”
Whenever we work on any project, software or otherwise, we always want to make improvements. In the software world these updates can be somewhat neatly divided into two catagories. Some improvements such as a bug-fix or an added feature might fit perfectly within the existing platform, and we might improve the end-user’s experience without any hassle -or without them even noticing. Deciding to make these kinds of changes is easy, and we do it all the time. Sometimes however you hit a point where you realise that a particular feature you would like to see is going to require some major upheaval. Everything that has been built so far assuming -and relying upon- X and you would like to change that to Y. So now we have to think about not only whether this change is an improvement, but also whether the benefits outweigh the cost of making that change.
If you haven’t guessed it by now I am pretty convinced that we have got to the stage in science where we need to make some of these breaking changes. We can try and encourage people to share their data, but if there is no incentive in the current system to do so it won’t be done to a re-useable standard, or at all. We can talk about ignoring impact factors and big journals but if we keep thinking that the end goal of a piece of science is a pdf document then we are still missing the point.
Crux of the matter being, before we point out where Open Science might break the current system, we need to remember it is already broken, and we might have to break it some more in order to fix it.