Government

Innovation resistance at Metro, part 1: The value of "bottom-up"

by David Alpert   •   September 29, 2009 12:58 pm

Yesterday, you saw the exchanges between Metro Directors Chris Zimmerman of Arlington and Gordon Linton of Maryland on open APIs and Google Transit. Linton wants to lock down all licensing issues before allowing new applications that use the bus position data (as NextBus does) or schedule data (like Google Transit), while Zimmerman advocated for "seeding" innovation and worrying about revenue later.

Photo by Mike Schmid.

To recap, there are two issues here. First, should Metro release its data generally to developers? They've released schedule data but under an unnecessarily restrictive license, and haven't released the bus position data at all. Second, should Metro try harder to work out a deal with Google to include Washington area transit directions in Google Maps, as every other large U.S. transit agency has done?

The Zimmerman-Linton exchange very clearly illustrates the dichotomy between the "open-source" philosophy and one of centralized control, or a "bottom-up" verus "top-down" attitude toward innovation. Writer and computer scientist Tim Lee discusses this issue frequently on his blog, Bottom-up. He explains, "The last couple of decades have brought us the dominance of the open Internet, the increasing success of free software," largely in Silicon Valley, "a place with extremely low barriers to entry, a culture of liberal information sharing, and a respect for the power of individual entrepreneurs." Because anyone can just make a Web site, write software for Windows, or sell a neat electronic gizmo (unless you want to connect it to a mobile phone network), we've had enormous innovation in these areas. It's precisely the absence of a gatekeeper who approves everything ahead of time that has enabled innovation to flourish.

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.

That's why the best policy for Metro is to make it very painless to participate. The Boston MBTA, Chicago CTA, Portland TriMet and others have created developer resources pages to help developers get started. Agencies need to keep well-meaning lawyers who don't understand the real costs of their involvement away from this. The best way to do that is to create a standard license agreement anyone can sign on to, one that doesn't demand payment, indemnification, or any other cost present or future.

There's a large benefit to riders of having these apps, and a very small potential revenue source. Trying to grab the revenue just kills the projects (and wipes out the revenue as well). Linton worried about people making money off bus position data. But right now, as Zimmerman noted, nobody is building any apps, period, and nobody is making any money anyway. Nobody wins that way.

Next: But what about Google and their billions of dollars?

David Alpert is the Founder and Editor-in-Chief of Greater Greater Washington and Greater Greater Education. He worked as a Product Manager for Google for six years and has lived in the Boston, San Francisco, and New York metro areas in addition to Washington, DC. He loves the area which is, in many ways, greater than those others, and wants to see it become even greater.