Being active in open data for transit and real-time passenger information, one of the complaints I sometimes hear leveled at transit agencies is "They're not on NextBus!".

This bothers me. A lot.

Why? There are two reasons. The first is pretty simple. Sometimes, when people say "NextBus", what they really mean is real-time passenger information, without any concern for the specific provider. But "NextBus" is a trademarked name for a specific proprietary real-time passenger information provider; if what you really mean is "real-time passenger information", then say so.

The second reason is more pernicious. A lot of people use mobile apps for transit which are designed around the NextBus API. So, they work everywhere that the local transit agency has elected to contract with NextBus for real-time passenger information. On its face, this seems like a huge success for transit riders—one app for dozens of cities! But, it's not. Vendor lock-in isn't the way to achieve real transit data integration.

I understand that transit riders love the idea of having a single app for transit information in every city they visit. I'm a transit rider; I get it. But the solution isn't to get every agency to pay the same vendor to provide the same proprietary service.

There are many AVL vendors out there; INIT, Xerox, Avail, Clever, Connexionz, and more. Some very forward-thinking agencies, like New York's MTA, have even decided to act as their own system integrator, and build their own real-time passenger information system, so that they'll never be beholden to any vendor's proprietary system. Built on top of the open-source transit data platform OneBusAway, MTA Bus Time provides real-time passenger information for New York's buses using an open technology stack that saved the MTA 70 percent compared to proprietary alternatives.

So with every agency using a different vendor's system (and some having rolled their own), how do we provide that integrated experience that riders crave? The answer is simple: by using open data standards. With standards like GTFS-realtime and SIRI, app developers can build apps that work with data from any transit agency and any vendor's systems. With OneBusAway, for example, I can easily (trivially) make use of feeds from any of several DC-area agencies, York Region Transit, MBTA, BART, TriMet, or any of the other agencies who are releasing GTFS-realtime data. Because these agencies are all using standardized formats for their open data, I don't have to build anything new in OneBusAway to consume their data—the same code that works for one agency works for all of them.

But NextBus doesn't provide an API using any recognized standards for real-time transit data. It's a walled garden of sorts; the NextBus API is great if all you want to do is present data from agencies using NextBus, and terrible if you want to use it as a springboard for building revolutionary real-time passenger information tools.

The real question isn't "why aren't you on NextBus"; the real question is "why doesn't NextBus provide a standards-compliant API"?