Over the past decade, I have served in various roles to deliver software for public agencies under government-funded contracts at MIT, UC Berkeley, and at transportation technology companies (the majority of that time as an academic). As transportation continues to rapidly change, and cities become increasingly reliant on software and data solutions that are hard to keep up with, I have been surprised by some common technical misconceptions that result in costly systems that are unable to adapt over time.
Several years ago, I noticed that many in the transportation space often used the terms “open standards” and “open source software” interchangeably, when they are actually quite different concepts.
Technology future smart city and wireless communication network connection concept
Getty
Open standards that are developed with a clear and transparent process are essential for ensuring flexibility and adaptability, and are almost always undeniably “good”. Whereas open source software, especially in the context of the public sector, has various pros, cons, and sometimes unexpected challenges.
Open Standards
Open standards are often developed for data or hardware that are made available to the general public and are designed and maintained through a collaborative and consensus driven process. They are critical for allowing for different systems to communicate and share information seamlessly.
In open standards making processes, members (which in some cases may include open participation without membership criteria or costs) work collaboratively together to develop standards. These standards are designed and tested in the open with members; they are not developed and tested by one or a limited set of actors in a black box and then pushed out as a standard.
The most popular example of an open standard in transportation is the General Transit Feed Specification (GTFS), originally developed by Google and TriMet. GTFS standardized how public transit systems share information about their schedules and locations of their vehicles (GTFS -real time). GTFS is not software – it is a data specification or standard.
GTFS has allowed apps like Google Maps or Lyft’s new transit features to easily present information to travelers about public transit systems around the world, regardless of which companies own and operate those bus services or rail systems, or which technology companies embed GPS devices on the vehicles used.
Requiring open standards is essential for preventing vendor lock-in, which has been a key problem facing many public sector agencies. Many U.S. transit agencies hold lengthy 15- to 30-year contracts with “systems integrators” who bundle proprietary hardware and data systems that they might purposefully make inoperable with other systems to facilitate vendor lock-in.
Open Source Software
Open source software is code that is developed in the open, free to license, and can be built on by other developers. Unlike standards, open source software is code that a city might run on its own to fulfill a specific purpose. OneBusAway is an example of open source software (or code) that utilizes the open standard, GTFS, to produce expected transit arrivals (ETAs) for buses.
Open source projects that are typically successful are usually oriented towards solving very broad, private sector problems. In order for open source to thrive, it requires the time and energy of many (typically thousands to tens of thousands) of contributors. In the context of the public sector, where there are relatively few software companies and thus relatively few software developers, the main advantage of open source software is that it is more customizable (but not scaleable or cost efficient).
Based on my prior years of experience developing open source software for the public sector, there are a few key downsides to open source software, including the following:
- Implementing custom open source software implementations often takes more time than purchasing off-the-shelf software.
- Custom open source software implementations often cost more money than purchasing non-custom software.
- There are very few software developers who want to build and maintain open source software for limited public sector use cases, so agencies are often locked into vendors (consultants or companies) who are the only ones who want to bother continuing to develop custom code.
An example of a custom software implementation that I helped build as a researcher at MIT was the development of complex forecast modeling software to estimate the impacts of the U.S. aviation sector. In this circumstance, the software we built was likely more expensive than an off-the-shelf solution. However, there are virtually zero other organizations with an interest or need for aviation emissions prediction software. Thus, the only option for our customer, the Federal Aviation Administration, was for them to purchase relatively expensive, highly-customized software. We delivered this software 10 years ago, and to this day it continues to be maintained by the same research lab. (Not a particularly flexible or efficient solution, but in this case, most likely the only viable option).
MIT is a non-profit institution, and the solutions that we delivered are not scaleable or commercializable. The problem with open source software developed by for-profit entities is that unless their business models are transparent, open source software provided to public agencies can lead to unexpected outcomes.
Red Hat came under fire a few years ago by many technology experts for predatory approaches to facilitate vendor lock-in to their services. With their recent acquisition by IBM, some of those concerns have risen again.
Implications for Mobility Management and Mobility-As-A-Service
The key takeaway for public agencies in an increasingly technologically-driven world is that open standards are essential for ensuring flexibility and creating an open ecosystem where competition (and lower costs for cities) thrive, but open source software is a double-edged sword.
Open source software can make sense if there are no cost-effective software-as-a-service alternatives available, where one has to design for highly custom needs that are truly unique and non-replicable, where a public agency is willing to pay more and can accept vendor lock-in.
In the realm of mobility-as-a-service and mobility management, where increasingly mobility companies can be required to deliver data through open standards (such as GBFS), open source software solutions simply cost cities more – without any added benefits.
