I started this blog because I like writing about how bottom-up thinking can make the world a better plice. But one thing I like better than writing about it is when someone else does it for me. I hope David Alpert doesn’t mind if I quote liberally from his post at the excellent Greater Greater Washington blog:
Bottom-up thinking upset the established order when it hit the software industry in the form of open source software, and it’s even more revolutionary in an agency like Metro, which tends to approach issues from a top-down point of view. Need some new railcars? Bid out a contract. Want to create an online system to track bus locations? Bid out a contract. For railcar procurement, there’s nothing wrong with this strategy. But for consumer information technology, where you don’t need only one type of railcar, this approach fails to stimulate innovation.
Opening up data allows both large companies and small “garage” developers to build applications. The policies of an organization affect both, but the economic forces affecting these are very different. If a larger company is going to work with Metro, they’ll probably only do it if there’s some money in it, which means they’re willing to spend some lawyer time upfront to negotiate a good contract. Transaction costs aren’t good, but they won’t necessarily derail the project entirely.
A garage developer, on the other hand, is probably doing the project in his spare time, for fun. Even if there’s the possibility of making some money, such as selling the app for $5 a pop in the iPhone app store, it’s not going to be a major source of profit. Most likely, those fees won’t even come close to compensating the author for his or her time. If he’d put the same amount of time into working for a tech company, he’d make way more. He might even have made more working at McDonald’s than spending the equivalent amount of time on the application.
This is one fallacy in Gordon Linton’s admonishment that someone out there might be “lining their pockets.” Perhaps sometimes that’s the case, but most of the time they’re lining those pockets with enough to buy a nice lunch.
Because the money is a secondary consideration at best, the transaction cost is a huge deterrent. If the developer has to even spend one afternoon negotiating with Metro, it’s a big burden. To Metro, it’s no big deal to put weeks into carefully assembling a deal. To the developer, the thing could have been done already. Therefore, most people won’t even bother. There are plenty of neat ideas out there that could make a good app. Why build the one that forces you to waste a lot of time not programming when you can just start coding on something else? Programmers want to be programming, not negotiating with bureaucracy.
I couldn’t have put it better myself. Don’t miss part 2 and part 3 of David’s series on the battle to open up data about the DC metro system.
The bottom-up argument David is describing is the basis for RECAP, which I described here. The Los Angeles Times recently ran an article that looks at three key figures in the movement for web-enabled government transparency and includes a nice RECAP mention. And here is a paper by several of my colleagues making the theoretical argument for a bottom-up regime for the presentation of public data.
