- Author: Kevin Chambers
- Date: June 9, 2020
When the topic of using technology in the public interest comes up, open-source software (OSS) is a frequent phrase on…
In the first post of this series, we looked at what open-source software (OSS) is and some of the key points in its history. We also learned about examples like Linux and Firefox that have millions of dollars supporting their ongoing maintenance and growth (via the Linux Foundation and the Mozilla Foundation, respectively).
Not all OSS has this level of financial backing, though. In this post, we’ll examine two more obscure open-source projects that have different business models. Our first example has stuck to a model of decentralized, collaborative management and development that competes with corporately supported products. Our second shows how transit leaders have leveraged OSS for an industry-specific success story.
In our third and final part in the series, we’ll focus on how open source software and the business models that support them can advance the work of mobility management.
I promise, that’s not a typo. Pronounced “post-GRES-que-ell” and often referred to simply as “Postgres”, this general-purpose relational database system has been around since 1986. It grew out of a federally funded project at the University of California at Berkeley, and has been under an OSI-approved open source license since 1995 (See the prior article for more details on the Open Source Initiative). PostgreSQL version 13 is poised to be released in the next few weeks.
Of the hundreds of specialized and obscure open source projects that keep the internet working every day, Postgres is a prime example of a success story. 25 years after becoming open source, more than 500 people have contributed to the code over the years, and the project is sustainably managed and supported through donated funds, services and volunteer time. DB-Engines ranks PostgreSQL among the most popular database products. It competes directly and successfully against proprietary industry heavyweights such as Microsoft and Oracle.
Postgres is able to compete and grow in popularity, David-vs-Goliath-style without the stability of being owned by a single large corporation, in large part due to a rich ecosystem of committed developers and businesses. Some of its contributors are freelance programmers that can use their expertise to build their résumés, others are providers of hosting or consulting services for the database, while others yet are employees of large corporations that rely on Postgres as part of their core internal infrastructure. In other words, Postgres is not a utopian escapade fueled by the selfless acts of nerdy heroes (though there may be a bit of that). Rather, the project thrives because of a wide range of business models that all benefit from Postgres being a well-maintained shared resource. This has been called the cornucopia of the commons.
The world of public transit has its own OSS success story: OpenTripPlanner. It has some similarities to Postgres, but as a newer entrant into the tech world with a narrower function, it has a smaller reach and a different growth pattern.
OTP got its start with support from a grant from Oregon Metro, The Portland area’s regional government agency. Metro awarded a grant to TriMet, the region’s public transit agency, to develop a multimodal trip planner. TriMet hosted a three-day workshop in 2009 for transit and tech leaders, contracted with OpenPlans (which at the time had a software development team), and OTP was born.
At the time, it’s unlikely that anyone would have predicted that 11 years later, OTP would be in use by at least 26 different government agencies in ten countries. More than 100 people have contributed to the OTP code. Version 1.0 was released in 2016, and work on version 2.0 is underway.
OTP is governed by the 12 members of the OpenTripPlanner Project Leadership Committee. Since 2013, OTP has been part of the Software Freedom Conservancy, an umbrella nonprofit organization that takes on the administrative functions of member projects. While not glamorous, having a decision-making body to guide the project and gain access to support for administrative, fundraising, and legal issues represents an important stage in OTP’s growth and maintainability.
There are many more notable moments and technical developments in OTP’s history, but we’ll highlight three of them.
In selecting these milestones, the goal is to emphasize how agencies have made choices that have helped meet their own needs while also contributing to the project’s usefulness to the larger field, and to illustrate that major changes in the project have been closely tied to infusions of government funding.
When TriMet wanted to get an improved trip planner with lower costs, they could have worked in isolation to do so; it would be reasonable for an agency to focus attention on meeting their own needs, after all. Instead, they pursued one-time funding that allowed them to initiate a collaborative development process. In effect, they set out to build not just their own solution, but a piece of IT infrastructure that’s available to anyone. A further bonus: transit agencies can use this powerful software without going through a potentially painful procurement process.
In addition to the software itself being open source, OTP has from the beginning relied on open data standards and open data. Routes and schedule data can be loaded into the planner using the General Transit Feed Specification (GTFS). The default data source for maps and road networks is OpenStreetMap, a world-wide crowd-sourced GIS database available under an open-source license.
OTP made it possible for riders to consider walking and biking options in addition to fixed-route transit as they planned their trips. But it wasn’t possible to plan trips that included flexible transportation services such as taxis or ADA paratransit—in part because it wasn’t possible for transit agencies to provide that information in a standardized computer-readable format. The aforementioned GTFS format only supported fixed routes and predefined schedules.
Fortunately, the world of transit standards continued to evolve: first proposed in 2013, GTFS-flex extends GTFS to include demand-response services. By 2017, the proposed spec was mature enough for the Vermont Agency of Transportation (VTrans) to bring this new standard into OTP for a statewide transit planning application that could account for more flexible forms of transit as well. VTrans received funding for this project from the Federal Transit Administration’s Mobility on Demand Sandbox Program, which supports demonstration projects. Like TriMet’s initial funding from Metro, the FTA grant to VTrans fueled the innovation but did not provide an ongoing source of funding.
When it comes to transit, the differences between the United States and European countries are considerable, down to the basic terminology (“public transport” over “transit”) and historical relationship to data standards, among other things. One area of commonality, though, is use of OTP. The Netherlands, Finland, and Norway have all worked with OTP at the national level, and we’ll take a closer look at Norway as an example of open-source software’s flexibility.
In 2016, railway reforms by the Norwegian government led to the creation of a publicly owned company called Entur. One of Entur’s core mandates is nationwide trip planning for all public transport. To carry this out, Entur:
Entur began working with OpenTripPlanner from the start, but they soon came to a choice point. OTP deployments relied on GTFS to load route and schedule data, but a different set of standards was more commonly used in Norway and much of Europe already: Transmodel, which uses the NeTEx standard for static data and SIRI for real-time data. Entur decided to pursue an OTP implementation that would be compliant with Transmodel.
If OpenTripPlanner had been a proprietary system, Entur wouldn’t have had the flexibility to combine existing software with a set of standards that was a better fit for its needs. This adaptability is one of the clear benefits of open-source software.
This decision also set Norway up well to comply with a European Union mandate for each country to have a national access point for transit data. The goal is to ultimately support travel planning throughout Europe. Under that mandate, use of NeTEx is required and SIRI is recommended. Although Norway is not a member of the European Union, Entur’s pursuit of a Transmodel-compliant planner sets them up to be able to connect to a continent-wide journey planning system. And because all of Entur’s products are open source, their Transmodel-compliant version of OTP can be readily used by other European nations. You can find more details about Entur’s work on OTP from documents shared from an April 2019 summit.
These two software success stories offer insight into what open source can achieve generally and within the field of transit. Those accomplishments have been possible because of committed individuals, solid governance structures, and sustainable sources of resources for development.
But how relevant are these cases to the world of mobility management? Is there a pathway to mobility managers being able to enjoy similar successes for their own needs? We’ll explore that in the third and final part in this series.
Have more mobility news that we should be reading and sharing? Let us know! Reach out to Kirby Wilhelm (firstname.lastname@example.org).