What might a Coop Uber look like (or should we be thinking bigger)?

I learnt of an interesting  coop recently: the Depository Trust & Clearing Corporation, responsible for clearing and settling most US securities (i.e shares & derivatives). At the heart of global neoliberalism is this user-owned coop, which holds some $40 trillion in securities, running a service the entire economy depends on. I’d been surprised enough to learn that Slaughter & May, the infamous corporate law firm repping half of the FTSE100, was a mutual partnership with no hierarchy or even boss, amongst hundreds of profit-sharing partners. 

If the temples of capitalism embrace user- and worker- owned structures, then why not the digital world? There’s understandably already a lot of interest in the idea of a Coop Uber. As Mike Konczal pointed out last year, Uber is rare in that the assets that make up the company’s service are owned by the workers:

“Given that the workers already own all the capital in the form of their cars, why aren’t they collecting all the profits? Worker cooperatives are difficult to start when there’s massive capital needed up front, or when it’s necessary to coordinate a lot of different types of workers. But, as we’ve already shown, that’s not the case with Uber.”

Uber takes 20% for connecting drivers with passengers, potentially a significant chunk of the estimated $50bn/year generating global taxi industry. Cory Doctorow explored the idea at this summer’s FooCamp,

The issue is relevant across the digital economy where certain sectors have, as Justin Fox on Bloomberg says “a tendency toward natural monopoly; as you attract more people to your platform, it becomes more valuable”. 

Services who benefit from large databases - be it the most drivers, songs or people’s stuff for sale - will inevitably end up dominated by the service with the most or best records in the database. Network effects dictates that the biggest gets bigger, and no-one has a fair idea what to do about it beyond accepting it as an operating condition of Web 2.

Fox concluded that “it is possible to imagine that years down the road, when these marketplaces are mature businesses, there might be advantages to running many of them as cooperatives instead of as shareholder-owned for-profit corporations.” Coops are one of those strange semi-socialist structures that fits comfortably within capitalism, yet runs closer to the Catholic economic theory of distributism. 

Post-Kickstarter, it’s easy to picture a writer-owned Kindle or a filmmaker owned YouTube — being funded and supported by sufficient numbers of disgruntled writers or filmmakers to power it into life. With the rise in ‘worker-on-demand’ applications coops could be a way to offset regular criticism about how these services reduce worker rights. 

But for now it’s challenge enough just to consider what a coop Uber might look like, which is the question I’ve spent some of my spare moments this summer considering. In this long read, after outlining two relatively conventional coop structures, I explore a third option that has more in common with the web and decentralised systems such as Bitcoin.

 

Option 1. The mega-coop

Option 1: the mega-coop diagramA logical starting point is simply to recreate Uber/Lyft/etc, with their global network of offices, drivers, marketing and technical infrastructure, as a driver-owned coop, operating either non-profit or with its profits distributed amongst drivers. It would need to be a large, well financed organisation with a legal and customer service team in every country it operated in. 

This would need a financing model that dealt with the initial startup investment and the ongoing day-to-day costs. The former could potentially be done through crowdfunding, or even with a community share offering, such as those offered on MicroGenius, so that backers could get a return on their investment. Given Uber has raised a sizeable $7bn across 12 rounds the amount of capital needed would be considerable, and balancing the potential demands of investors against the needs of a democratic member-owner organisation, would be key. Day to day costs could be covered, as with Uber, through a percentage on fares, through monthly/annual membership fees, through licensing API access to external providers, or some combination.

Although costly to setup, a single-coop competitor is appealing because it would be easier to manage, brand and offer users and drivers quality assurance. It would require a commonly agreed-upon set of regulations and pricing, which every taxi would have to follow, so as a democratic organisation would need to find ways to agree pricing and rules across national and regional differences between its members. 

 

Internal voting and localised rules could mitigate some of this, but given the scale such a service would need to expand to have any hope of competing against Uber, the democratic aspects of the organisation may well need to come secondary to the initial growth strategy. Indeed there are no successful giant digital democratic coops working on an Uber scale of 160,000+ drivers to hold as an example. The coop would have to find the right balance between the risks of being so democratic it was slow or unresponsive, against being an unaccountable and top-down behemoth. And, of course, if a success it could still end up with monopoly power, and the ability to force users and drivers to follow a one-size-fits all set of rules.

Option 2. Federation of existing companies

Another, lower-cost approach would be a coop that produced software and services for existing taxi companies who already have offices, relationships with drivers and passengers, not to mention leasing agreements and insurance schemes around their fleet of cars. This would both distribute control out beyond the central coop, responsible for creating software, and work to build upon an existing networks, brands and services, rather than striving to throw them all out of business.

Option 2: Federation of existing companies diagramThe coop in this instance would produce ‘white label’ software to manage drivers and payments for each of the companies, and also a single branded app which the user downloads. At this point either all the companies in each city and region would need to agree on and use the same prices, or the app would need to indicate that different cars were from different companies and had different prices. By letting each taxi company set their own prices this would create greater potential for competition and variation – car company X with the older cars is 20% cheaper than taxi firm Y which only has recent Sedans, while company Z has a 100% electric fleet of Tesla cars. 

 

As well as offering more choice and competition, it also removes from the main coop the burden of verifying and approving new drivers’ identifies or providing customer service. It is more closer to an infrastructure, software-as-service company, serving it’s members, who are all established companies. On a simple level, this already exists - a company like Mowares offers an Uber clone from $400. What a coop — owned by all the local taxi companies paying for installs — could further do, is ensure that each install could communicate with each other and produce a single app for users to download that connected them to all of their local taxi companies.

Most appealing about this model is how little cost it would take to achieve scale, provided it was supported by sufficient taxi companies, while also dealing with any potential legal problem, by passing the problem over to taxi companies who have long operated in the local/national environment.

Nevertheless this approach maintains the middle-man, the taxi company, an extra cost which Uber has removed. Part of Uber’s ability to charge low fares is replacing the expense of taxi offices, switchboards and phone receptions with software they can reduce the cost of journeys. So this coop model may always end up more expensive than Uber or Lift as it needs to pay both driver, the coop producing the software/service and the taxi companies representing the driver. While some companies, such as executive car services, with account management, may offer sufficient value to justify the added cost, it’s hard to imagine the cost-conscious end of the market acting in the same way. It may require, as Seth Ackerman proposed, cities and countries making a legal requirement for taxi-apps to be worker-owned to succeed.

Of course this no help for the driver who, for whatever reason, doesn’t want to join the local taxi-company, or can’t, which may be an issue in areas where there is only one taxi service. But a service which lets drivers register directly has a much greater administrative burden and legal liability around verifying drivers and their licensed vehicles. To do the verification job well, the model ends up more centralised and much closer to the first option above. 

Interlude: trustiness as a sliding variable

All that I’ve read and my thinking for most of the summer seems to move between these two models - either a large centralised coop that verifies individuals who join up but that risks being undemocratic and less nimble and innovative; or a more decentralised, federated system that only works with companies who in turn take responsibility for driver management and verification.

But then I was remembering hitchhiking in France as an eleven-year-old with a girl who had told me loudly I had a bum-chin (a chin so dented as to have its own cleavage). We decided to sneak out of the boring campsite and hitchhike to the nearby town. It seemed a suitable adventure and we were aware enough of the risks not to tell anyone lest we were stopped, although not aware enough of them not to do it. We squeezed into a smoke-filled Citroen with three men quite oblivious to any dangers. They dropped us at the supermarket, where I bought a bottle of wine to take home, and we hitched back.

Hitchhiking was – and in many places still is – normal, despite there being no identity checks and the occasional, mostly fictional horror story. Because of this it’s something both the driver and passenger do at their own risk, with their eyes wide open — somewhat like giving your credit card details to a website in the 90s. By comparison, a system that records you as a person, getting into a specific car, licensed to a specific person at a particular time and location, is many orders of magnitude safer than hitch-hiking. Lift sharing and car-pooling websites, have far softer requirements – liftshare.com seeks only a verified email address to offer and cost-share a trip you are making – but there are no publicised problems with car-sharing scams.

In other words, perhaps trust is something relative to time, circumstance and conditions. If I’m stuck at night in a remote rural location having missed the last bus - I’d hop in a car with almost anyone if it’s the only one nearby. If it turns out that someone in my office block is making almost the same trip to work each day, even tho I don’t know them I’d be happy to share a ride and split the petrol. If I need to get from a train station to a meeting at the last minute, then I’d want a driver who knows how to handle the city in rush hour. If I’ve got to do an early morning long distant trip to an airport as all the public transport is down, I might just want to go with the cheapest price I can find.

 

So, instead of than having apps for each of these circumstances, or trying to design a coop that could accommodate some or all of these needs, why not design and build an architecture - a set of protocols and systems - for car journeys, and build the coop car app on top of that? 

Option 3. A distributed architecture for journey data

Option 3: A distributed architecture for journeys diagramIt's may be easiest to illustrate this idea by looking at the web, which illustrates quite how much a decentralised, open system with lots of competition at every level can achieve.

URLs are unique, point to websites and are either encrypted, with an certified working encryption and a https:// prefix, or unencrypted (http://). These websites can run a huge choice of software and sit on many types of servers; competing search engines can all index these websites and serve up the results through browsers which are viewed by the end user across phones, PCs, tablets, TVs and so on. There’s a total, genuine free-market in devices, browsers, search engines, websites, servers, the software that runs on servers - and this potential anarchy of decentralised maximum-competition is all held together by a commonly agreed naming system pointing to every site (the URLs), and some open source code - HTML, javascript, CSS and HTTP - that everything across the system can understand.

A protocol for journeys, rather than pages, could be achieve something similar.

Any driver with a car that wants to offer lifts could be identified with a unique URL: mydonutrickshaw.car or 123.456.789.101112. Maybe they paid for a security certificate to verify their identity and driving/taxi license, so they are a ‘secure’ https URL, or maybe they didn’t.

Someone wanting a lift fires up an app with their phone. It’s already got their preferences stored - they’ll take any lift from Facebook friends, people in their address book, or who work in their company - as well as drivers from Addison Lee, Uber, Lyft, the new Tesla.Coop or any trusted (https) drivers with a minimum 6 months experience. On telling the app the journey they want to make, they see that there’s an expensive executive car available within five minutes, and a dozen cheaper options in up to 30 minutes, one of whom they’ve travelled with before and liked If they wait another two hours, there’s a neighbour who will be in the area and will be driving back directly. All this information is pulled from bits of the system, and all is designed to prevent any single player dominating or monopolising the market through a technical advantage.

How could this work?

This approach has four core elements - Coop, Open Source, Register & Semantic data (clumsily abbreviated as CORS):

  • A Coop, funded by its members, is in charge of building and maintaining…
  • Open Source Software, available to anyone who wishes to use or modify it, provided they register on a…
  • Register, a method to provide a trustable, yet decentralised index of all users, drivers, and groupings (i.e. Taxi firms). It could be run on the blockchain, and its records are stored at uniqiue URLS using…
  • Semantic data to store information for each URL, unique to each user, driver or group – with access control revealing differing information depending on who is asking, and which any other parts of the system—if allowed—is able to read and interpret meaningfully.

This approach is loosely parallel to the web’s architecture of:

  • Worldwide Web Consortium, a non-profit organisation funded by its members to approve… 
  • HTML/CSS/etc specs, powering websites whose address is stored by…
  • ICANN, the global domain name registry, which points to…
  • Http web servers, which resolve domain names into working websites, and can be hosted anywhere.

As with the web, certificate authorities could add a further level of trust by granting to drivers a machine-verifiable certificate guaranteeing they are who they say they are.

This model has a few aspects:

  • Creation by the coop of the open source software used by both taxis and users is funded by a set of a founder members who will benefit from the service, be it cab companies, taxi driver unions or individual drivers. Locking in funding ensures the software is supported and delivered to the needed standard. This could be returnable investment as with a community share offering, or it could be donations or a share of earnings.
  • While this coop controls the release of the software and defines the schema or structure of the data people must include - it does not own the network of drivers — anyone publishing a semantic page about their car in the correct format and joining the register/blockchain is in. So without being a member of the coop, say, a taxi company in Delhi could host semantic data (i.e. a page of machine readable information) on each of the cars in its fleet, and as soon as the cars are registered, anyone using the taxi software in Delhi would see these cars in their service. 
  • Conversely, anyone could build interfaces to read and interact with the data, or integrate it with their service, be it a conference venue wanting to offer taxi-booking from their event aps, or a procurement system trying to pre-book cars at the lowest price. Uber could offer non-Uber cars through it’s app when its own weren’t available, and likewise offer Uber cars through other apps; drivers meanwhile could chose to work through taxi coops and peer-groupings, under a bigger branded umbrella or on their own, keeping the maximum share of the fare.
  • Maintenance of the blockchain would presumably have a small cost associated with it, which could be paid for either by processing new information added to the block chain (i.e. in-kind processing across all apps) or a very small payment per transaction. Similarly the core coop would depend on continued funding, which may be through membership fees or a flat, low, levy.

The problems and challenges

Even with this structure there are significant challenges for a distributed system to overcome. There's issue of privacy and payment: a traditional cash-fare taxi ride stores no details about the passenger or the driver (unless the passenger makes a note of the car registration or taxi license number). Part of ride-apps’ appeal are their cashlessness; for this to work in a decentralised form the user would need to store card details on their own device, uploading the information or making the payment to their driver upon arrival in a dependable, secure way, with some fallback in case their phone lost battery or signal.

Would it require the driver and user to have the latest phones? 

The driver too would want to keep track of their journeys and how much they had earned from each, but there may be security risks if each user’s journey data was stored with the driver, revealing private address and movements to anyone who accessed the driver’s account. What about building the map of geolocated taxis? Finding a decentralised method to map a stream of ever-changing data such as locations may be more trouble than the cost of paying for a central service to provide that. How do you design to clearly indicate different levels of trust/knowledge around different drivers without quantifying drivers down to just numbers?

It would be naive to describe these issues as trivial; they aren’t and this doesn’t even begin to cover things like getting sufficient drivers and users to make the system worthwhile — Uber already has a significant first-mover advantage and has spent billions of dollars getting to where it is. Furthermore, many of the challenges to overcome combine engineering with social/business challenges — which is largely untested waters for many open source communities, although far more normal for cooperatives. This means the coop and open source world each have different yet vital skills and experience to contribute to making something like this.

A first step might be to prepare a draft protocol and software proposal and through a series of code-sprints, tele-seminars and conference meetups iron out potential problems and bottlenecks, before forming a multi-stake-holder coop to crowd-fund/crowd-equity a test stack of software. Ideally this would centre around one or two cities, perhaps those which have banned Uber, and to test it at scale with local investment, before trying to roll it out any wider and begin to deal with multi-lingual, multi-currency, multi-legislative environments.

These challenges, tho sizeable, don’t seem insurmountable – this doesn’t seem as complex as landing a robot on an asteroid accelerating through space, while the $50bn+ annual turnover of the global taxi market makes any competitor to a model like Uber, taking up to 20% on every journey, as both credible and fundable.

Indeed the potential rewards for solving this would bring much needed competition to sharing and worker-on-demand space. To imagine a decade or two from now having just one taxi company for the world, or one freelance employment agency, or one letting agency, each with total control over their market, their pricing and worker terms, would be as if to take the worst parts of totalitarian communism, privatise them and hand over to a single company.

Instead an architecture that provides all the benefits of app-based ride-ordering yet maximises competition and – like the web – is open to unlimited participants and new ideas, as the cost of exploring them will be far lower and less risky than if it was controlled by a large corporation or giant coop. So, if someone finds a way to offer drivers passing takeaway restaurants on the way home extra cash for picking up and dropping of pizza, or to let a business sync their spare vehicle capacity with a same-day delivery service, the architecture would easily accommodate it. If a large UPS-sized shipping company wanted to use the data to forecast when and where roads would be busiest, it could. In other words, the question is not about offering a coop version of Uber as much as using a coop to offer an open, free protocol for car journeys that could run Uber and any number of coops and alternatives sitting on top. It’s a more complex approach, but one that runs closest to the collaborative decentralised network economy and culture we’ve collectively been building this last few decades.  

 

by Nic Wistreich

Published 27 September 2015
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.