According to the ODI data spectrum, data exists on a spectrum from closed, to shared to open.
Closed data is limited to internal use in an organisation. Shared data might be available to specific groups. Open data is data published under an open licence for anyone to access, use and share.
While it’s framed around data, the core concepts of the data spectrum can be applied to other types of work. Source code can exist on a closed-shared-open spectrum. And so can photos, books or other works.
The spectrum focuses on a single important aspect: who has access to a work.
But there are others facets we can consider. One of these is the level of collaboration that the licensor of the work is hoping to engage in.
Are they just licensing a finished work for other people to use? Looking for feedback or hoping to engage people in developing an unfinished work further?
We can describe that as a spectrum of collaboration, too.
There’s existing research around forms of collaboration and degrees of collaboration along a spectrum. But for the purpose of this blog post I’m going to propose a slightly simplified collaboration spectrum:
- No collaboration – the creator of the work (publisher of the data) either considers the work (or dataset) to be complete or finished, or has it not planning on developing it further.
- Seeking feedback – the creator of the work is open to receiving feedback on the work. E.g. around its form or function. There is no guarantee that feedback will be incorporated, decisions about doing that remain with the creator.
- Seeking contributions – the creator of the work is hoping to receive contributions that will improve the work. These might be in the form of suggested alternative text, contributions of additional data, bug fixes or improvements. There is no guarantee that contributions will be incorporated, decisions about doing that remain with the creator.
- Collaborative maintenance and development – the creator of the work is hoping to share the work of developing and maintaining the work with others. This means ceding some level of control over what improvements are made (although the creator might still control the infrastructure or define the means of doing that)
Where I think this is helpful is in clarifying the goals of the creator. In some cases a work is shared for reasons other than improving or maintaining it. The goal is to circulate that work to its intended audience. In other cases, there is a serious intention to coordinate and collaborate around a work.
This spectrum also implies some infrastructure, processes and effort on behalf of the creator:
- No collaboration – none, the work is just published
- Seeking feedback – there is a means by which feedback can be supplied, e.g. an email address, feedback form or similar mechanism
- Seeking contributions – there is infrastructure to support the submission (and rejection) of suggested contributions. E.g. adding suggested revisions to a document or pull requests for some code
- Collaborative maintenance – there is shared infrastructure and decision making to support the submission and inclusion of contributions
Often publishers of a work overlook the need for these processes. And the desired improvements never happen.
GDS recommends “make things open: it makes things better“. But the intention might not be to make that specific thing better. It depends what we’re trying to achieve. And unless there are processes in place to do that, it won’t happen.
If we combine this simple collaboration spectrum with a spectrum of openness, we can create a matrix like this:
| Closed | Shared | Open | |
| No collaboration | – | ||
| Seeking feedback | |||
| Seeking contributions | |||
| Collaborative maintenance |
If something its closed, it’s hard to have any form of collaboration really Although I think we can still usefully talk about collaborating within a very small group?
We can then apply that to categorise different initiatives. For example, around the publication of data:
| Closed | Shared | Open | |
| No collaboration | – | Census data | ONS statistics Bus time tables |
| Seeking feedback | OS data1 | OS data1 | |
| Seeking contributions | Google My Business Google Maps | Get Information About Schools (Edubase) | |
| Collaborative maintenance | CRM | OpenStreetmap Wikidata Discogs |
1 last time I checked, you could send in emails to flag errors in OS maps but not suggest fixes directly.
Moving things between different classifications requires not just a change in licence, but a change in processes. And, for collaborative maintenance at least, empowering others to make decisions.
This type of matrix also helps to illustrate that we can be open in more than just a narrow technical sense of applying an open licence to something. As I wrote yesterday, a commons needs more than open licensing.
Lost Boy 