Just a few days after Halloween, and with pumpkins adorning the refreshment tables at Open Data Camp 7, campers gathered at the end of day two to swap open data horror stories. Or, as leader Dan Barrett put it, to learn from their experiences and mistakes. Because that can be cathartic — and helpful for others.
A reflection on working at [a large public institution] and spending six years trying to improve its open data division. “I recognised that there was a division between its work and public understanding of what it did. And I thought open data could help to bridge that.” Things were going fairly well. “And then they went spectacularly badly, and the work stopped.”
What did the teller learn? “That it is important to own the story of your own work, and to think about how you tell it to other people,” particularly in an environment in which others are seeking to benefit from telling a counter-narrative, “discounting the work you do, playing down the benefits of what you do”, and diverting resources to other priorities. “So that is the lesson I am taking into a new role: Tell stories that resonate with everybody about data.”
This resonated with campers, who recognised that the instinct is to tell big, complex stories about “saving the world” or “saving democracy” or “saving the environment” with open data. When sometimes multiple stories need to be told for different audiences, who might, for example, be more open to hear about how open data can save money.
A tale about an open data initiative in [an English county], with a “grand ambition” to become a hub for the south, bringing in many organisations. Money came from the county council and for a while there was huge enthusiasm; but eventually the funder started to ask what it was getting for its cash. “There were lots of audiences saying they wanted this, and business was enthusiastic, but internally leaders didn’t get it. So, eventually there wasn’t enough defence and it withered on the vine.
What did the teller learn? That examples of good practice and initiatives that have worked are essential to keep making the case and to reassure leaders. At the time, there was nowhere to go, no Slack channel, no repository of knowledge to call on. Now, at least, the Open Data Camp blog has captured loads of useful examples.
A story called “no good deed goes unpunished” which related to some information being published by [a government department] about [some of the institutions that it regulated] and where they are, which was withdrawn because there was a perceived threat of it falling into the hands of extreme pressure groups – even though it is available via public search engines (or just driving around the country).
What did the teller learn? That data can be used in weird ways, and even though that might not be a reason to take it down, it can be used as a reason to take it down.
Not an open data story, but a failure story, about a surgeon removing the wrong kidney from a patient with kidney failure – and doing so even though there were four or five other people in theatre who could have stopped him.
What does this tell us? That culture is an issue, and it not only stops things happening, but fails to stop them happening. This completely resonated with another participant, who said that government projects are particularly afflicted by this, because they are big, and structured, and “you don’t just fail, you fail very, very bl**dy slow”. Which is much worse than the Californian attitude of “fail fast” because it eats away at confidence and resources.
A confession about data publishing, also involving a governmental release of data, but one that was pushed and released really fast. So fast, that nobody has ever been able to go back and structure it properly or monitor it. “It is just out there and it is causing mayhem.”
What did the teller learn? She just put her hands around her neck. For session participants, that careful thought must be given to “data infrastructure” – and to understanding that the infrastructure needed for the release of open data is different to the infrastructure needed to collect and manage data in the first place.
A tale about the perils of working with [a major open source tool] on which a map of New York was changed to Jewtropolis. Only for a few minutes, but long enough for users to spot it, snap it, and pass it onto the tech press.
What did the teller learn? That a tool change issue caused a problem, which was picked up and corrected, but not before damage was done. That the metric that was used for permitting the user who made the change to make them without oversight were not good enough and needed to be tightened up. That horror stories live on: even when their ghosts have been laid.