Can You Sell Open Source Hardware

Are you an Open Source Hardware designer, developing fun and useful projects with Open Source Hardware? Do you develop Open Source Hardware for others to use and improve? If so, or even if you are just curious about the topic, this is the symposium for you. Bring your questions, ideas and components to share, and we’ll discuss how companies can sell products based upon Open Source Hardware.

It’s a tough journey for open source hardware companies. What are the paths forward? We’ll share experience from our work at Chumby, SparkFun, and Pachube. We’ll also look at the challenges of open source hardware startups, including intellectual property and funding. The panelists are experienced with funding, intellectual property, manufacturing (even injection molding), embedded software, and international shipping.

Designing & Selling Your Own Product

Of course, the first way to make money that I have to mention is to create your own product. Which means designing a product, manufacturing it in a factory and selling it to your audience. First, let me talk about the the typical argument against that way to make money. Because it’s all open-source, there is a chance that people will just take the design files from your website and make the product themselves. Or worse, some other guys living in countries where manufacturing is cheaper will just steal your design files and produce & sell your own product, but for much cheaper.

This is a valid argument, but in practice it doesn’t happen that much. Most of your audience don’t want to build the product themselves, especially if it’s a complicated one to build. Sure, they will use the files that are available for free to get insights on your product. They might make minor modifications, or use it as a base for another product. But only a few of them will build it from your design files. Also, even if another manufacturer is building your product for much cheaper, it will usually be at the expense of quality. And that will only help to build your own brand, according to DIY Drone’s CEO Chris Anderson in his book Makers: The New Industrial Revolution.

Back to the product creation, you will find a lot of articles and resources on this website to design, build and market your own product. Yet, even if it is the most straightforward way to make money with an open-source hardware business, it is also the most difficult way if you are a beginner. It usually requires a lot of efforts and investments before you have anything to sell, even if crowd funding platforms can help a lot on the last point. This is why I also advice to look first at other ways to make money if it is your first business.

The open source product model

One of my favorite reference points for building a business on open source software is Red Hat, and how they built out a model for commercial solutions that sell, while still supporting the upstream communities that sustain the technology innovation. As a long-time proponent of this model, I’m happy to report that it is gaining traction elsewhere. There is a misunderstanding that goes way back about this particular model that it is a support and services business, which is simply not true. Selling subscription licenses for software products is functionally the same, regardless of the origin of the source code, whether it is proprietary, open source, or otherwise. The reason that so many misunderstand this model is that they overvalue source code and mistake it for a product. In this reading, anyone selling a solution built solely with open source software must be selling support, because why would anyone pay for what they can obtain for free? As Red Hat and others have demonstrated, customers will pay for solutions that save them time, regardless of the origins of the technology.

Let’s imagine a potential customer that looks at an open source product, scoffs, and decides they’re going to build their own version. In truth, there are a number of options:

  • Use the same open source components to assemble a distribution resembling the product (a functionally similar solution, but not a byte-for-byte reproduction)
  • Use the same source code as the product and simply rebuild/respin it yourself (a fork)
  • Use a similar distribution from a competitor, sometimes also available for free

You may look at the list and think, why on earth would someone buy from a vendor of open source with all of these free alternatives available? It turns out there’s a lot that goes into building a successful product that doesn’t involve source code. There’s the management of several instances and their automated, scalable upgrades. There are network services that feed into this management, making use of aggregated data from across the customer base. There’s patent and license indemnification. There’s HIPPA, PCI, and other compliance. There’s a promise to resolve issues within an allotted time, as well as subject matter experts to consult, many of whom built the software you’re using. The key finding from this model is that source code often doesn’t matter to the customer. Customers care about saving time and effort, and if your solution does that, they will buy it. In the end, Glyptodon decided to emulate this model, making Apache Guacamole the upstream community, and Glyptodon Enterprise the downstream product.

Creating Accessories for Other Products

Instead of making your own product starting from zero, another way is to build accessories or add-ons for already existing products. The most common example would be Arduino shields, which are add-ons boards for the Arduino platform that add functionalities to Arduino projects.

Even if it also involves design & manufacturing, as for the creation of your own product from scratch, this way of generating money is much simpler for several reasons. First, the product that you aim to create is generally much simpler to design than creating your own product. Wether it is a 3D-printed case for a BeagleBone Black or an Arduino shield, it limits the number of components and design efforts.

You are also guided by the products you are creating accessories for. Again, creating a shield for the Arduino platform requires that you follow the specifications of the Arduino board in terms of size & IO pins. Manufacturing is also easier for the same reasons: usually manufacturers are used to produce Arduino shields for example. Finally, and the most important, marketing & sales are also so much easier when it comes to accessories & add-ons. You are creating a product for an already proven market, so you don’t have all the hassle to create an audience in a completely new market.

Create a commercial product

One of the key decisions to make in this process is where the open source project begins and ends, and where the commercial product picks up.

What are the differentiating factors? One of the findings from the Fedora-to-RHEL model is that branding and identity are important to both parts. The Fedora community must feel ownership of its identity, and paying customers must feel some affinity to the RHEL brand.

The bottom line is—the open source community, when it works well, provides the innovative force that sustains product development. Some companies decide that they will develop proprietary pieces of their commercial product not available to the upstream community. Other companies add further restrictions to their upstream community, essentially enforcing that all innovation comes from the downstream product development group. In the case of Glyptodon, they looked at four different models. All of these are valid, but there are tradeoffs to each.

  1. Open Source upstream community, proprietary downstream product—This is the model chosen by a number of companies, including Confluent, Databrix, Cloudera, and a host of others. The basic idea is to build a commercial proprietary product on a successful open source platform, usually with a viable community in its own right, separate from any commercial effort. This has become an especially popular model for data analytics solutions companies, who are able to differentiate products based on the management control plane. The core data analytics technologies are freely available and open source, while the management control plane software is only available at a cost. The downside is that it’s difficult to build a user community around the downstream product, although that doesn’t matter as much for certain industry segments.
  2. Limited upstream open source community, proprietary downstream product—This was the most popular model back when the first commercial open source companies received attention from investors. The model was simple: put out a limited version of the commercial product under an open source license and try to upsell on the proprietary features only available in the commercial version. The result is that the parent company is ultimately responsible for sustaining product development, and there’s very little lift from an outside community. The communities in these cases never develop an identity outside of the parent company, limiting their growth and value to the parent company. This is a viable model in cases where the technology is more end-user app-focused. For these businesses, the tradeoff is worth it if what you’re trying to build is mass adoption of a freemium product that you offer premium services for down the road. In cases where you require more input on product development, as is the case for many infrastructure solutions, this hasn’t proved to be a suitable model.
  3. Upstream open source community, downstream licensed product built with open source software—This is the Red Hat model, and it’s been proven to work well for others, too. For vendors who sell infrastructure solutions, there are some advantages. By developing and devoting resources to the upstream community, you help to ensure that your technology is used by a large number of people, many of whom are highly skilled admins who need to employ solutions that will allow them to be more efficient. By making a downstream product that has the same feature set, you allow these admins to do much of your selling for you, without having to explain why features are in one version but not the other. The downside is that the prospective customer can choose not to buy from you at all, but that gets us back to the original point about time vs. money. If you’re able to save them time and the headache of maintenance, they have a compelling reason to buy from you.
  4. Upstream open source community, downstream SaaS product—This is a relatively new model that is easier for some vendors (and customers) to grok than the idea of selling open source software. Take an open source community, make it successful, and then offer to run it as a service for customers who don’t want the headache of operating software themselves. There are tremendous benefits to this model: it’s easy to explain, there’s an obvious benefit to the customer, and you don’t have to worry so much about delineating between the user and customer communities. But there are downsides: by taking on the daily operations of customers, you need to have the internal expertise to efficiently and securely run these services for your customers. This can be quite challenging, especially if you’ve never run a SaaS business before. MongoDB, to use one example, has made great progress with this model recently.


These days, everything seems to be open source. From software to video games, to productivity suites and even hardware components. There’s no reason why your product can’t be as well.

Similar Posts


No Comment.