Real-time bus tracking is one of civic technology’s easier calls. No one likes guessing when next bus will come: “Do I need to run for it?”, “Do I have time to duck into that corner store and get a newspaper?”, etc. So people immediately grasp the benefit of being able to ask their smartphone where the next bus is.
Wait — I know what you’re thinking: “Not everyone has a smartphone. Don’t be such a techno-élitist!” And you’d be absolutely right.
That’s why the way in which New York City is setting up their bus-tracking system is important:
The big win in civic technology is to build systems that become platforms upon which anyone can build new services, whether volunteer, commercial, or cross-governmental. And that’s exactly how New York City’s Metropolitan Transportation Authority (MTA) is doing it. Starting with their pilot of real-time bus-tracking along the B63 route in Brooklyn, and now expanding to Staten Island in the next phase, and then ultimately to the entire city, they are building an architecture that explicitly supports the development of new and varied applications beyond what MTA produces itself. More on that in a minute.
Procuring for an open architecture
What’s particularly interesting about this project is how it was structured as an open platform from the very beginning — starting with the procurement of the various components. The MTA separated the project into a software side [1] and a hardware side [2]. That might sound obvious, but it’s actually not how a lot of civic procurement happens. More typically, a city requests to buy a whole solution in one piece, and each interested vendor submits a bid encompassing every aspect of the project: the server software, the on-bus hardware that reports the bus’s position, the mobile phone applications and web applications to query the server, public display units… everything, the whole enchilada. Like so:
It’s easy to understand the attraction of this method for both sides: the city gets to externalize all the details and just write a check, and the vendor gets a big contract. But the disadvantages (for the city) are equally obvious: the vendor becomes the only competence center, the only place with enough expertise to service and maintain the system over the long haul. Great deal for the vendor; not such a great deal for the taxpayer.
There’s another disadvantage to monolithic procurement, too, less often remarked on: from a technology standpoint, big turnkey systems generally don’t have good entry points for requesting data and services in a programmable way. In tech-speak, they tend not to have good APIs (“application programming interfaces” — for example, the standardized set of request and response formats your phone uses to get map information from a mobile service provider is an API).
By separating the software side from the hardware side, and by making a few other key decisions, such as that the server software would be open source, the MTA has essentially forced their bus-tracking system to have good APIs — because the on-bus hardware uses published APIs to talk to the server software, and because the server software is now an independent piece whose value derives from being able to communicate with anyone’s client applications as easily as possible. Requiring that the server software be open source, as the MTA did, cements this last advantage: the best survival strategy for a piece of open source software in that position is to have as rich an API set as it can.
Structuring the project this way doesn’t necessarily increase costs — in this case, there’s no evidence that it did (the MTA selected an extremely competitive bid from OpenPlans and Cambridge Systematics), and it’s even likely to reduce costs over the long run, because it improves the competitive bidding situation: the MTA can use different software or hardware vendors for future phases, or even use multiple different vendors simultaneously, thus diluting the project’s overall risk. They can do this because the server software is open source (based on the OneBusAway software originally developed for use in Seattle) and thus any interested vendor can acquire expertise in it. And the MTA can use different hardware vendors because the API-oriented nature of the system means that there is no “secret sauce” whereby the hardware and software communicate using a proprietary protocol known only to the original vendor.
The MTA has thus incentived an open, extensible platform:
The power of open platforms
And that brings us to why this system isn’t just for people who happen to have smart phones: anyone can use those APIs, which means that corner store (where you’re thinking of buying that newspaper) can set up a display showing where the next bus is along its route; the MTA even lent out a couple of displays to demonstrate this. Or maybe someone will set up a display in their living room window near the bus stop, subsidized with ads (not everyone finds that an attractive future, but if it gets eyeballs that means people find it useful). Or maybe someone will set up a text-response service for people whose phones can do text messages but not apps.
All this happens outside the MTA’s budget: the MTA does not have to spend more money for these things to appear. All it has to do is structure the bus-tracking system in such a way as to enable spontaneous application development by third parties. For just a taste of what that can look like, here’s a short video about the evolution of open platforms in transit and here’s a list of all the apps that have been built on top of the MTA real-time data so far (just on the one-line pilot in Brooklyn). Many of these apps, like this one that lets you find out when the next bus is coming by calling from any phone, were developed within weeks of the data going live.
Since anyone can query and record bus positions over time (along the B63 route right now, and across all of New York City in the future), the MTA is enabling third parties to use that information to make predictions about bus arrival time, to analyze traffic patterns, to note and publicize service disruptions, and in general to things that formerly only a transit agency could do. That doesn’t mean the MTA itself won’t do these things — they’ve already released one month’s worth of data for the B63 route in Brooklyn, just as a sample — but it means that the MTA has bravely opened itself up to competition from the private sector: if some app developer thinks she can use the data to do something better than the MTA does it, then she’s free to try. That’s what platforms are all about.
Congratulations to the forward-thinking teams at MTA, Cambridge Systematics, and OpenPlans. We hope this project can be a model for other cities to follow.
Disclosure: OpenPlans is one of the founding partners of Civic Commons
References:
-
[1] mta.info/mta/news/books/pdf/110926_1230_Finance.pdf, page V-56 (section “List of Procurements for Board Approval, September 2011, Procurements for Ratification, Metropolitan Transit Authority”):
On-board Bus Hardware Subsystem Hosting and Maintenance
Cambridge Systematics, Inc
Contract No. 11084-0100 $7,526,026
-
[2] mta.info/mta/news/books/pdf/110725_1230_Finance.pdf, page V-7 (section "List of Procurements for Board Approval, July 2011, Procurements for Ratification, Metropolitan Transit Authority"):
On-Board Bus Hardware Subsystem
Verifone, Inc
Contract No. 11043-0100 to 0400 $55,000,000
[Summary: Verifone to receive $6,915,662 contract for Staten Island;
combined cost for the remaining four boroughs not to exceed $48,084,438,
with contracts to be competitively bid among vendors determined to
be technically qualified: Clever Devices, ACS, Cubic, and Verifone.]
New York City Bus Tracking: Procuring for an Open Architecture
Posted on December 7, 2011 by Karl Fogel in Commentary, Sharing Software
Real-time bus tracking is one of civic technology’s easier calls. No one likes guessing when next bus will come: “Do I need to run for it?”, “Do I have time to duck into that corner store and get a newspaper?”, etc. So people immediately grasp the benefit of being able to ask their smartphone where the next bus is.
Wait — I know what you’re thinking: “Not everyone has a smartphone. Don’t be such a techno-élitist!” And you’d be absolutely right.
That’s why the way in which New York City is setting up their bus-tracking system is important:
The big win in civic technology is to build systems that become platforms upon which anyone can build new services, whether volunteer, commercial, or cross-governmental. And that’s exactly how New York City’s Metropolitan Transportation Authority (MTA) is doing it. Starting with their pilot of real-time bus-tracking along the B63 route in Brooklyn, and now expanding to Staten Island in the next phase, and then ultimately to the entire city, they are building an architecture that explicitly supports the development of new and varied applications beyond what MTA produces itself. More on that in a minute.
Procuring for an open architecture
What’s particularly interesting about this project is how it was structured as an open platform from the very beginning — starting with the procurement of the various components. The MTA separated the project into a software side [1] and a hardware side [2]. That might sound obvious, but it’s actually not how a lot of civic procurement happens. More typically, a city requests to buy a whole solution in one piece, and each interested vendor submits a bid encompassing every aspect of the project: the server software, the on-bus hardware that reports the bus’s position, the mobile phone applications and web applications to query the server, public display units… everything, the whole enchilada. Like so:
It’s easy to understand the attraction of this method for both sides: the city gets to externalize all the details and just write a check, and the vendor gets a big contract. But the disadvantages (for the city) are equally obvious: the vendor becomes the only competence center, the only place with enough expertise to service and maintain the system over the long haul. Great deal for the vendor; not such a great deal for the taxpayer.
There’s another disadvantage to monolithic procurement, too, less often remarked on: from a technology standpoint, big turnkey systems generally don’t have good entry points for requesting data and services in a programmable way. In tech-speak, they tend not to have good APIs (“application programming interfaces” — for example, the standardized set of request and response formats your phone uses to get map information from a mobile service provider is an API).
By separating the software side from the hardware side, and by making a few other key decisions, such as that the server software would be open source, the MTA has essentially forced their bus-tracking system to have good APIs — because the on-bus hardware uses published APIs to talk to the server software, and because the server software is now an independent piece whose value derives from being able to communicate with anyone’s client applications as easily as possible. Requiring that the server software be open source, as the MTA did, cements this last advantage: the best survival strategy for a piece of open source software in that position is to have as rich an API set as it can.
Structuring the project this way doesn’t necessarily increase costs — in this case, there’s no evidence that it did (the MTA selected an extremely competitive bid from OpenPlans and Cambridge Systematics), and it’s even likely to reduce costs over the long run, because it improves the competitive bidding situation: the MTA can use different software or hardware vendors for future phases, or even use multiple different vendors simultaneously, thus diluting the project’s overall risk. They can do this because the server software is open source (based on the OneBusAway software originally developed for use in Seattle) and thus any interested vendor can acquire expertise in it. And the MTA can use different hardware vendors because the API-oriented nature of the system means that there is no “secret sauce” whereby the hardware and software communicate using a proprietary protocol known only to the original vendor.
The MTA has thus incentived an open, extensible platform:
The power of open platforms
And that brings us to why this system isn’t just for people who happen to have smart phones: anyone can use those APIs, which means that corner store (where you’re thinking of buying that newspaper) can set up a display showing where the next bus is along its route; the MTA even lent out a couple of displays to demonstrate this. Or maybe someone will set up a display in their living room window near the bus stop, subsidized with ads (not everyone finds that an attractive future, but if it gets eyeballs that means people find it useful). Or maybe someone will set up a text-response service for people whose phones can do text messages but not apps.
All this happens outside the MTA’s budget: the MTA does not have to spend more money for these things to appear. All it has to do is structure the bus-tracking system in such a way as to enable spontaneous application development by third parties. For just a taste of what that can look like, here’s a short video about the evolution of open platforms in transit and here’s a list of all the apps that have been built on top of the MTA real-time data so far (just on the one-line pilot in Brooklyn). Many of these apps, like this one that lets you find out when the next bus is coming by calling from any phone, were developed within weeks of the data going live.
Since anyone can query and record bus positions over time (along the B63 route right now, and across all of New York City in the future), the MTA is enabling third parties to use that information to make predictions about bus arrival time, to analyze traffic patterns, to note and publicize service disruptions, and in general to things that formerly only a transit agency could do. That doesn’t mean the MTA itself won’t do these things — they’ve already released one month’s worth of data for the B63 route in Brooklyn, just as a sample — but it means that the MTA has bravely opened itself up to competition from the private sector: if some app developer thinks she can use the data to do something better than the MTA does it, then she’s free to try. That’s what platforms are all about.
Congratulations to the forward-thinking teams at MTA, Cambridge Systematics, and OpenPlans. We hope this project can be a model for other cities to follow.
Disclosure: OpenPlans is one of the founding partners of Civic Commons
References:
[1] mta.info/mta/news/books/pdf/110926_1230_Finance.pdf, page V-56 (section “List of Procurements for Board Approval, September 2011, Procurements for Ratification, Metropolitan Transit Authority”):
Tags: Cambridge Systematics, MTA Bus Time, OpenPlans
About Karl Fogel
See http://www.red-bean.com/kfogel for more information.