Ideas on Open Hardware Revenue Sharing

Author: Jeremy Wright
Published: 2022-10-13
Last Updated: Never
License: CC BY-SA 2.0
Previous Post: None

Abstract

A business model for selling open hardware to generate revenue is presented, along with a collaborative loop between developers and practitioners to share ideas and revenue. An equation is presented which might help quantify each party's contributions to the end product, thus enabling a dynamic revenue split. This equation can be encoded into software or in a shared, collaboratively edited spreadsheet. This allows each party to enter their contributions, and be made aware of the current revenue split in real-time. The end goal of all this effort is to provide developers and practitioners with an alternate revenue stream, hopefully reducing the dependence on other forms of funding such as grants.

Prologue

This blog post is a companion to a presentation I gave to the open hardware research community. You can view a re-recording of the presentation here, and the slides are available in odp and pdf formats. However, the video recording and slides are already outdated because of feedback from the community and additional research that has been conducted. This blog post will be the central source of updated information moving forward as additional discussion and research is done on this topic. To join the discussion, please join the open hardware research mailing list.

1. Definitions

Throughout this blog post two terms will be frequently used: developers and practitioners. Here are definitions for each term:

• Developers - Hardware and software developers, which could be for-profit, non-profit, cooperative, etc. For the purposes of this discussion, the developer is the interface with the market, selling the products and collecting revenue.
• Practitioners - People in the field doing the work, such as researchers, occupational therapists, etc. Holders of the domain knowledge and experience. The practitioner often has a need for the product being developed with the developer.

2. Introduction

This post and the corresponding presentation are meant to serve as a starting point for discussion, and not to present a final, authoritative method. They are also not business or legal advice, they are ideas to be explored by the community.

The ideas presented are related to these themes:

• Open hardware income generation
• Creating a positive loop between practitioners and developers
• Revenue sharing to reduce practitioner dependence on other funding sources (i.e. grants)

The overarching goal is to free up hardware developers and practitioners to work on the projects and problems they think are most valuable and interesting, regardless of whether or not mainstream funding is available. This, of course, also needs to be done in a sustainable way.

3. Revenue Generation

This section covers an operational model which is designed to be a foundation that a revenue/idea sharing loop between a developer and practitioner can be built upon. Where possible, precedents are included to show where these methods have worked before. Emerging business models for open source hardware by Joshua Pearce covers some of what is discussed here in better detail, and expands on several other business models that may be of interest in this context.

3.1 Kit Sales

Offering kits for sale rather than finished products can provide multiple advantages to a developer. The first and most obvious advantage is that it can save the developer the cost of assembling a product before shipping. This shifts the time spent doing assembly onto the end consumer, with the disadvantage being that some consumers will refuse to purchase products that are not ready to go out of the box. Selling kits encourages consumers to understand the product better, rather than treating it like a "black box". Once a consumer has assembled their product from a kit, they are much better prepared to repair and modify it later on. This can even lead to some consumers becoming community members who suggest modifications and improvements to existing designs. For an example of a company that has an effective kit-based product line, see Adafruit Industries, and also refer to Pearce, Section 4.1.1.

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.

3.2 Continuous Innovation

The phrase continuous innovation in this context means that new products are always in development, and there is no single product that the developer relies on for their revenue. This is how 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.

3.3 Cloning is a Feature, Not a Bug

Cloning of open hardware is where a third party makes and sells a design on their own, separate from the original developer. Under most circumstances this is normal and to be expected. Some third parties will 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.

3.4 The 20% (or More) Rule

Google famously encourages their employees to 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.

4. Developer-Practitioner Feedback Loop

This section is an attempt to document the flow of ideas and revenue between developers and practitioners, and to envision a positive feedback loop between the two.

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.

4.1 Core of the Loop

The core of the developer-practitioner loop is, unsurprisingly, formed by connections between the developer and the practitioner.

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.

4.2 Donations

It is also possible for both the developer and practitioner to solicit donations from a community, as a commons-funded way to facilitate their work.

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.

4.3 Traditional Funding Sources

It is also expected that practitioners will continue to pursue more traditional funding avenues, such as grants, to help facilitate their work.

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.

4.4 Trust, Transparency and Accountability

There is one more thing to note before moving on. This loop involves the exchange of ideas and money, and so trust, transparency and accountability are essential to the process. The method of determining the revenue split presented next, along with some ideas on how to add a sort of automated governance system into the loop, will hopefully help ensure trust, transparency and accountability between practitioners and developers.

5. Revenue Sharing Model

Now that the loop between developers and practitioners has been defined, there has to be a mechanism in place to ensure that this idea and revenue sharing is done in an fair, effective and sustainable way. This section lays out a possible method by which revenue share can be determined.

5.1 Mainstream Models

A static percentage is often defined when doing revenue sharing, such as in a royalty payment scheme. An example would be that a practitioner gets a 5% share of all revenue generated by a product that they helped develop. It can even take the form of something more generous, such as a 50-50 split, where revenue is split in half between the developer and practitioner. However, static revenue splits do not take into account the relative effort and at-risk contributions made by the developer and the practitioner. If a practitioner spends several months in the field testing and making improvements to a product, which was a large proportion of the total effort that went into the product, you would expect the practitioner to get a larger portion of the revenue. The inverse also applies, as when a developer puts a lot of resources into designing, manufacturing and marketing, versus a smaller contribution by the practitioner. What may be needed in a self-sustaining model is an effort-based determination method which fairly distributes the generated revenue.

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.

5.2 The von Hippel Equation

In the book 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:

value_i = design_cost_i + communication_cost_i + production_cost_i + transaction_cost_i

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.

5.3 von Hippel Modifications

In this section, a few modifications to the von Hippel equation will be suggested to move it from being an equation describing Free Innovation, to an equation that can be better used to determine revenue sharing percentages in the open hardware industry.

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:

value_i = design_cost_i + communication_cost_i + production_cost_i + transaction_cost_i + testing_cost_i

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:

value_i = design_cost_i + communication_cost_i + production_cost_i + transaction_cost_i + testing_cost_i + (support_multiplier * production_cost_i)

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.

5.4 Using the Equation

The process of using the equation starts with each party understanding and agreeing to the equation and its modifications, such as the technical support multiplier. This helps to increase the amount of trust and transparency in the project. The equation can then be encoded into tracking software, which could be as simple as a shared Google spreadsheet or an open source equivalent. The purpose of this software or spreadsheet is to allow each party to enter their contributions, such as time spent, cost of parts, and travel costs. The spreadsheet can then calculate each party's contribution compared to the whole, giving a real-time revenue sharing percentage. Doing so adds accountability to the system as well, since each party can see what the other is contributing, and whether or not they seem to be holding up their side of the project.

5.5 Income Lag

One aspect of this that is probably intuitive but is worth addressing, is the fact that income will lag the investment made by both the developer and practitioner. It takes time to develop a product and get it to market, and then time for a product to be adopted by the market, if it ever is. Some products just do not sell well (or at all) for various reasons. In any case, product revenue will lag the initial investment of time and material, so it is not of immediate financial benefit to the practitioner or developer. However, a practitioner may end up with a working product to aid them in their research much sooner, which could lead to grant and donation opportunities. Also (it is hoped) as time progresses, and both the developer and practitioner have brought more collaboratively developed products to market, that the revenue generated will be a significant additional revenue stream. This could be important in the future if other funding sources such as grants and donations are unavailable or are insufficiently available.

6. This is Just the Beginning

As stated throughout this post, these ideas are put forth to spark discussion. The goal is for this blog post to evolve over time as more information and ideas come to light. If you would like to join the discussion on this topic, please join the open hardware research community mailing list, introduce yourself, and add your thoughts.

Update History

None