9.0 Notes (page 9)

Notes for Section 7.0 - Distributed Production Network

A Distributed Production Network (DPN) has the following differences and relationships to our first example of a Community Factory:

• The objective of the network is to provide physical products and income for its members.
• It follows the same principles and general reference architecture, as far as using automation and self-expansion.
• It assumes a network of separately owned nodes, rather than a community project.
• Being more distributed, it may have lower start-up needs than a Seed Factory starter kit.
• Some nodes can grow into a Community Factory/Seed Factory if they expand enough. Thus the examples are not entirely distinct, but have different emphasis. They can be part of a joint growth pattern.
• A DPN can begin with conventional businesses and individually owned equipment as a starting point. They join the network with the intent to cooperate and upgrade to self-expanding automation. They can be immediately productive offering goods and services to each other with what they start with. Upgrading can begin with small scale projects, initially via spare-time/excess capacity from existing work, or by pooling resources to buy or build automated equipment.
• By being distributed, a DPN would emphasize the various transport and communications aspects more than a Community Factory. Payments and remote operations would be more important.
• More design consideration should be given to starting with manual/conventional processes with the upgrade paths to automation.
• Design consideration should be given to setting up "Prototype DPN Nodes" as an R&D task.

Automated Protocol Derivation

The distributed network consists of nodes that perform functions and transport systems that connect them. Nodes are variable complexity, but do at least one task. Thus each function in a self-expanding architecture can be a specialized node type. Similarly the transport systems can carry multiple item types, but must at least deliver one type. Thus each input and output flow type can be handled by a specialized transport system. These "atomic" functions and flows can be used to define network interfaces and protocols. More complex operations would then be built up by grouping these atomic tasks into larger sets.

Growth Pattern

A DPN can start with individuals who collaborate to build or acquire conventional and computer-driven equipment, existing individual workshops, and larger scale businesses with existing equipment. They agree to work together as a network to upgrade each others' capabilities, and supply resources like labor, parts and materials. They may also form cooperatives, partnerships, or joint property ownership to carry out larger projects or build network locations. Over time, network members design and build new machines and software, and optimize their processes so that the growing network is more efficient and automated. Some network nodes can grow to be complete factories with high levels of automation.

For design purposes, we can assume starting with nothing, and building up conventional tools and equipment incrementally, with a goal to maximize self-expansion from the start. For example, basic woodworking tools can be used to make wood storage shelves in order to hold lumber for later projects. As the conventional workshop diversifies, it eventually starts building automated machines. In the real case where existing individuals and shops collaborate they can skip acquiring and building the early growth stages where they already have them.

Business Scenario

Because a distributed network is under different owners, they have to interact with each other, deciding what work to accept, resources to exchange, and payments for them. This falls into the category of business scenarios and plans. A scenario covers the whole operation of the network, while plans cover individual business entities. To develop these scenarios, we start by gathering ideas to incorporate, then try to organize and add details.

• Business Ideas

- Like other parts of the systems in this book, we would like to automate much of the work if possible.

- When you make things for yourself, rather than work for pay for others, or sell things to others, you are not liable for income or sales taxes.

- People can co-own fractions of assets jointly, as in partnerships or "tenancy in common". Typically profits or occupancy are split by the co-owners, but for our purposes we split production outputs, which go to the owners. The owners need direct participation to avoid creating securities (passive investment where others do the work). Securities create lots of legal and overhead complications. Participation means directing what will be produced, and doing some of the work. Not all outputs will be used directly by the owners. Some is likely to be sold, generating tax liability, but less than a pure business which only sells things.

- An automated market can be set up to trade or lease asset fractions as a given person's needs and interests change. For example, they might own part of an automated greenhouse that supplies food, and increase their share if they gain a life partner or child. An active market for asset fractions makes this easier. Portable assets would need an identification and tracking system the way automobiles have VIN numbers. Tracking could be via photograph and scan when it moves.

- The larger the pool of network assets and equipment, the more that can be made internally vs buying from outside. This increases opportunities to work for an output share and avoid sales mark-ups at each stage of production. Automating parts of the network lowers costs across the whole network.

- Specialists will still be needed, such as a greenhouse operator who understands the automation and growing plants. They would own a larger part of the greenhouse as the operator, while other people would buy portions for the output.

- A project needs to check the proper legal framework (cooperative, partnership, LLC, etc.) for their location. Unfortunately no single solution is possible because laws differ by location

- An efficient market for co-owned assets can potentially disrupt businesses with high fees, such as real estate and stock brokerage. A co-ownership finance structure with scheduled purchases by the buyer may lower risk and disintermediate banks.

• Gathering Capital

In conventional business finance, a new factory builder goes to investors and financial institutions to get the funds needed. There is typically a lot of paperwork, meetings, and overhead costs in acquiring the funds. In a distributed production scenario we can take a different approach. We can use a digital currency network starting from financial nodes to fund early production elements. Distributed asset ownership is tracked automatically, with payments and products flowing back to the financiers. The legal framework is "tenancy in common", with assigned output and usage rights according to the fraction of ownership.

Projects are posted to the financial nodes, providing a description, legal documents, and required investment to be raised. Individuals subscribe to investments by posting an amount to a digital address which is under their control. Thus the funds are still in their hands, but the public ledger allows everyone to see the amount raised. Once the goal is met, the funds are forwarded to the project organizer, who then uses them to purchase the production equipment. Contributors then own undivided fractions of the assets, and get proportional shares of the outputs.

This approach can replace conventional business finance. Someone setting up a new node or location, but does not have enough to pay for all of it, may provide 20% themselves, and get 80% from several finance nodes. In return for operating the node, they get more than 20% of the output, which can be used to buy the remaining ownership fraction over time. Eventually they can accumulate enough surplus to become part of a finance node themselves, and get part ownership of other nodes. Someone who wants the production outputs for their own use, but not operate the nodes, can buy fractions of various nodes which produce food, power, and other items on static ownership terms - their percentage stays constant. If there are not enough such nodes, a finance node can pay for building more of them.

• Transaction Network

Ownership rights, financial payments, and product deliveries involve promises and contracts between owners. The conventional methods involve paperwork and the banking system, which requires a lot of manual steps. As an example, assume an individual wants to order some farm products on a regular basis from an automated greenhouse. Buying part ownership of the greenhouse would be a single transaction, and later deliveries can be automated. A market can be set up for fractional ownership, where the operator keeps a steady percentage, and other people can buy and sell the remainder at will. This is not mere passive shareholding, since all the owners can submit requests for what the greenhouse should grow. Since living plants take time to grow, these output orders would be placed in advance, perhaps quarterly. Until then, the greenhouse would produce whatever it already has in progress. Information on what is being grown can be provided to the ownership market to help buyers select which ones to buy into.

Project Phases

The network is operated on the basis of individual choice to join and the level of participation, on an ad-hoc basis. Therefore it cannot impose any particular sequence or protocol on the members. However, network members can agree on features and coordinate plans. For design and analysis purposes they can then lay out a series of development and implementation phases, which we make a start at below.

As noted in the previous section, a DPN can start with individuals and businesses forming a cooperative network and using existing equipment. Therefore it can begin operating before any new designs for the network are produced. Logically, however, we place the research and development phase ahead of building and operating the network.

• Phase 0 - Research and Development

The R&D Phase covers creating the new and custom software and hardware to upgrade the automation, self-expansion, and distributed operation of the network beyond conventional current methods. Design nodes will be needed in later operation of the network to create new products and locations. Therefore we assume the early design nodes will also carry out R&D tasks, and spin out prototypes and locations as upgrades. Design projects are the work carried out by design nodes, with completed designs as the output.

This phase of the DPN development includes the following tasks:

- Coordination,

- Conceptual and Preliminary Design,

- Building R&D Locations,

- Developing New Technology

- Building and Testing Prototypes

- Designing Location and Node Details

• Phase 1 - Build DPN Nodes and Locations

A location is owned by network members, and may contain separately owned distinct nodes within it. Examples of a location include an industrial park, office building, or data center. Each of these can contain leased or privately owned space. Individuals and businesses can also operate free-standing nodes outside a location. Thus a home workshop or vehicle can participate in the network as a node, but need not be distinctly owned as a location.

The network as a whole needs coordination - things like tracking who is participating and what capabilities they offer, and distributing membership and start-up information. The coordination itself can of course also be a distributed task, such as via a forum, wiki, or peer-to-peer network. The following sub-phases can be added/built in parallel on an ad-hoc basis as upgrades:

- Phase 1A - Add Conventional Nodes and Locations: This is adding existing elements, or building new elements using conventional methods.

- Phase 1B - Add Data Transport: This adds network communications to automate member announcements, work requests, etc. The actual work is still via conventional methods.