Platform Coops Meetup At Supermarkt
Towards our goal of developing open source tools to empower groups and individuals to collaborate in radically sustainable ways, we were curious to hear the news that corporate owned food delivery company Deliveroo suddendly shuttered it’s Berlin branch a couple months previously. With Deliveroo’s departure, multiple food courier collectives started forming.
When analyzing the various courier collectives and how they operate, each has different needs and concerns- cramming everyone under the same roof of one software configuration feels wrong. Some groups want to do payment on PayPal while another accepts Bitcoin and cash only. Some riders deliver to multiple zones like Kreuzberg and Friedrichshain, while others deliver to only one zone. Who manages dispatching of orders if it’s not 100% automated? In all cases the right amount of “elasticity of scalability” is needed to have enough riders to meet the timely demands of customers, or conversely enough orders to pay riders livable wages. This scalability seems like the largest challenge for all food courier collectives.
Looking at existing software solutions like the fantastic CoopCycle where the app developers created a traditional monolithic web app that puts everything under the same “virutal roof” makes for nice unified brand experience and it eases software development. However, this software architecture also limits configurability to account for multiple collectives different needs. While peer-2-peer software (in theory) can offer greater freedom and configurability, that architecture is often significantly more complicated to develop.
We worked with Christopher Mäuer to create an experiment called Food For Coins that used a simple web application for ordering and and also have a Telegram bot to helps with dispatching orders to the riders and accepted bitcoin and cash for payments. We are currently discussing setting up clones of our software for the the courier collectives. While this would not solve the elasticity of scalability issue, it would allow for different groups to experiment as they need to without affecting others. To address the elastic scalability issue, we are exploring how to best create a large order que or API that all the collectives can feed their live order data into and allow a “matchmaking” to take place that allow collectives to help other collective load balance when needed, while also keep the autonomy of that given collective’s desires. If developed right, this sort of matchmaking could allow all sorts of different types of collectives to collaborate with one another and balance work needs.
Modified from article on SUPERMARKT