Pioneering City-led, Public-Private Partnerships to Build a Mobility Data Standard
In 2019, municipalities across the United States joined together to create a new global non-profit organization governed by cities called the Open Mobility Foundation. The goal? To bring together public and private sector stakeholders to support the development of open-source software that provides scalable mobility solutions for cities – namely, the Mobility Data Specification, or MDS for short.
Originally developed by the Los Angeles Department of Transportation (LADOT), MDS is the open-source data specification developed in partnership with stakeholders in both the public and private sectors. It is used by more than 120 cities around the world to plan transportation infrastructure, support and regulate shared mobility services, and advance the goal of a safe, equitable, sustainable transportation system.
At its core, MDS is a set of APIs (Application Programming Interfaces) that create standardized two-way communications for cities and private companies to share information about their operations, and that allow cities to collect data that can inform infrastructure planning, regulations, and other public policy decisions. MDS was originally developed to help cities manage dockless micro-mobility programs (including shared dockless e-scooters), but is also used in car and bikeshare programs, delivery robots, and other emerging modes. The OMF is even starting to tackle issues around curb management using this approach.
As we look to the future, there are many lessons learned; lessons around how we co-create in a unique, city-led public-private partnership model, lessons about the value of open source software and standards when it comes to managing mobility. After two years of pioneering work, here is what we have to share.
THE BENEFITS OF AN OPEN APPROACH
An open source approach to data specifications benefits cities and companies by incorporating input from both the public and private sectors, reducing costs, and nurturing a healthy, competitive ecosystem for mobility services and software tools.
The OMF provides a structured, collaborative space for development. This results in a better specification, one that’s been “stress tested” in advance by the people who will use it. The open-standard specification model reduces costs by eliminating intellectual property license fees, reducing the amount of bespoke software development and manual data management that would otherwise be needed to satisfy unique requirements for mobility providers to operate in multiple jurisdictions. These benefits of open source flow to the communities served by local governments as well. By reducing the cost and complexity of implementing data-driven policies, governments become more agile, and competition for mobility services is increased.
HOW WE CO-CREATE
While MDS and the open specification model offer many benefits to cities, mobility operators, and software companies, each part of the MDS ecosystem has its own needs and priorities, which sometimes come into conflict. Cities want to hold operators accountable to local policies, some of which limit the scope and scale of their operations. Mobility operators want to sustain good relationships with regulators and work toward shared goals like safety and greenhouse gas reduction, but need to run profitable businesses and reach the most desirable customers. Software companies want to sell their services to cities and retain them as customers.
As the organization that governs the development of MDS, the Open Mobility Foundation has to make sure that our process supports the needs and interests of all stakeholders, and avoids “capture” of the specification by any particular interest. A particular concern of cities is that MDS could be altered in a way that would curtail their regulatory flexibility or limit their ability to competitively procure software tools. These risks are addressed through a governance model that prioritizes transparency, consensus-decision making, and a formal approval process before changes are implemented.
Transparency: All development is done via GitHub and working groups that are open to the public. Because proposed code changes are published and reviewed, it affords opportunities to investigate the utility and potential drawbacks of any change early in the development cycle.
Consensus: Decisions to move forward with a change to the specification are made first in the working groups, where consensus is prioritized. Features that do not have broad consensus are typically held back and reworked. While there is a mechanism in our structure to make decisions when consensus cannot be reached, to date it has never been activated in the development process.
Formal approval: Once a working group produces a release and agrees that it should move forward, changes go through a three step approval process. The Working Group Steering Committee, made up of OMF members from the public and private sector, reviews the details of the changes and approves a release candidate. The Technology Council, made up of mostly private sector members, evaluates whether the release fits into the larger vision for the OMF’s technology framework and addresses business needs. Finally, the Board of Directors reviews the release to ensure that it is aligned with city needs and policy prerogatives.
This process is more time-consuming than a typical development cycle, but helps ensure a balanced outcome to the conflicting needs and priorities of the various stakeholders.
LESSONS FROM AN EMERGING FIELD
Like any startup, the OMF has had to learn and adapt. Three of our key lessons to-date:
Getting policymakers and technologists to speak the same language is hard. The output of OMF is very technical and the process by which we produce that output involves a lot of concepts and skills that are not common amongst transportation policymakers. The converse is true as technologists frequently lack the context and experience to understand policy goals and challenges, and consequently struggle to produce technology to address them. An ongoing challenge for the OMF is to create spaces where these two groups of stakeholders can find enough common ground and shared vocabulary to contribute their unique skills and perspective, and to develop enough understanding of each other to effectively collaborate. What folks don’t lack is a willingness to try to understand and work with each other, which serves as a strong foundation for addressing this challenge.
Ecosystem value is hard to capture as an open source non-profit. The existence of the OMF and MDS provides tremendous benefits in direct cost savings and reduced friction between stakeholders. OMF sustains itself with membership dues paid by companies, but companies do not have to be members of the OMF to use MDS or contribute to its development. To be financially sustainable, the OMF must balance delivering unique value to members while also maintaining the free, open-source model that MDS was built on. We are continuing to experiment with financial models that capture value across the ecosystem and allow us to sustain our unique organizational structure.
Common standards are hard when everyone moves at different speeds. MDS has evolved a lot since its first release in 2018. But while some MDS users upgrade to new versions of the specification regularly and are eager to take advantage of new features, others are slower to adopt new versions, have limited capacity to implement changes, and may be content with capabilities from several years ago. This poses a challenge to the ecosystem. When multiple versions of a standard flourish, the benefits of standardization are reduced as companies and cities have to invest in additional technology to simultaneously support this diversity. The OMF is learning how it can best support both early and late adopters, and what approaches are effective in encouraging a coherent ecosystem even as MDS grows and evolves.
As the Open Mobility Foundation finishes its second year, we are continuing to build on the success of our initial vision while evolving our organization and business model to reflect the things we’ve learned so far on our journey.
If you liked this post, check out our Architectural Landscape series:
While the work that we do is often technical, it’s Read more
Whether they’re handling an emergency or just a planned road Read more