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 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.