The OpenCourier protocol opens up opportunities for delivery workers to own the platforms that manage their livelihoods. We introduce the protocol, welcoming contributors and comments.

Gig work platforms have become a part of everyday life, but the centralized control of those platforms by corporations has led to power imbalances and information asymmetries that put workers — who are often categorized as contract workers — at significant economic risk. For example, stories of drivers being locked out of their Uber accounts have become commonplace. Likewise, workers often note that they must live with constant uncertainty about their daily income and costs, with tips getting pocketed by platforms and daily earnings falling under minimum wage.

In recent years, workers have organized and fought back, even pushing forward legislation in some states in the United States. Our team has been involved in the Workers’ Algorithm Observatory, developing tools like FairFare, which helped crowdsource nearly 1 million rideshare trips across the U.S. in collaboration with labor organizations.

Platform-based work still has the potential to enable an ecosystem of labor that is beneficial to workers, particularly those who need more flexible hours or conditions than traditional work arrangements. However, creating systems that center workers’ needs to begin with is crucial to improving this market. Although hundreds of local independent platforms have sprung up in an attempt to do exactly this, they often end up relying on white-labeled software that is costly and hard to customize, making it harder to compete with large centralized services.

Inspired by protocols shaping the early internet and more recent decentralized social media systems, we envision a protocol-driven ecosystem where cooperatives of workers are able to own and govern the platforms that their livelihoods depend on. Protocols define an open standard of data exchange that anyone can build upon, enabling an ecosystem of interoperable technologies. This means, for example, that worker-owned platforms using the same protocol could leverage a shared system to achieve similar economies of scale as centralized platforms that have come to dominate the market. 

Below, we introduce OpenCourier, a protocol we are developing to enable a decentralized ecosystem of community-owned delivery platforms. 

What is OpenCourier?

Aiming to shift control of delivery work away from a single entity, OpenCourier is a protocol that defines data formatting and communication across a decentralized network of delivery platforms, couriers, and service requesters. Broadly, we aim to enable an ecosystem (Fig. 1) that centers community-owned delivery platforms, where workers — who we refer to as couriers, given their work providing delivery services — cooperatively manage the platform they are a part of. 

We focus on a protocol centered around couriers because of the precarity of their current work conditions; it’s crucial to enable more decision-making by couriers themselves. Inspired by current challenges faced by couriers on centralized platforms, the OpenCourier protocol has three main goals:

• Enabling value alignment. The protocol gives couriers the agency to join independent gig platforms within the ecosystem, allowing them to conduct work based on their values and working preferences.
• Correcting information asymmetries. The protocol ensures transparency across the network of independent platforms by mandating the disclosure of key information and standardizing data formats for third-party auditing.
• Reducing power imbalances. The protocol embraces open-source development, enabling shared tools and innovations to benefit all stakeholders in the ecosystem.

Notably, OpenCourier standardize how couriers can get, organize, and share information necessary to coordinate last-mile delivery services. In addition to reflecting our intentional choice to focus on couriers, we do this because promising protocols already exist for e-commerce, such as Beckn, a protocol that provides an open framework between customers and businesses (e.g., restaurants/retailers). Rather than focusing on customer-facing or vendor-facing technologies, OpenCourier focuses on courier-facing technologies.

Three key layers of interaction

Fig 2. _{Here we show the architecture of the decentralized community-owned delivery ecosystem enabled by OpenCourier through three layers in the protocol. Courier instances register with the ecosystem through the Registry layer, and courier mobile apps can discover available instances via the same protocol. Couriers may use any app that implements the App-Instance layer to fulfill delivery tasks for the instances they are contracted with. Instances manage delivery tasks and collect courier preferences through the App-Instance layer while interacting with service requesters via the Instance-Requester layer.}

OpenCourier defines multiple endpoints for three main layers of interaction that a courier encounters in our ecosystem. 

First, to be able to provide last-mile delivery services, a courier must join what we call a Courier Instance, an independent instantiation of a delivery service platform following the protocol. Typically, we envision an instance as being run and self-governed by a local cooperative of couriers, such as one that’s geographically based. To enable couriers to find courier instances that are aligned with their values, OpenCourier defines a Registry layer that provides a curated directory of Courier Instances so that a courier can choose a “home instance” that helps anchor their daily work. An individual or group might organize to set up a registry for workers to peruse; many registries can exist independently of one another. 

Second, couriers must be able to receive and manage jobs from their Courier Instances.  We envision a courier using Courier App(s), software application(s) that couriers use to see and manage their daily work, as part of the Courier Instance(s) they are a member of. A Courier Instance can develop its own App or use those developed and made available by others. This is the App-Instance Layer.

Third, Courier Instances must be able to get the tasks sent by Restaurants/Retailers. OpenCourier envisions a layer of Instance-Requester Interactions that define how Courier Instances negotiate through quotes and open texts with Restaurants/Retailers, who broadcast the delivery task after querying the Registry to multiple Courier Instances and pick one to conduct the taskBecause transparency is a key goal of the protocol, the Instance-Request Interactions layer also enables a Courier Instance to share data to data requesters like researchers for external auditing(calculate average hourly rates) across the ecosystem or regulators as requested by data disclosure requirements. 

Implementing OpenCourier

Fig 3. _{Screenshot of the instance selection interface on the Courier Client. Couriers see a list of instances along with brief introductions for each, then pick one (or more) to join via the courier client. As all platforms within the ecosystem follow the same protocol, couriers are able to manage delivery logistics in a single mobile client.}

To provide proof-of-concept of the protocol, we developed a mobile app that serves as a Courier Client, which communicates with a dummy Courier Instance that we set up. The Client is an example of where developers leveraging our protocol can help build technical features that would make new norms or ways of organizing among couriers. For example, a key feature of our prototype Client is its focus on collecting preferences of workers, such as choosing a method of calculating earnings or noting weight limits. We might assume that a Courier Instance using a Client like this one cares about matching jobs to their couriers beyond speed of delivery.

Like many protocols, there are many ways to implement OpenCourier in practice — in terms of both technical infrastructure and organization. For example, a Courier Instance might use a cloud service for its server or choose to self-host a physical server; opt to be part of certain Instance Registries or not others; use a specific Courier Client that offers more or less options for its workers to specify preferences; bring couriers into more participatory decision-making about how to allocate jobs, or make executive decisions through a smaller leadership team.

This flexibility of OpenCourier is intentional: we welcome diversity in innovation in how to implement the protocol, to help break the constraints in how we currently understand the platform economy. We invite diverse communities to innovate, experiment, and share tools in ways that reflect their own values and needs. 

Ultimately, OpenCourier aims to reimagine how last-mile delivery platforms are built and governed by centering workers as the primary stakeholders. Our hope is that this ecosystem can not only mitigate the inequities of existing gig platforms but also foster more sustainable, transparent, and cooperative models of work. We welcome collaborators, critics, and contributors to share comments and join us in shaping what worker-owned delivery can become.

About the authors:
Yuhan Liu (Computer Science, Princeton University), Varun Nagaraj Rao (Computer Science, Princeton University), Sohyeon Hwang (Center for Information Technology Policy, Princeton University), Janet Vertesi (Sociology Department, Princeton University), Andrés Monroy-Hernández (Computer Science, Princeton University)

Also read their vision paper.