Delivery of Mobility as a Service (MaaS) cannot be the task of a single or a private enterprise.
This is not a neglected problem space. But the solutions so far exhibit two flaws:
First, the best-known new mobility solutions are single-mode, proprietary solutions (think Uber, Lyft and so on) which seek to compete with rather than to complement existing modes.
Second, there are many solutions which leverage open data to offer trip planning that leaves booking and travelling to the individual. Even in the most successful cases, the individual must take sole responsibility for the success of mobility once they have booked or enquired.
We posit that true MaaS solutions cannot be created as an act of fiat. They require many parties to at least be complicit and preferably to be orchestrated. In turn, that requires either a highly trusted and well-established private party, or a trusted public collaboration. We aim to create the latter.
Shared code both accelerates implementation and improves interoperability.
Open data is clearly desirable, even if the precise meaning of the term is elusive. Open APIs offer even more opportunity for collaboration. But both tend to create divergent independent implementations. By contrast, open platforms lead to better interoperability, and shared code to provide access to open data and open APIs leads to faster implementation of more robustly interoperable applications. While overlooked by proponents of open data, many solutions use open source code. We propose actively sharing the source code as well as the data.
Through shared code collaboration, the parties to MaaS solutions within TravelSpirit can co-operate by crafting code to express their collaboration, with the detail of their business relationship arising from the code and ultimately being made concrete at deployment time through shared agreements. We anticipate that profitable operational agreements will arise from code collaborations, rather than the reverse.
In a shared, multi-party collaboration, each party must independently take responsibility for their participation motivations which must remain extrinsic to the collaboration.
An open source solution can be operated by a company with an interest in the code. That has advantages, especially when the connected company provides infrastructure, build and release services. But the additional control such a company needs in order to generate revenue can inhibit both community diversity and growth.
It is better for companies to exist independently of the code, with their locus of motivation in their own business model rather than in the community in which they collaborate. Many effective open source communities operate in this way, with one of the oldest being the Apache Software Foundation and one of the newest The Document Foundation. These communities sustain multiple businesses, each with their own business model, without needing to preferentially advantage any single business.
By protecting community members from each other’s business models, each is able to contribute freely and the opportunity for all is accelerated. This is achieved by two means: