The ideas presented are related to these themes:
In my original presentation, I put forth the idea that selling kits might help with certain regulatory restrictions. I am now going to retract that idea as being unhelpful and potentially troublesome. There is no guarantee that just selling something as a kit will help with regulatory restrictions or the need for certification. In all cases regarding regulatory conformance and certification, the appropriate resources should be consulted to make sure your products are compliant with local and international law. Here is an Adafruit forum post that provides some discussion on this topic.Sparkfun Electronics operates so that if a product, or group of products, under-performs or loses revenue due to being cloned, the rest of the product lineup can absorb the loss. The hope (in relation to this discussion) is that this also helps offset the tendency to chase the most lucrative products. Some products can and should be created simply because they should exist, and not necessarily because they are very profitable.
The disadvantage of this approach is that as more products are offered, the overhead a company has in terms of production and support increases. Sparkfun Electronics employs hundreds of people who help spread the load of a large product line, but this could quickly become unsustainable for a small developer if the product line is expanded faster than the available labor resources can support.take advantage of the situation though, and in some cases will even illegally use the trademark/brand of the original developer in an attempt to trade on their good name, and maybe even to shift the support load for their cloned products onto the original developer. However, as long as third parties act in good faith and respect trademarks and branding, cloning can actually be a feature and not a bug. The reason this is true is because when developing products for the common good such as assistive technology, open science hardware, and appropriate technology, cloning provides a type of distributed manufacturing. Whereas the original developer may not have the production capacity to serve all demand for a product, cloning spreads that load out among multiple manufacturers, with the disadvantage that quality assurance is not centralized.
Cloning can also allow open hardware products to reach regions where the original developer may not be able to do business due to laws within their native country. In this case, the third party cloner supplies the demand of the unserved region. This is not a way to get around export restrictions on technologies though. Export restrictions will likely still apply to any distribution of restricted technologies. The appropriate resources should always be consulted to ensure compliance with local and international laws.spend 20% of their time working on projects that they think might benefit Google's mission, regardless of concerns like revenue potential. Whether or not this rule is used and enforced at Google is less important than the implications of having such a rule. Implementing this rule for an open hardware company that is working in areas like open science, might help offset the tendency to chase the most profitable products at the expense of worthy projects which are less profitable. Employees should ideally have some freedom to collaborate with practitioners and work on side projects, without having to always chase market trends and bottom lines.
The Developer-Practitioner loop, and all of the related revenue streams, are summarized in the following graphic. We will walk through it, step by step, in the rest of this section.
Ideas, represented by a light bulb, flow in both directions, where-as revenue (dollar sign icon) only flows from the developer to the practitioner. This is because it is assumed that the developer is the interface with the market, offering the products developed for sale and collecting sales revenue. This is not a requirement since the practitioner could have the skills and connections to be the interface with the market, but for the most part it is assumed that the practitioner wants to focus on their work and not on market concerns.
Platforms such as Patreon and LiberaPay provide a relatively easy way for community members to participate financially in a developer or practitioner's work. Practitioners, such as researchers, do not seem to be taking advantage of this type of crowdfunding very much, but in the interest of revenue diversification it is a resource that should at least be considered. Another effect of community involvement is that some community members end up contributing and injecting ideas into the developer-practitioner loop, which can lead to a better product.
There is nothing in this revenue sharing model that excludes practitioners from pursuing other funding. However, with revenue sharing, it is hoped that sources like grants can become a source, and not the source of revenue. It is not known whether universities and other entities that employ practitioners will have policies against this approach of pursuing other revenue sources.automated governance system into the loop, will hopefully help ensure trust, transparency and accountability between practitioners and developers.
A model that is a little closer to what may be needed is something like the Slicing Pie model that is used in the realm of start-up companies. A simplified explanation is that the Slicing Pie method assigns standard units to each person's contributions within a start-up company. Those contributions can take many forms including capital, facilities, clients, equipment and expertise. When a start-up company is sold, or has an initial stock offering, each person's contributions are divided by the total contributions made by all founders to decide what portion of the sale/stocks the individual founder gets. While this is in the same vein as the model that may be needed for sharing open hardware revenue, it is still designed for the world of start-up companies and is not a fit for our purposes here.Free Innovation by Eric von Hippel (chapter 3), an equation is defined to capture the value of a product that is created via free innovation. The base equation is defined this way, where the subscript i denotes the innovation:
valuei = design_costi + communication_costi + production_costi + transaction_costi
It is noted in the Free Innovation text that due to the Internet, communication costs have greatly decreased in the last decades. This is especially true of open hardware, with design source materials that are usually exclusively stored and distributed online.
When developers and practitioners are working together, it is expected that there will be field testing that needs to happen, and this can be a significant cost. Field testing costs could be combined with design costs, but in many cases design and testing may be handled separately between the developer and practitioner. Adding this factor in, the von Hippel equation becomes:
valuei = design_costi + communication_costi + production_costi + transaction_costi + testing_costi
Technical support for a product is something that also needs to be taken into account, and this cost is something that largely happens after a product has gone to market and starts to be sold. However, it is difficult to predict support costs, and getting this value wrong can make the project less profitable for the developer or needlessly pull revenue away from the practitioner. The developer must also not inflate this value higher than it should be to "pad their margins".
Please Note: The rest of this section is even more highly speculative, and would greatly benefit from feedback from the community. More research certainly needs to be done on this topic of predicting support costs in the context of open hardware products.
One option is that the developer has the understanding that technical support for a product is just their responsibility, and they have to hope that the revenue from the entirety of product sales offsets any support costs. However, if a developer is small and with only a few products, or there is a disproportionately large project with high support costs, those costs may end up being unsustainable. The system needs to be sustainable for both the developer and the practitioner so that they can continue building products that solve problems in the future.
What is suggested here for discussion, is to select a support multiplication factor based on the complexity of the product and its likelihood to need technical support. A range of 0.0 to 1.0 could work as a simple approximation of complexity, although it may very well be that scale is wrong. This multiplication factor could be used with either the design or production costs, using either of those values as an approximation of the complexity of the product. Using the production cost, the von Hippel equation would become:
valuei = design_costi + communication_costi + production_costi + transaction_costi + testing_costi + (support_multiplier * production_costi)
As an example, a 3D printed kit product with no electronics, and that requires minimal assembly, could be a 0.0 or 0.1 on the scale. A zero specifies that either the developer is not offering support for a product, or that the support costs will be so minimal as to be non-existent. This effectively drops the support cost out of the modified von Hippel equation.
Another example is a 3-axis pipetting robot with custom printed circuit boards. Robots can be difficult to debug and support, and having custom circuit boards adds to the complexity, and it is assumed, the support costs.
Time, discussion and experimentation will prove if the resulting equation, and this support multiplication factor, are effective measures of value contributed to a project. It is likely that the equation is missing other factors that contribute value to a project as well. More research certainly needs to be done, and there needs to be much more discussion on this topic.join the open hardware research community mailing list, introduce yourself, and add your thoughts.