MDS Architectural Landscape Series

STRIKING A BALANCE

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.

HOW WE CO-CREATE

The following principles are core to our collaborative process:

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.

Map of the Open Mobility Foundation’s governance structure

PRINCIPLES IN ACTION

Ultimately, the best way to understand how we co-create is to follow a real example.

For instance, let’s take a new beta feature that is part of the latest release of MDS: Provider Reports. Mobility providers run special pricing programs for low income groups, often as part of permit requirements to make services more accessible. Typically, communicating the utilization of these programs is done manually with operators providing ad hoc monthly reports to cities. Recognizing an opportunity to make the process around this existing reporting requirement more efficient and consistent for providers, Spin proposed a solution. By creating an issue in Github and bringing it to the appropriate working group, any contributor can participate in the development of MDS.

After the issue was opened, discussion around the feature – a new endpoint within the Provider API – moved forward both on Github and in working group meetings, each open to public participation. Features are vetted based on a variety of factors, privacy concerns are addressed, and a broad understanding of the topic and consensus must be reached to move forward. In the case of Provider Reports, it was important to establish that the reports returned through this feature would contain aggregated monthly trip counts of special groups, and that these reports are currently required across a variety of cities, demonstrating a clear and broadly-applicable use case while addressing privacy considerations.

This particular feature was included in the 1.1.0 release, which went through an initial vote by the Provider Services Working Group Steering Committee, then on to the OMF’s Technology Council for consideration and further discussion, and finally was approved by the Board of Directors on March 30, 2021. 

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, and it lets MDS evolve to incorporate the best ideas from all parts of our community.

Learn more about how to participate in the OMF’s collaborative process.

—

The Open Mobility Foundation (OMF) community – our Board, staff, and members – set out on an ambitious mission this year: to define the growth trajectory for the Mobility Data Specification (MDS), outlining a product strategy and roadmap while defining the development process into the future.

The result was a comprehensive document we call the MDS Architectural Landscape. This post is the final in a three-part series about the architectural landscape where we explore what it means to co-create in an open source environment. Other posts in the series explore the vision for MDS and why open source projects are good for public and private sector organizations.