Open Data, Public Good or Engine for Private Growth? – Lightening Talk at OGP Summit – 2015.10.28

Here is the deal.  Seoul City used to provide the real-time train arrival data so several apps using that data came into being.  People loved it.  However, Seoul City stopped providing the data citing the demand of the train operators who did not want to see other companies making money off of their operation.  Immediately, the apps stopped functioning.  Open Net Korea intervened making phone calls and publicly calling for provision of the data.  Seoul City reversed and now the apps are doing fine.

There was a service like Westlaw or Lexis-Nexis that provided but a charge.  However, the government began providing judgments database itself.  It is not a good one but still is at least as good as the one provided by the commercial provider.  The government’s provision will certainly run the commercial provider into bankruptcy.

Which one is a good story? Which one is bad?  If you find both stories good, you have a problem to solve.  In the first one, the private sector flourished thanks to the deferral of the government while in the second one the private sector will disappear because of the government’s entry into the market.

How do you distinguish the two cases?  Why is one better than the other?  How do you make the decision?  Should the State step in only when the market fails?  But when it comes to data market, it is hard to say whether the market is failing or not because it is hard to put prices on data.  When it comes to data, data is two-sided commodity.  Data benefits a person receiving and a person giving it.  Why should the State wait while people are paying for data?  Shouldn’t it be OGP’s mandate to pressure the State into providing those services itself so that people don’t have to pay anything?

This is what the UK government came up with as a guideline on whether to enter into digital services.

1 Start with needs* 2 Do less 3 Design with data 4 Do the hard work to make it simple 5 Iterate. Then iterate again. 6 Build for inclusion 7 Understand context 8 Build digital services, not websites 9 Be consistent, not uniform 10 Make things open: it makes things better

1. Start with needs* *user needs not government needs The design process must start with identifying and thinking about real user needs. We should design around those—not around the way the ‘official process’ is at the moment. We must understand those needs thoroughly—interrogating data, not just making assumptions—and e should remember that what users ask for is not always what they need. We use ‘needs’ as an organising principle since people come to our sites to accomplish tasks and to fulfil needs, not just to hang out. Focusing on needs means we can concentrate on the things that deliver most value for money.
2. Do less Government should only do what only government can do. If someone else is doing it —link to it. If we can provide resources (like APIs) that will help other people build things—do that. We should concentrate on the irreducible core. We’ll make better services and save more money by focusing resources where they’ll do the most good.
3. Build digital services, not websites Our service doesn’t begin and end at our website. It might start with a search engine and end at the post office. We need to design for that, even if we can’t control it. And we need to recognise that some day, before we know it, it’ll be about different digital services again. We shouldn’t be about websites, we should be about digital services. Right now, the best way to deliver digital services is via the web—but that might change, and sooner than we might expect. [omitted]

I have one theory.  Maybe, the state should not build data-based services full stop.  It will be very difficult to find a market failure in the data market.  The State should never run Facebook, should never run Google, should never run. . . . Thank you for listening.