This article is written by Tim Hill, Data Standards and Technical Lead at the Open Data Institute

Over the past two decades, there has been an explosion in the number of movements urging ‘openness’: open access publishing; open source software; open data; open science. And often these are intertwined with powerful moral claims regarding, e.g. public access to publicly-funded research.

For public servants, however – particularly those working on large digital projects – openness may be not only an ethical ideal, but also an operational necessity. While the different initiatives listed above each have their own individual focus, one thing they have in common is a concern to safeguard transparency in complex domains.

Open approaches thus become important for public servants because, where algorithmic tools become sufficiently advanced – as in the case of simulation models – transparency is often the only way to guarantee accountability. Without it, algorithms and advanced research can become simple black boxes: inscrutable and therefore, in the public sphere, unusable.

At the very least, where research and digital projects aren’t open from the start, time spent opening them up to outside parties can inflict serious delays and overheads later. The recent case of the MRC’s Covid-19 modelling referred to in part one is a prime example, as is the controversy over GISTEMP climate models.

It should be noted that openness always imposes at least some overheads

Where possible then, openness needs to be “baked in” as early as possible. In an ideal world, all research outputs a project relies on should be unrestricted (open access); the data supporting these outputs should be freely available (open data), as are the processes followed to derive these (open science); and any software used for data collection and/or processing is publicly-viewable, testable, and modifiable (open source).

The spectrum of ‘open’

Of course, this ideal is not always practicable. Some domains – defence, intelligence – are necessarily ‘closed’ by default. More often, some aspects of a project need restricted access, while others can be open. Any project involving personal data will need to involve careful thought as to issues such as anonymisation and privacy rights when determining the degree of openness appropriate for its work. Typically, openness is not an either/or decision that can be applied across the board. The Open Data Institute has developed a Data Spectrum to help organisations work through data-sharing, open-license, and other issues on their path toward greater transparency.

In addition, it should be noted that openness always imposes at least some overheads. Where work is still at a preliminary stage – exploratory data-analysis or rapid experimental iteration, say – it makes sense to hold off opening it up until the effort is a little more mature and can serve as a foundation for further activity.

Opening up your project

Assuming, however, that you’ve taken the decision to use open approaches in your project, what next?

First, if you’re using code or research originally developed in an academic setting, there’s a good chance it’s open already. Research boards have increasingly made openness a criterion in funding decisions over recent years. Working with the university or lab behind the research, you should be able to get a good idea of how open their work is – and of any reasons why they might not be as open as you’re expecting.

Second, try asking yourself some basic questions about your project and the work you’re undertaking:

  • What percentage of published research outputs are freely available, and which are behind a paywall?

  • How easy is it to find and use the data this research is based on? Is it available in an institutional repository, as a paid service, or is it simply in the possession of the researchers?

  • How easy would it be for another team of researchers to replicate research results, given only publicly-available information?

  • Is any code used available in a public repository on an open source platform such as Bitbucket or GitHub? If not, why not?

Asking these questions from the outset can help you avoid unpleasant surprises later, and build trust in the increasingly complex systems we’re using to address our most urgent problems today, from Covid-19 to climate change. — Tim Hill

We want to hear what you think about this article. Pitch an article to us or send your comments to hello@apolitical.co

(Photo credit: UnSplash)

Make sure to share your own thoughts with the author by leaving a comment below