Max Gano, a Solution Architect with Sound Transit Research and Technology, describes his work in transit technology with the following catchphrase: "open data + open source + open architecture".
WMATA's ambitious new strategic plan, Momentum, includes a number of technology-related goals. How can the principles of open data, open source, and open architecture help us build Momentum?
As part of Momentum's goal to "[m]eet or exceed customer expectations by consistently Delivering Quality Service", WMATA seeks to "[m]ake it easy and intuitive to plan, pay, and ride", with specific 'strategic actions' including to "[p]rovide readily-understandable and useful real-time information in stations, stops, and on vehicles" and "[p]rovide transit riders with a regional trip planning system that works for all systems and provides real-time information in vehicles, in stations, at bus stops, and on any device".
These are high-level strategic goals, not detailed technical specifications, but the intent is still clear. Now, how do we achieve those goals? If past experience is any indication, they'll be achieved by handing the contract off to a big-name vendor who will extract a significant sum from WMATA to deliver one of the major off-the-shelf transit passenger information systems; the project will probably come in late and over-budget, and when it's done there probably still won't be a usable API for developers.
This isn't just an opportunity to take pot shots at government IT contractors; it's a scenario which has played itself out over and over again. One of the latest and most visible examples has been
healthcare.gov—and while many of the criticisms leveled at the site unfairly neglect to account for the complexity mandated by the Affordable Care Act itself, the reality is that what was built could have been built better, faster, and cheaper. Take The Health Sherpa, for example. Using the same data which powers
healthcare.gov, they've built a bare-bones plan finder which (gasp!) actually works! Now, Health Sherpa doesn't handle the enrollment side of the transaction, one of the largest pain points to date—but it still demonstrates that you can provide core functionality with a better, faster, cheaper alternative.
It's the same way with transit data. Using proven open-source packages like OneBusAway and OpenTripPlanner, we can advance WMATA's strategic goals, and we can advance them without the cost, delay, and dysfunction traditionally associated with government IT procurement. With open data, open source, and open architecture, we can deliver a cutting-edge product, while saving money and putting a better product in riders' hands faster.
But to do this, we need the region's transit authorities to fully embrace open data and open system architectures. Breaking free from the cost, inflexibility, and data silos traditionally associated with transit passenger information systems means fully considering open-source products alongside their proprietary counterparts, and demanding that agencies work with and alongside—not against—open-source developer communities, both locally and across cyberspace. Leveraging open standards like SIRI and GTFS-realtime, publishing high-quality open data, and collaborating with developers to enhance the quality and utility of data products all contribute to a better end product, and, ultimately, help advance the strategic goals which WMATA has outlined in Momentum.
With OneBusAway and OpenTripPlanner we already have the technology to deliver much of what WMATA seeks as part of Momentum. Are we completely there? No. Both of these projects are works in progress, with contributions coming in on a daily basis from a global community of software developers. But in terms of core features, OpenTripPlanner is already an outstanding package for trip planning (having proven itself in Portland), including real-time routing for transit and bike sharing systems, and OneBusAway provides a level of transit data integration yet unmatched in the region, as the Mobility Lab's pilot shows. As these packages mature (including via support from forward-thinking transit agencies) the advancements benefit transit riders around the world, in every city where they've been deployed.
By using open-source software, agencies are no longer tied to a single vendor for service, support, and new features. No longer are they tied to costly service contracts, exorbitantly-priced change orders, or business-driven mandates to upgrade to a vendor's latest-and-greatest (more expensive) product. Instead, agencies can hire their own staff developers, or contract with the vendor of their choice to build new features, maintain the system, and advance their strategic goals.
Similarly, because these tools are built around open infrastructure, there's nothing stopping an agency from swapping out components of these systems with other alternatives built around the same data standards. Silos are non-existent in an open-architecture world. There's no vendor lock-in, no fear of proprietary data formats, and no risk in experimenting with alternative tools.
Taking these tools from hundreds of thousands of lines of code on a server (or even just a conceptual plan) to a polished, production-ready service is a different kind of task than just writing a check to a vendor and walking away, but it's hardly an insurmountable challenge—New York's MTA has experienced extraordinary success in developing Bus Time on top of OneBusAway, saving money and delivering more features faster than proprietary alternatives. Along the way they've collaborated with the global developer community—this interactive list of routes was built not by the system integrator responsible for the Bus Time project, not by an MTA staff developer, but a member of the global developer community (yours truly, in fact).
Simply put, the model works, and the benefits are considerable. Can our region's transit agencies overcome their technophobia and intransigence in time to avoid a