Open data and geospatial IDs to deliver smarter bookings, richer maps, and seamless machine-to-machine travel coordination

Open Source Summit, Amsterdam – August 25, 2025

The OpenTravel Alliance (OTA), the leading data standards organization for the travel industry and a member of the Linux Foundation, today announced it has joined the Overture Maps Foundation (Overture), another Linux Foundation initiative focused on building reliable and interoperable open map data for global use. By joining Overture, OTA will work with another leading consortium to resolve one of the travel industry’s most persistent challenges: standardizing location data across the highly fragmented ecosystem of travel providers, platforms, and markets by establishing open, interoperable mapping frameworks.

Overture’s open dataset already includes more than 60 million places of interest, each with standardized names, categories, and addresses. Its technical foundation includes the newly released Global Entity Reference System (GERS), a reference framework that unifies how locations are identified and integrated. By utilizing GERS, each hotel, vacation rental, airport shuttle, or train station receives a unique, persistent identifier that works across all platforms and systems. By eliminating the need to manually reconcile data from different sources, GERS streamlines how location data enters travel systems, reduces integration times from weeks to minutes, and accelerates the delivery of new location-aware services.

“The travel industry has long struggled to unify data about where things are, especially across fast-changing and inconsistently named places like bus and train stations and local attractions,” said Stuart Waldron, director of the OpenTravel Alliance. “By integrating OpenTravel’s object models with Overture’s foundational open data and GERS framework, we aim to lay the groundwork for smarter, safer, and more connected global travel experiences.”

From Fragmented Data to Frictionless Travel

OTA’s contributions to Overture are intended to pave the way for members to freely build upon and enrich a single source of truth for places data. While Overture does not directly handle dynamic updates such as station hours or real-time transit availability, these types of rich data can be attached to GERS IDs, enabling them to be integrated into widely used systems. These systems ultimately reach billions of consumers through applications powered by Overture members such as Tripadvisor, Uber, Esri and founders AWS, Meta, Microsoft, and TomTom.

Use cases for shared data include:

• A connected travel ecosystem: GERS IDs support a seamless web of data, improving coordination across travel discovery, booking, and in-trip experiences. A hotel booking system can share precise location data with a ride-sharing app, local restaurant or tour operator using a common GERS ID.
• Richer map experiences: A stable, open base map allows developers to add travel specific data layers. With OTA, the travel sector aligns on schemas for real-time details like hotel availability, room rate, and pet-friendly policies, allowing attribute data and other amenity updates, all linked to a GERS ID.
• Future innovations: Forward-looking applications may include lightweight open standards anchored in GERS IDs that would make AI agents for businesses discoverable. A traveler’s AI assistant could then programmatically communicate with a hotel’s AI to ask questions or make a reservation, opening a new frontier for automated travel services.

“The travel industry is a prime example of a sector that relies on accurate, interoperable location data, but has been held back by a patchwork of inconsistent identifiers and siloed systems,” said Marc Prioleau, executive director of the Overture Maps Foundation. “By working with OpenTravel and its network of data providers, we’re applying Overture’s open, scalable map infrastructure to create a unified foundation to support smarter experiences, not only for travelers, but also for the AI agents and applications acting on their behalf.”

In the coming months, OTA and Overture plan to align OTA’s existing location schemas and definitions to GERS IDs to enable seamless adoption. Over time, OTA’s compiler may allow updates from members to flow directly into Overture’s datasets, ensuring that the travel industry’s most authoritative data remains current, accessible, and open, without requiring OTA members to rework their internal systems. The OpenTravel Alliance invites travel providers, booking platforms, and transit agencies to join this effort to build an open, shared map of the world’s travel infrastructure. To participate or learn more, visit opentravel.org or contact us

About the OpenTravel Alliance

OpenTravel Alliance is passionate about solving the challenges of connecting multiple systems within the complex travel distribution ecosystem. Our mission is to enable the future of travel by driving the evolving AI driven digital experience for consumers. OpenTravel Alliance creates, expands and drives adoption of open specifications — including XML and JSON — with partners such as LF OpenAPI which is incorporated into our tooling for the electronic exchange of business information across all sectors of the travel industry.

Our membership includes airlines, hotel companies, car rental firms, cruise lines, railways, tour operators, travel agencies, solutions providers and technology vendors. Billions of OpenTravel message structures are used daily, carrying billions of messages between trading partners.

Future innovations, partnering with Overture and other LF foundations, will be to deliver
universal open travel offers allowing all travel related products to be published for sale in a consistent secure digital means sellable by any retailer with an agreement with the product owner. A key enabler of AI agents in this space. Learn more about offers.

Founded in 1999 as a not-for-profit trade association, OTA became a member of The Linux Foundation in 2020 and continues to evolve while maintaining its essential role in standardizing travel industry messaging. For more information, visit www.opentravel.org

About The Linux Foundation

The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, ONAP, OpenChain, OpenSSF, OpenStack, PyTorch, RISC-V, SPDX, Zephyr, and more. The Linux Foundation is focused on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

For a list of trademarks of the Linux Foundation, please see its trademark usage page: www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

We’d like to hear from you

Curious to hear more? Visit our website where we will be posting more detail as it becomes available. You may also request to meet and discuss how the OpenTravel foundation will benefit your business on that same page.

When last did you speak to a fellow traveler who was delighted about how their trip arrangements went? Why should we put up with this?

Travel planning is time-consuming and irritating

After 45 years working with travel reservation systems—deeply involved in or familiar with most of the major solutions—I can confidently say: knowing why these systems behave the way they do doesn’t make booking travel any less frustrating.

Even the simplest trips are a headache. Booking air and hotel means juggling flight availability, cost, schedule, company policies, airport proximity, and ground transportation. Then there’s hotel cost, location relative to meetings, and more company rules. Add car rentals, rail options (especially in Europe and Asia), and cruise departures from ports like Miami, Canaveral, or NYC/NJ—and the complexity multiplies.
Frustrations amongst the ultimate customer in our industry are at a boiling point and the time for change has never been more relevant than right now.

Industry Proposed Solutions

So what’s the industry’s answer? Push travelers to supplier websites and apps. Sure, they offer personalization—but they don’t solve the real pain points. I still have to manually navigate all the intersecting variables, or pay someone to do it.

Some channels and distributors are trying to help, but they fall short. What travelers need is simple: “I want to attend a conference” or “I want to go to Disney World”—and the system should handle the rest. There’s buzz around AI agents and LLMs as the magic fix. But even the smartest AI needs clean, actionable data and a deep understanding of travel’s convoluted rules and workflows.

The real solution? Open source.

Other industries have figured this out. Auto manufacturers, for example, now collaborate on non-competitive features—like how cars integrate with smart devices, maps, and even an auto grade Linux. They realized solving the same problems in silos is wasteful and expensive. Travel needs the same approach. An open source effort would reduce complexity, cost, and lower the barriers for publishing travel products—big and small—for AI agents to discover and act on. Imagine tours, restaurant reservations, and niche experiences being just as accessible as flights and hotels.

Making the Change

You can support the changes needed by supporting the creation of the Open Travel Foundation as part of the Linux Foundation.

The time is now as the travel retail market is ripe for disruption and under LF, there is the necessary foundational technology to make it happen. Efforts like Overture Maps, OpenWallet, OpenSearch, DIF, OSSF, and more. . Opensource pulls together a community which act together to share costs and risk.

We’d like to hear from you

Curious to hear more? Visit our website where we will be posting more detail when it becomes available. You may also request to meet and discuss how the foundation will benefit your business on that same page.

The Open Travel Foundation

The travel retail industry is evolving to focus on delivering comprehensive experiences rather than just individual services. This shift necessitates enhanced interoperability among travel providers and retailers. Current protocols, rooted in standards from the 1960s, are outdated and insufficient for modern needs. The industry requires a new approach to handle travel offers as digital retail products, considering the unique characteristics of travel services, such as their transient nature and location specificity.

Addressing these challenges can unlock significant economic opportunities by automating travel arrangements and providing access to previously excluded suppliers. This proposal outlines the creation of an open-source foundation to revolutionize travel retail, fostering a community-driven approach to share costs and risks.

The travel retail market is ripe for disruption as many of the current constraints are rooted in legacy technology upon which business processes and revenue models were built. The latter making it extremely difficult for any one company or industry segment (air, car, hotel,,,) to unilaterally change. Opensource based approaches have had success in such scenarios as they pull together a community which act together to share costs and risk.

To meet the demands of travel retail today and in the future, the Open Travel Alliance is expanding its mission by becoming the Open Travel Foundation as part of the Linux Foundation.

Mission and Vision Statements

At the Open Travel Alliance, our core purpose drives every initiative we undertake. Our mission and vision statements articulate the essence of our commitment and the future we aspire to create. They serve as the foundation for our strategies and daily operations, guiding our efforts towards achieving meaningful impact

Mission Statement

Enhance the future of travel by enabling the transition of our travel industry members to digital retail supporting today’s app-based consumers demanding personalized solutions. Empowering members via message standards, reference architectures, and reference implementations to support their efforts to move to modern APIs and cloud-based solitons that in turn support digital retail at scale.

Vision Statement

The Open Travel Alliance is a cross-sector technology enabler for the travel community providing open-source support for ubiquitous offers capable of omnichannel personalization that will remove barriers to the publishing and consumption of travel products. Any product, offered and sold on any channel, while obeying the supplier’s price and rules.

We’d like to hear from you

Curious to hear more? Visit our website where we will be posting more detail when it becomes available. You may also request to meet and discuss how the foundation will benefit your business on that same page.

In summary, the Open Travel Alliance would provide a standard on data structure, message schema, and offer/order minimum behaviors. Offers and orders would be containers that can accommodate any product, price, and rules such that the offer is actionable “as is”. That is, convertible into an order. This moves a majority of processing away from the data centre to the edge of the network (cloud based). Backends handle orders much as they do today. The actual shop functions would be competitive, using this universal offer capability, where the better ones win the marketplace. Details on how this works is in previous and soon, subsequent posts.

How this may affect the travel retail industry can be explained using an example of a prior disruptive change in technology. Prior to MP3 and MP4 standards, the music and video industry was very constrained. Products were brought to market in a limited number of ways that were tightly tied to consumption technology. In the “Boombox” era, you had vinyl, various forms of tape (reel, cassette, 8 track), CDs, DVDs, video disks, and a few others. This allowed companies to constrain distribution given the limited number of channels for distribution and make high profits. Nearly impossible for any creator to distribute on their own. Consumption was a little better as there was some competition between suppliers of  devices capable playing the limited formats.

The advent of MP3 and MP4 standards blew the revenue model to pieces. Now anyone could publish and given no physical assets were needed (digital distribution), this was easy and cheap. Consumption was also unlocked as nearly any device could consume the product. Companies like Circuit City failed as the majority of their revenue was based on CD and DVD sales. Once those products were gone, they could not survive on sales of electronics alone. Record companies and others had to reinvent themselves as they could no longer control creator access to distribution.

Travel is still in the Boombox era. Most obvious is airline tickets which are still severely constrained on who can sell and process a ticket. Hint, they are value bearing documents even in eTicket form.

Not just anyone is allowed to print money. As many trips include an air segment, this is limiting who can be a travel retailer. Beyond legacy air there are constraints affecting everyone.

Everyone presents their product or service via proprietary messages and APIs. This is our above example of a half dozen distribution forms on steroids. There is some consolidation as distributors may pull in products from a dozen or more formats and pass them along with their own proprietary format. The main effect however is increased cost. Any company providing travel retail to the consumer has to deal with 1000s of proprietary formats. Even worse, pricing is hopelessly complicated with hundreds to thousands of possibilities, no MSRP, and no easily accessible rules on those prices.

The constraint on the industry here is very few distribution or retailing companies have the knowledge, talent, and funding to do travel retail at scale.  Any startup originator of a travel product may create a set of APIs or pay someone else to use theirs, but no distributor or retailer is likely to pick up your product. Too costly to connect to your proprietary APIs given a very low profit opportunity. You may have just built your 100 bed hotel but that’s not near large enough for any major channel to connect to you. The ones who do connect will charge large fees to recover the cost.

The net for the traveler is you are constrained to a small number of retail outlets (online or apps) and what they can sell is a fraction of what is out there to be purchased.

As a travel product/service provider, this is a hard business to break into.  Crazy high fees by those that will connect to you, and you are not likely to get to the higher value customers. To be a startup with a great idea for a killer travel app, you can’t get to much content without paying large fees to an established distributor.

Like MP3/MP4 for music and video, a universal offer with a standard data structure, message schema, and offer/order behaviours, removes these barriers. Anyone can publish their travel product/service cheaply and any channel/app can pick it up cheaply. This won’t fix airline tickets, that would be another long blog how to fix that, but this addresses the rest. It’s time to move beyond 80s and 90s travel retail distribution and revenue models. Time to ditch them with the Boombox.

The OpenTravel website has been extremely busy. During this “down” period thousands of message/model downloads supporting hundreds of projects at hundreds of companies across 18 countries. This has provided high value to the travel industry.

However, this cannot continue at current funding levels, nor can new efforts be initiated to address the needs of the industry to move to JSON/REST and offer/order paradigms. In response to this need a group of travel industry leaders met on September 12th, 2024, to reboot OpenTravel.

The reboot will evaluate the needs of the travel industry to support digital retail via a more consistent approach to APIs. Companies using OpenTravel messages as a starting point for their JSON based API enhancements still leaves too many needless differences in API structure and behavior. We need more consistency between travel suppliers and consumers to work effectively with each other. The scope includes defining the capabilities and behaviors of offer and order approaches using well known, successful, open-source patterns. Once an approach to bring consistency to APIs and hence lower costs is defined, membership and funding models will be proposed. This may include becoming part of a larger existing open-source community. This would define globally how offer and order works for all travel retail with multiple open source offerings to help solution providers to speed up their own product plans.

Stay turned and check the opentravel.org website periodically to track progress or to sign up and be an active participant in defining the future of travel retail.

Some background in travel: Back in the 70s when I started in travel retail programming I had already been working for an airline for a few years. Most of the people I was working with also started outside the IT department. Some were gate agents or worked on the ramp, in hospitality many worked at properties. This was due to the fact there were not a lot of IT people out there to hire. Travel companies did a lot of hiring from within and had education departments to provide the IT skills. The result was 10 years down the road there were a lot of very experienced developers that also knew the business of the airline, hotel, car rental, rail and other companies pretty well. A fair amount of the product people were the same. Someone who started as a res centre agent was now defining the reservation capabilities needed to meet changing business demand.

Having this kind of shared experience between product teams and developers meant that product definition documents didn’t need to be too detailed. In fact most were fairly vague. But it worked as a product person could tell me what they wanted to see on the availability screen and I knew what they meant. I knew how everything on that screen already got there and so I knew what I had to do to add new data requests.

However, this happy arrangement didn’t last for long. As companies grew and now there were graduates to hire with IT skills from colleges, it began to fall apart. More so than the product teams, increasingly  the developers didn’t understand the business. Vague product definition documents (use cases) were still the norm but developers had no idea what they meant. Years later, as development starting moving to outsourcing and offshore, this disconnect got much worse.

The result was a lot of design and redesign as acceptance testing was rejected by product teams as not what they asked for. Animosity between product and development grew and still seems fairly bad today in most companies. In developer speak we call this a context switch problem. Product owners and developers don’t speak the same language.

Product teams feel they are describing what they want clearly and developers find that does not actually tell them what they need to do. Developers, as they now do not know the business, don’t have the context to understand where the data needs to come from, what the relationships between data elements are, and many often unwritten use cases and roles that have to be followed (like when a plane crash happens, what data gets locked down). At many travel providers this ongoing issue has caused efforts to revamp the development life cycle and among several goals, attack the context switch issue.  Most would have heard of moving to agile or even scaled agile (SAFe) which include efforts to shift left and use various means to touch base with product teams early and often. The goal being to find any disconnects with product earlier when they are easier and cheaper to fix.

These approaches found their way to API development with patterns like API first. Create a mock (wireframe) of what you think product wants via a set of lightweight APIs, probably with static data, to show the product team. Then iterate and build out from there.  However this still is a pattern of repeatedly showing product teams some mock ups until they agree. It’s a workaround of the context switch issue, instead of asking are there ways for product teams to describe what they want that is easier for developers to work with.

There are practices and products for use case development that achieve this but it does mean a learning curve for many product teams. I know this as I led architecture teams as part of a move to SAFe and still struggled to get product teams change how they did use cases. There is another approach under development. As I mentioned in my last post, there is a new specification from OpenAPI called Arazzo. The spec defines how to describe how a series of APIs work together including the data. This will facilitate (AI based) tools that automate the workflow including code generation. What OpenTravel provides already are object (data) models that define the data with context (semantics) that is used to create the API description documents. For a single API, it’s a next step to add Arazzo.

Description documents are another, possibly large, step to the left for APIs. It’s easy to envision AI based tools that, with access to the object (data) models from OpenTravel, can know what data is available and what the semantics are. Tools that can work with a more conversational approach for product teams but producing the API description documents. I want to emphasise that point, product owners describe what they want largely as they do today. Those description document are in turn used for further automation to generate APIs and code for some mock tests.

Envision a process where product teams, with a little developer help, can iterate quickly by gradually updating their descriptions and immediately seeing what the result is. What’s being built now is the specification foundations for this between OpenAPI and OpenTravel. Tool providers are involved in the specification work while investing and updating their products to get to market as quick as they can.

Maybe we can get back to the 70s when product people and developers got along. Peace and love!

OpenAPI already produces a specification which allows the API developer to describe the structure and attributes of the API. This is predominantly used by tool vendors to automate the process to publish an API for use. What has been added is a spec of similar design that allows for the description of the relationship of one API to the next. This spec describes the sequence of APIs and the passed data elements in a way that tool providers can start automating the workflow itself. Early use may be to allow an API consumer to easily see how a sequence of APIs work together in what is called a mock test. Down the road the automation will extend to the runtime itself by generating code that will handle the various use cases. Given the proliferation of similar but different APIs in travel, this approach can have a dramatic impact by lowering the (labor) cost to bring new travel content on board via APIs. Reducing the current very long lag time to onboard new content by a retailer. At OpenAPI, I run a travel special interest group working on prototyping common travel API workflows using the new spec. As we get those reference implementations done, they will be published on the OpenTravel website. I presented this and other OpenAPI activity on April 15^th at the Linux Foundation Open Source Summit in Seattle. You can access the pdf at:
https://static.sched.com/hosted_files/ossna2024/a6/OpenAPI%20MiniSummit%20April%202024.pdf

The spec itself can be viewed thru the OpenAPI website.

In retail , I can’t find any product provider that builds their own trucks. There are those like Amazon and Walmart that brand their own trucks, but they don’t make them. Yet in travel retail it’s very common for product providers to build their own APIs to transport their goods. There are some analogies to my example with Amazon and Walmart for product providers that are hosted on a service provider’s CRS/PMS, but the service provider is building their own trucks (APIs).

The distributor of the product in my grocery store example builds one type, one instance of a loading dock that can handle any truck. This is because trucks are fairly consistent in their shape, size and attributes. If a truck manufacturer made a truck taller, longer, wider than others they would not sell many trucks. They would be useless to perform their function to deliver goods to most business who are not going to build a loading dock for this unique truck. This is true of any mode of physical transport one can think of. If the truck, plane, rail, bus, ship, etc. cannot be accommodated easily by the receiver, it’s useless. But that’s exactly what we do in travel retail with APIs. Everyone creates unique APIs to transport their products, travel commodities like seats, rooms, cars, berths, etc. expecting the receiver to make accommodations for each supplier. Most would agree that the competitive value or differentiation of the travel product would be in the service it provides and at what price, not by what the digital truck that delivered it looked like. Yet over the decades I lost count of how many product teams I have worked with that did, and still think, proprietary APIs are a good thing.

A travel distributor, such as a GDS, aggregator, TMC, channels or others, has to deal with 1000s of bespoke APIs. In effect making and maintaining instances of bespoke loading docks. Some instances have minor differences, some major. Either way, any time there is a change required to the software, a major testing effort is required to validate all the bespoke instances.

All this comes at a high cost which needs to be passed on to someone. It may be in higher booking fees, transaction fees, or other types of service fees. It also adds to throttling of shop/availability messages where over a certain look to book rate it’s not worth it to a GDS or other distributors to deal with you. Same is true for taking on content from smaller providers like boutique hotels or tour operators. API support and processing costs are too high to turn a profit without charging unacceptably large booking fees.

 It does not have to be this way. Today there is not a full standard for travel APIs that would guide not only what the message looks like but how the API behaves. Attributes that in our truck vs loading dock use case would have the same effect. That is, attributes that would allow API consumers to have one loading dock that can handle the delivery of any travel product.

 Consistency in how travel retail APIs work would not only save distributors and channels loads of money, it would also greatly reduce cost for travel providers (providers of the APIs).

 This is not a failing of the existing standards bodies. OpenTravel, OpenAPI and others are ready to work together to solve this. It’s the prevailing narrative in the travel industry that proprietary APIs are somehow a competitive advantage and a means to retain market share as it is hard to change providers. It’s narratives that everyone should follow the air standard (including non-air), while rail, hospitality, restaurants, tours and others also think they, not air, have the best standard. For others, they are building their own silos and don’t care what anyone else does.

It is also the lack of understanding that while you may in fact deploy some great APIs, it’s still going to mean high labor costs to someone else just because you are different.

In closing, you may make a really cool digital truck to deliver your product. But if everyone one who wants to work with you has to build a custom loading dock, your cool digital truck is a barrier to commerce, not an advantage.

Standards bodies have traditionally been supported by the major players in industry verticals. Such as airlines for IATA, Hotels for HTNG, rail for the UIC. Major online channels have not participated all that much. In fact, very few consumers of the message and API standards participate in the creation and maintenance of standards. This is odd as there is far more labor spend on API consumption than API production. Much of the potential improvements to the standards along with reference implementations would be to the direct benefit of distributors and channels as they could greatly lower the cost to acquire actionable content. The use of XML and JSON message standards from OpenTravel is overwhelmingly by consumers of travel APIs. In the past 24 months there have been downloads by over 1000 individual users. This calculated by eliminating duplicate and missing email addresses. These by individuals working for hundreds of companies across 18 countries. However, there is no support for what is a community, nonprofit, effort by the consumers of APIs.

OpenTravel is rolling out a donation capability in the model of Wikipedia to provide an opportunity for those that are benefiting from the standards to contribute back to community. Working with partners like TTI to get the word out that standards and much needed reference implementations don’t happen on their own. Donations will be used to fund support for workgroups and the creation of JSON based object models by experienced modelers. This in turn supports the move of the industry to REST based APIs and away from bloated and stateful XML/SOAP messages. Doing this as a community would speed this transition and lower the cost of travel retail for all. Lower costs for content acquisition means more content in the retail channels. More commonality in API functions like identity management and how offers are constructed means enablement of cross channel personalization. No one player in the travel market can do this. It needs to be a community effort that is fairly funded by the community.

Said a little more plainly, game theory studies interactive decision-making, where the outcome for each participant or “player” depends on the actions of all. The interesting cases are when a group of people must decide to cooperate with each other or not given the possible outcomes. A commonly used example is multiple people are arrested for a crime. If no one talks, they may all get a light sentence as the authorities don’t really know who did what (lack of hard evidence). However each individual may decide to inform on everyone else. They would get no sentence and the rest get a harsh one. If everyone informs on everyone else, they all get a harsh sentence. Game theory is predicting who will do what and why.

How does this relate to travel retail? Currently travel providers and channels are creating bespoke APIs for retail that do pretty much the same as everyone else (shop, book, pay, ticket/entitlement). They could choose to cooperate on the non-competitive, technical, aspects of API development and delivery, such as taxonomy, syntax, message structure, callback functions, query methods, etc..

They could choose to use organisations like OpenTravel and TTI to create common use reference implementations to be shared by all. This would greatly lower the API production and consumption costs for all. This would not affect product, price or rules which can be unique per implementation but following a common architecture, it could actually enhance ones ability to compete as the money saved on redundant low level API work could be used for product and personalisation improvements.

However the industry does not cooperate where it makes sense. There remains a long standing notion that it is somehow an advantage to have APIs that are different from everyone else. Harder to adopt, hence harder to change partners, aka vendor lock in. That somehow their own staff, on their own, can create better APIs than anyone else and that will make a difference. That somehow offloading everything to a service provider will make them more competitive. That service provider would use their own bespoke APIs (lock in) across multiple travel companies but also the same product, price and rule capabilities. That latter being a concern for a travel provider as they may be limited on how they can differentiate their product.

Currently in travel retail, no one cooperates with anyone else. They all see the worse outcome, they all get a harsh sentence meaning high IT costs. Loads of redundant effort and APIs that make selling across channels or partnering to promote each other’s product extremely painful. If there was ever a time to take two steps back and use game theory to examine how cooperation may benefit all, it is now.

The industry is moving towards shared nothing architecture in order to leverage cloud computing (beyond simple hosting) and what truly distributed personalized retail could look like. Doing that in a bespoke way company by company won’t work. Reach out to OpenTravel at https://opentravel.org/contact-us/ if you want to dig deeper into how cooperation would work.