Open Source Community Economy
Concept notes • Thomas Stephens / 3DVR • October 4, 2026
The vision Communities can build, own, and operate the infrastructure that supports their livelihoods. Open source designs and coordination tools let each neighborhood start small, share improvements, and decide how its own operation works. Delivery is the first connecting service; a broader cooperative economy is the long-term possibility.
How the idea developed Thomas first proposed an open source bus: people could form their own bus companies, get together, and build a bus. The shared toolkit could include vehicle designs, parts lists, assembly and repair instructions, route and ticket software, ownership templates, and a network of local workshops. Documenting a conversion of an existing bus was suggested as a practical learning step, rather than immediately designing an entire vehicle.
Thomas then proposed delivery as a more accessible starting point. People could deliver mail or goods on foot and upgrade their means of transport as needed. Crucially, Thomas clarified that a worker would not even need a phone: they could rely on the network. This grew into the idea of a whole economy built around shared community infrastructure.
Participation without personal equipment The entry point is a person's time, abilities, and willingness to contribute. Owning a phone, bicycle, or vehicle should not be a prerequisite. Offer walking routes and other roles suited to different abilities, including dispatch, repair, packing, coordination, and administration.
A staffed neighborhood hub can accept orders, assign packages, print routes, and record handoffs. A courier collects packages and a paper delivery log, completes a route, then returns confirmations and undelivered items. The hub reconciles the log and updates the shared system. Phones are optional tools; the network carries coordination.
Potential hubs include participating shops, cooperative spaces, and other willing community locations. Libraries were discussed as a possibility, subject to their agreement. Participation by any location remains a proposal.
Transport grows with actual demand Walking: small loads and short neighborhood routes. Bicycle or cargo bike: longer routes and greater carrying capacity. Shared van or truck: larger loads and demand that supports the costs. Community buses: a later branch for passenger transport and community vehicle building.
Workers should be able to use shared equipment. Progress need not mean every individual buying a vehicle. Match routes to capacity, terrain, weather, accessibility, and safe working conditions.
The shared toolkit Publish software, operating guides, and appropriate hardware designs in forms others can inspect, reuse, and improve. The proposed software covers order intake, dispatch, route planning, payments, maintenance records, and proof of delivery. Printable manifests and receipts are part of the core experience.
A basic record includes an order reference, pickup and destination, agreed delivery window, load requirements, assigned courier, handoff confirmation, completion or exception, and payment status. Keep personal addresses and delivery records private; open source does not mean publishing customer data.
Hubs need a process for missing paperwork, disputed delivery, damaged goods, failed handoffs, and service interruptions. Paper records should reconcile into one shared record without double-booking or duplicate payment.
Local ownership and cooperation Local groups could own the service, equipment, and hubs. Drivers, walkers, builders, dispatchers, merchants, and riders or customers could contribute to governance. Ownership structure, membership, compensation, voting, and surplus allocation remain decisions for the participants.
The network should make charges, worker pay, shared costs, and decisions understandable. Shared software must not force a single distant company to own every local operation. Communities can cooperate across boundaries and contribute improvements back while retaining local control.
A whole economy Delivery connects people who grow food, cook, repair things, make products, teach, and provide other services. Hubs can also help coordinate shared tools, workshops, storage, and local offers. Existing Portal community and farming tools provide a natural place to connect these activities.
The first useful loop: a local shop needs delivery; a neighbor earns money completing it; that neighbor spends locally; another business gains a customer. This is the proposed mechanism, not a demonstrated economic result or a promise of income.
Start with ordinary payments and clear records. A new currency, token, or mandatory device is not required. Larger systems should follow actual needs and decisions by the community.
Proposed smallest pilot 1. Choose one compact neighborhood and a willing dispatch hub. 2. Find a few local shops with recurring, lightweight delivery needs. 3. Agree on a service area, delivery windows, prices, worker compensation, and responsibilities. 4. Run a small walking route using printed manifests and manual dispatch. 5. Reconcile every handoff, delivery exception, and payment at the hub. 6. Measure demand, delivery time, worker earnings after costs, reliability, and customer experience. 7. Improve the process before adding software complexity, equipment, or another neighborhood.
The pilot is a proposal. No participants have been recruited, services launched, prices approved, or funds committed through this document.
Decisions to resolve before operating What do local merchants actually need delivered, and how frequently? Who hosts and staffs the hub? How are workers paid fairly when volume is low? How are loss, disputes, weather interruptions, and shared equipment handled? Which ownership and governance structure do participants want?
Mail was part of the original idea. Research the applicable postal rules before offering letter or mail delivery. Also establish applicable operating, insurance, labor, vehicle, food-handling, and accessibility requirements for the actual pilot location and service. These are unresolved implementation questions, not legal conclusions.