This is a post that has been brewing for a long while, so sorry if it smells a bit. The basic concept hit me during FutureGov‘s excellent CityCamp London event, and keeps reoccurring as I have chats with people and read stuff online.
It’s not a post about technology, really, but rather taking some of the lessons learned from technology and seeing how it can be applied to everyday public services.
The way I see it is this – places, whether cities, towns, villages, or larger areas like districts, counties or regions, can be seen as systems. They have a number of different sectors and organisations working within them, all of which have their own distinct processes, but all of which also interact with one another all the time.
When you think about it, it’s amazing that the system works as well as it does most of the time. These are complicated beasts.
So what about this open source business? Well, whilst in theory anyone can contribute code to an open source project, in general, not many people actually do. Instead, development is handled by a small core group, and most people’s effort is put into testing software and submitting bug reports.
This is the role I think citizens can play in redesigning local services – not necessarily producing solutions, but spotting the issues, the bugs, and reporting them. As Eric Raymond wrote in his seminal work on open source development, the Cathedral and the Bazaar, identifying problems is the hard bit, the bit where you need ‘many eyeballs’ – solving them should be straightforward for those that understand the system.
That’s not to say that citizens shouldn’t be involved in contributing ideas for improvements, but it shouldn’t be their only contribution. I suspect this is the reason why the success of ideation competitions across the world has been variable, as Andrea Di Maio has noted on several occasions.
A key part of the bug tracking process, though, is visibility, and this is what our public services lack right now as part of the feedback mechanism.
The bugs people identify are published on the web, categorised and tagged so they can easily be found. Other people try to recreate the bugs so they can be further tested. People suggest possible solutions, which the core development team may or may not take on board.
For place to work effectively as an open source system, then, we need an open, public repository of bugs that anybody can access.
After all, there are very few areas of service delivery that just one organisation has ownership of. Take anti-social behaviour – it’s a police matter, sure, but also a health one, an education one, a social services one. There are probably some community and voluntary organisations that have an interest too.
Any one of those services might have an easy solution to a problem, but if they don’t know about it because it was reported to someone else, then nothing is going to happen.
Likewise when people are submitting issues, or bugs, they don’t necessarily care which service they should be reporting it to. Which tier of local government? Is it a police matter? We shouldn’t force people to understand our hierarchies and structures just because they want to point something out that is going wrong.
Some people might be crying out ‘FixMyStreet!’ at this stage, and that site does go a certain way to answer some of the issues I’ve written about. But there are a couple of key differences. The first is the nature and tone of FMS, which the name makes clear. ‘Fix my street!’ yells the citizen. Maybe we should turn that around, and make it ‘How can I help you to fix my street?’ might be a more positive exchange.
Not only that, but while FMS provides a space for public responses to issues from the council, it doesn’t make the process of producing a solution an open one. It doesn’t open the conversation up to the other actors in a place, it doesn’t enable citizens themselves to contribute to the solution – whether through their ideas or actually physically doing something.
Here’s another example. Maybe someone reports a bug in the local public transport arrangements, getting from a village into the local town – there isn’t a bus early enough to get them to work. They could report the bug straight into the local council, in which case it would probably end up being pushed to the transport operator. But this misses the opportunity for perhaps a local private car hire firm to step into the breach, or indeed for a local resident to offer a lift. In the latter case, sometimes a problem in the system doesn’t need a system wide fix.
There are a number of challenges to open sourcing a place like this. A major one is the way that partnerships work at the moment, which can be incredibly slow moving, bureaucratic and not terribly collaborative. A more enlightened approach will be necessary – although in this age of public sector austerity, such an attitude is likely to be required anyway.
There is some tech required – the best place for the bug tracker is online, but throwing something together in WordPress or Drupal shouldn’t take anyone who knows what they are doing too long at all.
So this concept I think starts to tie together some of my thinking around coproduction, crowdsourcing, open source and my more recent outpourings on innovation and creative collaboration.
I’d be really interested in people’s thoughts. Please spot the bugs in what I’ve written!
Whilst the half baked thinking in this post is entirely mine, the bug tracker idea was originally blogged about by Tim Davies a few years ago; and the importance of visibility was made clear to me in a conversation with Nick Booth.
