TravelSpirit sees transport as a human right and freedom, and does not want to see cities of the future being run solely for the benefit of commercial interests.
We believe it is important to defend transport from monopolistic processes which threaten to take the whole of the mobility market within the private confines of organisations that do not have a public remit or control.
The Open Internet of Mobility is a global digital commons that enables the full benefits of Mobility as a Service (MaaS) and Connected & Autonomous Vehicles (CAV) – new transport modes, software and information streams – to be locked-in for the public good.
Built on open architecture, standards and protocols, this framework will enable MaaS and CAV providers to compete in a transparent market that is truly focused on providing individualised customer-centric services to anyone and everyone.
Open development occurs when all decisions are publicly documented, all resources are open source and all bona fides participants have equal rights.
Development in the open is inclusive and empowering. Experience shows that the collective memory of a community – both short-term and long-term – must be available to all if development is to be accessible to all who wish to participate. It’s thus essential to apply consensus rules such as those used by the Apache Software Foundation, where all code commits are documented, small enough to be reviewable, logged to a mailing list and subject to challenge.
Apache asserts that “if it didn’t happen on the mailing list, it didn’t happen,” a rule to ensure that all in-person interactions are fully documented for all participants. Even when a project comprises a few co-located people, it is vital to follow this rule otherwise new participants will have lesser rights in practice whatever their rights in principle.
Open collaborative tools, open licensing, self-governance, non-discriminatory respect, release-train schedules and shared assets are the keys to open development.
Open development is now a well-understood practice among open source communities. We expect TravelSpirit to operate using the following default practices:
Open collaborative tools:We will use open source tools to support community interaction and software development, rather than proprietary tools. We will also seek to ensure that it is possible to migrate between hosting arrangements and also to migrate to alternative solutions.
- Open licensing:All code we work with will be licensed under an OSI-approved copyright license compatible with the Mozilla Public License version 2. All non-code assets will be licensed under the equivalent Creative Commons license, CC-BY-SA-4.0-Intl.
- Self-governance:Decisions will be made by current, actual contributors, possibly with reference to a larger body of former contributors where decisions are not readily reversible by future participants.
- Non-discriminatory respect:We will require all participants to abide by policies requiring respectful interaction that is not affected by externalities of the individuals or companies involved.
- Release-train scheduling:We will release software according to a pre-determined schedule (a “release train”) to ensure that all participants have their improvements included in a timely manner, that security fixes are circulated promptly and that no party is able to prevent releases based on their own preferences alone.
- Shared assets:We will cause all common assets – funds, trademarks, collective copyrights, employees, events – to be in the stewardship of an independent entity beyond the control of any one participant.
- Open Trust:Collaborative projects will have shared assets that need managing. An independent legal entity is the best vehicle for this, and we believe a fiduciary and administrative umbrella is a wise first home.
Collaborative projects will have shared assets that need managing
Once a collaborative project is in progress, the collaboration will naturally start to require the management of shared assets on behalf of the community of collaborators. This will include technical assets such as a source code repository, mailing list service, wiki, translation memories, build services, test systems and so on. While these can in many cases be hosted on shared services such as GitHub, it’s important to ensure that no member of the community has exclusive control. Even the most trusted individual can leave a project, and a lack of clarity about who legally “owns” those servers can lead to painful disputes.
Even more important is the stewardship of legally-recognised assets such as domain name registrations, trademarks, shared cash from donations and other sources, hardware bought for general use and so on. It’s very important these assets are legally controlled by the project rather than by a subset of individuals.
In time a project may have more significant assets, including public events, staff and even premises. By the time these are acquired, a community must definitely be anchored in a legally-recognised entity.
Open source is enabled by granting permission in advance through a standardised copyright license.
The term “open source” was coined at the end of the 1990s to embody the application of the older concept of “free software” (software with its user freedoms intact) when applied to communities of developers that potentially included commercial users.
The Open Source Initiative (OSI) was formed in 1998 to advance the term, and since then has acted as a standards body for copyright licenses. In the last 20 years, OSI has approved many copyright licenses as open source, providing a richly varied scope for open source development. All these licenses allow use of the code without any preconditions whatever, and grant permission in advance to improve the code and to share the original or improved code with anyone.
Some licenses place preconditions on the sharing of the code, most frequently by requiring that anyone doing so reciprocate on the liberty they enjoy by making the same liberty available to recipients of the code. In a play on the word “copyright”, licenses requiring reciprocal license terms are called “copyleft”.
The scope of the required reciprocity varies. Some licenses require projects incorporating their code to share the full source that corresponds with the program being given to users. These project-reciprocal licenses are sometimes termed “strong copyleft” with the best-known being the GNU General Public License (GPL). Other licenses limit the scope of the required reciprocity, for example by only requiring the reciprocal sharing of the source of modified files (the Mozilla Public License, MPL, does this) or only requiring reciprocal licensing if the source code is shared (the Eclipse License does this).
Scope-limited reciprocity makes it easier for existing companies to execute their business models outside the project, so we believe use of a scope-limited open source license will lead to more rapid growth of the Open Internet of Mobility and the markets associated with it.
Since existing code that is likely to be used by the Open Internet of Mobility is licensed under both the non-reciprocal Apache License and under the project-reciprocal GPL, we need to select a license explicitly compatible with both. We will therefore advocate use of the Mozilla Public License version 2 for all new code contributions.
An open source model leverages copyright to create innovation, collaboration and market growth
All code is automatically protected by copyright the instant it is created, and without a license from the copyright owner almost all legal reproduction of the code would be impossible. In proprietary contexts, copyright licenses are granted in exchange for payment, as a convenient control point allowing a vendor to recover the costs of development and profit from code.
But this is not the only way to leverage copyright. Open source projects license the copyright under an OSI-approved license in a way that creates permission in advance for improvement and use, and as a result encourage commercial use of the code outside the scope of the project. Companies working with open source code have commercial models that do not rely on the artificial scarcity of the code that results from a proprietary license. Instead, they use the code to enable generation of revenue by other means.
A well-constructed open source project consequently allows many enterprises to benefit from code, rather than just one. New entrants to the market will still need new business models and new investment, but do not need to re-implement basic and well-understood code which is non-differentiating.
Since it is non-differentiating, it’s unlikely such improvements will lead to significant business advantage but rather to the maintenance burden of maintaining an independent “fork” of the code. As a result, businesses sharing open source code are incented to contribute their improvements to the code back to the community, with the consequence that the shared code is constantly being improved by every business adopting it.
This continuous improvement leads to shared innovation, to collaboration and to the growth of the market generated by the code. These benefits are likely to greatly exceed the benefits that would have accrued to a single entity seeking to directly monetise the copyright.
Existing projects should be used and improved where possible, reserving new development to gaps
The Open Source movement, together with the Free Software movement before it, have caused millions of lines of code to be liberated under open source licenses. As a consequence, the basics of any software system are highly likely to already be available in a collaborative project somewhere. It is better to default to using existing projects, improving them where necessary and contributing the improvements upstream.
Open source and open data are necessary but not sufficient.
A collaborative development will need source code licensed so as to give every participant permission in advance to use the code to satisfy their extrinsic motivations. The code will almost certainly consume external data that will need to be licensed in such a way as to permit such consumption, and will need to expose APIs and emit data licensed in ways to allow downstream consumption.
These are “hygiene factors”, necessary for open collaboration but sufficient neither to cause nor to guarantee it.
For the Open Internet of Mobility we will need to go beyond open source licensing to also stimulate and protect open development and representative governance.