6.0 - The MakerNet

The previous example, 5.0 Personal Production considered a project for a single location which makes products for home and hobby use. For this example we consider a network of people and equipment at different locations, who help each other make things, which we call a MakerNet. The network can expand in two ways. Each location can self-expand as in the previous example. In addition, locations can collaborate on building items for new locations. As in all our examples, the locations and network as a whole use part of their output for expansion, and the rest for end products for users.

Concept Summary

We will start with a summary of the purposes and main features of the project. Later sections and pages will develop more detail on how such a network is designed and built.

• Purposes - The main purpose of the MakerNet, like all our seed factory examples, is to supply products and services that people need and want. In this example we don't limit the community to a single geographical location. The people and equipment that make up the network help each other make things. Moving people and heavy items across long distances takes time and energy, so the design emphasizes sharing information and working remotely by means of the Internet. Long distance transport between locations is still used when it makes sense.

An end goal for the project is for the equipment to be mostly automated, but people can start with whatever skills and tools they have, or even none. Through self-learning and teaching each other, network members improve their skills. They also help each other acquire and upgrade sets of tools and equipment. Another goal is to become self-supporting by the time society adopts mass use of robots and automation. Conventional jobs are likely to become scarce by then. A community would then need the skills and tools to make their own products, and even their own robots, to support themselves. Until that time, members can trade work and goods on a less than full time basis, for hobbies, home improvement, and extra income.

• Features - Whatever starting point the project begins with, the evolution is directed towards a network of mostly automated production systems. So if a product like a dining table is requested, instructions and design files are sent across the network to various sites. These sites then provide the lumber and hardware, fabricate the parts, transport them from place to place, and finally assemble the finished table at the destination. Payments or credits flow in the opposite direction as work is completed, and ideally all the steps would happen automatically. In reality, some work by people will probably be needed, either in person or by remote operations, but much less than for traditional production and sales.

End products, like a dining table, are not used in further production. A design feature of the network is the ability to bootstrap itself by using part of the production output. It expands by making additional equipment, using the same process as for end products. Stored instructions and design files are sent across the network, except the product is a new machine or tool to add to the network. The larger the network gets, and the more equipment it accumulates, the better it is able to expand itself. Meanwhile the range of end products also expands, to eventually include most of the basic goods and services people need, like food, shelter, utilities, and some desired optional items.

Some people may not be interested in operating production equipment themselves, but want the outputs they produce. In that case they can supply funds to buy starter equipment, land, materials, and other inputs. They then get a share of the outputs in return. A sufficient portfolio of such investments could eliminate the need for a conventional job. Working outside the network is always possible, to pay for extras that can't be made internally. If basic needs are covered by the network, such extra work would be optional, and can therefore be be chosen according to preference, instead of necessity.

Project Description

This section gives a more detailed description of the parts of the project.

Network Parts

A MakerNet consists of a set of nodes and the transport systems that connect them. A Node is a site that contains some set of design or production capabilities. It might be as simple as a single machine or independent designer, or as complex as a fully expanded factory. Nodes transfer physical items, energy, and data to each other according to agreed protocols, using one or more transport systems. They also interact with outside entities by already existing conventional methods. The data portion of transfers includes design information, production orders, and payments. We expect most data will be transferred via the Internet, because it is already built and well-developed. Ownership of nodes may be independent or by shared entities (associations, corporations, etc.)

A Cluster is a set of nodes that are physically close enough to effectively work together. As examples, they may be co-located in an industrial park, or within a single metropolitan area. The effective working distance will tend to vary inversely with the mass transferred between them and directly with the value of the transfers. So design nodes may work together from anywhere in the world, because design data is high value and zero mass. Gravel, on the other hand, is high mass and low value, so moving it between nodes will only be effective for short distances. Clusters may go by names like group, association, or cooperative to indicate they work together. Members of a cluster may optionally set preferences or priorities for transfers between themselves. The Network is the set of all nodes and clusters that share the same transfer protocols, plus the internal and external transport systems that do the deliveries. This allows them to communicate data, distribute work, and collaborate on making products, including new nodes to expand the network. Nodes may freely join or leave the network, although agreed work-in-progress and transfers should be completed before leaving.

Node and Transport Types

The nodes within a given network all share the same transfer protocols, but they can have widely varying contents and functions. Since a given node can evolve and expand over time and add new functions, it cannot be permanently placed in a discrete category. However, we can use descriptive names, like a metalworking or chemical processing node, to help understand how the network operates. Such descriptive names for nodes are not necessary when we treat the design and protocols in the abstract. We can also describe node types with some loosely defined categories. A "specialty" node only performs one or a few related tasks, while a "general purpose" node can perform a wide variety of them. Examples of specialty nodes include design nodes, mining nodes, and power nodes. General purpose nodes that output a variety of end-products can be described as "starter", "expanding", or "industrial" scale. Ones with fewer output types can be described as "workshops", such as a woodworking shop. "Commercial" nodes would mostly make products for sale, while "private" ones mostly make items for personal or internal use.

The transport systems that connect nodes can also be described by categories. Internal systems are owned by network members, for example delivery trucks. External systems are owned by outside entities, such as an Internet Service Provider or a public road. Transfers can also be logically distinguished as between network members or between members and outside sites. However, the same transport systems can be used for both types of destinations, with perhaps the exception of not using the network protocols for outside deliveries. Functionally the transport systems are described by the type of entity being delivered. Our reference architecture for self-expanding systems currently includes Bulk Cargo, Discrete Cargo, Humans, Energy, Fluids and Gases, and Data. Both nodes and transfer systems can be described by how they operate. For example, they can be described as manual, remotely operated, or automated.

Operations Concept

An Operations Concept describes how the network would operate once built. At present the concept is only a starting point for further analysis and design. Our network operations concept follows a communicate, agree, and execute sequence. This is similar to how traditional business has operated with advertising, quotations, contracts, production, delivery, and payments. The difference is a fully developed network can use the protocols, production nodes, and transport systems to automate the steps.

In concept, node and transport systems advertise their capabilities and costs in a standardized format via a network protocol. This could be done on a distributed peer-to-peer network or as data supplied by a website, but the specific method can be left for later. The capabilities information would include equipment capacities, production location, cost, schedule, and other relevant data. Another node, or an outside customer, who need something made or supplied, can search the network for suitable capabilities. They can then send requests for information or requests for quotes for custom work, or place an order if it is a standard item. The receiving node then accepts the order, places it on their production schedule, and communicates progress from time to time. In an early development stage of the network some of the steps may be manual. In a fully developed version they may be entirely automated.

Design files for a product would contain enough information to build it. This includes required materials, parts sources, quantities, fabrication processes, shapes of the parts, assembly instructions, etc. The format for design files would be standardized, so that they can be matched to node capabilities. More detailed steps for the network operation starts with a user, either from outside or part of the network, who wants a product made. We will use as an example a dining table for home use. The user reviews available designs on the network, or if they want something custom, the capabilities of design nodes. Once they have chosen a final design, their local ordering software can compare the product's requirements to the available advertised capabilities for production and transport. The software can generate a rank-ordered list of nodes or clusters which can deliver the completed item. The customer can review these candidates, contact them for additional information, or simply go ahead and submit the order. The orders would include reference to the design files that specify what is to be built, delivery instructions, and proof of available payment. The node that gets the initial order, in turn sends out orders to suppliers as needed. For example, a woodworking node that completes the dining table may send out orders for lumber and hardware. For complex items, a single original order may generate a chain of additional orders through the network and from outside suppliers. A large commercial node may be able to complete the entire product, while small individual nodes may need to split the work between them. One node might supply lumber of the correct sizes, another uses a table saw and other woodworking tools to shape the parts, a third does the finishing and assembly, and a fourth delivers the finished product. The order generation and delivery of the design files may be entirely automated once the customer authorizes it.

In order to pay for the various production tasks, the person making the order places sufficient funds in escrow on an electronic payment network. This could be via conventional financial systems like bank accounts and credit cards, or new programmable ones like Bitcoin. Programmable networks have features that allow automating the payment of multiple suppliers. Transaction records are public in the this type of network, so the node operators can see the funds have been placed in escrow. The escrow guarantees the funds are available, but they are not delivered until the work is complete. When a node completes their work, and delivers their items to the next node, or to the end customer, the escrow is notified to release their portion of the funds to pay them. This step may also optionally be manual or automated. Because transaction records are public, nodes can prove they completed the work and were paid. If order data are also a matter of public record, the combination of order and completion history can serve as a reputation measure for nodes. This can be used by future customers to help select nodes for new work. A reputation system is an optional feature for this kind of distributed production, but it may be useful.

Network Creation and Growth

We do not expect such a network can be designed and built all at once. Instead, we can start from existing non-networked businesses and entities who agree to work together. They do not have to devote all of their work to the network, but can allow it to be added incrementally. The first step beyond just associating with each other and manually sharing data is for one or more design nodes to develop the transfer protocols, and then supporting software to handle purely electronic transfers such as design data and payments. At this level the actual work to satisfy single orders can still be by whatever conventional means they already use. The next step is creating product designs with sufficient information to distribute tasks across multiple nodes, and optimized for production within the growing network. Orders then can start to be issued in parallel from the originator or as a chain where one node generates sub-tasks for other nodes. Along with the new designs, nodes can begin to automate their internal operations and deliveries to increase efficiency and lower costs.

The network is intended to operate and grow on an ad-hoc basis in a distributed fashion, rather than a centralized top-down design. However, network members can collaborate on improved designs and protocol updates. New nodes can establish themselves by posting their capabilities to the network, and can change or remove that data at any time. They may start out with purely manual operations, and only download network software to communicate capabilities and orders. Some of the products that individuals can order are intended to be new production elements, which allows them to expand and automate their capabilities. So the network can self-expand by adding new nodes, new product designs, and internal production of more elements. As the network grows, it can become more automated, and produce a wider range of needed items internally. A fully built network could supply the majority of it's own inputs and outputs.

Potential Benefits

It will take work to design, build, and operate a MakerNet type of distributed production network. There have to be enough advantages in having such a network to justify its creation. At this point in developing the concept we cannot prove those advantages exist. We can, however, list potential benefits, and then investigate them further as the concept evolves:

• Individuals can join the network with minimal capabilities at first, but gain the benefits of the rest of the network immediately. It may lower the barrier to entry compared to conventional business start ups.
• There may be social and financial benefits for people who regularly work with each other and build up skills and reputations.
• The extent and rate of automated self-expansion can produce high rates of capital growth.
• To the extent the ordering, payment, and production tasks are automated, it would have low overhead and high productivity.
• Routing of individual tasks to the nearest/fastest/cheapest nodes for each customer may be more efficient than centralized production at a single location.
• Filling orders for a wide range of customers may optimize and stabilize production schedules, and automatic reassignment of tasks to other nodes may better handle delays or breakdowns.
• Enhanced privacy is possible if the orders and payments are only identified by account numbers, and the final delivery is a closed container. The shipper only needs to know the destination, but not what is being shipped or the price.
• Ownership and leasing strategies may be automated, so that at any time people are working for themselves (with automated equipment). This may have tax advantages.

Design Process

Having described the general concept, we now turn to how such a system can be designed. This section is very preliminary for now. This wikibook as a whole is about self-expanding production systems. We presented a common Reference Architecture in section 3.4, and a systems engineering-based design process in section 4.0. We adopt these as starting points for this particular example of a distributed network. Like other self-expanding systems, a distributed network is complex, so we plan the growth in phases, and divide the whole project into smaller elements to simplify the design tasks. In this case, the starting point is existing skills, tools, and equipment, and business processes as they are now. The early phases add network communication and payment software, and more conventional equipment to support new production tasks. Once network members are ordering parts and products from each other, they can start to design custom hardware and setting up production nodes.

Distributed Features

Because it is distributed, this example will place more emphasis on the transport functions and elements which connect locations. Historically factories and offices were centralized because it was the less expensive solution. Modern communication and transportation equipment have lowered those costs, so more distributed solutions are feasible now. Other factors like reduced commuting time and energy use for shipping can come into play with locally distributed production. It is still useful for design and optimization purposes, however, to treat a set of production equipment as an integrated entity, despite the pieces being physically separated and under different ownership. Even if the elements are widely distributed, it makes sense for operating efficiency to design them to work together and use standardized interfaces and protocols. There are existing examples of such distributed systems, such as the Internet itself, and the traffic control network for airplanes. There will still be advantages to grouping things together physically, but we treat it as a design choice based on circumstances, rather than a default assumption. Other factors like availability of start-up funding and staff may drive a more distributed solution.

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.