These days I’m thinking a lot about what’s the meaning in choosing to develop something in open source. Especially in Hardware.

Lately, we have witnessed the Open Source development model permeate more and more sectors and product proposition: it’s absolutely not rare to see hardware products releasing all the designs online and, as you probably know, we created, launched and distributed worldwide (thanks to an amazing partner like Velleman) a fully open source product: did you know that you can find out everything about 3Drag on the Rep Rap Wiki? Well, our beloved 3Drag/K8200 3D printer, that – according to our evidence – is the second best selling 3D printing machine in the world was a good trial for us.

If we look to our products history, as it was for the printer it is with most of the boards we produce, we basically inherited a “framework” that was open source and – just because it was – we had chances to build more products on top of that. Rep Rap knowledge base and bubbling community was the enabler that actually allowed us to create the 3Drag, and most of our boards are dedicated to Arduino, another pillar of the Open Source Hardware economy.

These two contexts are pretty different though: while RepRap is substantially a community (even if RepRapPro – also empowered by the project founder, Adrian Bowyer that we recently interviewed – builds products) the latter, Arduino, is a successful and sustainable business venture also increasingly recognized as a Brand – with all the intangible value that comes from that.

The cost of being Open Source

If we look at the choice from a mere market-wise point of view, going for Open Source tends to be a scarcely appealing perspective for a business: if you want to start a new product – say a boat, a lamp, a drone – and make it an open source platform, you basically agree to cover some initial investments and operational costs.

Explicit costs, very easily identifiable capital expenditures, simply relate to the cost of starting up a “shareable” piece of work. The typical approach of those creating new open source – with the idea to release it in the Open – is to create some sort of 1.0 release to start from: well, developing such an artifact typically requires money.

Furthermore, implicit costs are often ignored: once you release a project and you commit to openness people will start looking into it and as soon as they put your hands on that, they start doing something very common: they ask questions. And, do you know what questions they ask more? They ask about how to get involved. Following up with these users, coordinating, envisioning the ways and channels to let them express their value towards the platform is not a simple, neither cheap task as it takes a lot of time and work.

Since it’s not going to be a walk in the park, it’s to consider: why am I doing this?











Why Open Source? The user perspective

From the point of view of the user, Open Source is a pretty neat concept, with evident often mostly theoretical, advantages. I prefer open source – both in software and hardware – as a user because I like the overall idea: it’s transparent, I can have a look inside and if I don’t , as I typically don’t , I’m sure someone else will do and spot design errors or even tricky and questionable choices: no developer adds a backdoor in an open source project. This may seems scarcely interesting for an electronic board but it’s definitely going to be important if tomorrow I buy a medical device, maybe a prosthesis or implant.

If I’m lucky enough to have access to the right means, I can re-create the project: this is pretty straightforward with software as means are cheap and software is basically self-described by the code (see other parallels between open source software and open source hardware here in this post we published already). With hardware is totally different: building a car from the designs will involve capital (access to means of production, supplies, knowledgeable personnel) given for granted that you’ve access to all the relevant documentation and fine tuned manufacturing data that may also depend on your particular context (and therefore not be unique).

Despite the vision of an active, involved, knowledgeable and potentially conscious users is tempting, those kind of users, the ones that are able to access information and replicate the project in a DIY manner, the ones that we would have called “developers” if we were talking only about software, are very rare and have a very specific role in every open source business: those are the ones supposed to help the platform itself grow, adapt and transform. That’s why open source (and not Free Software) was born as a product development approach: as you can’t access every talent in the world, you open your code so that they can access it.

In this process of adoption of open source in hardware we should make a reflection on how this role, that of the independent project developer and contributor, is supposed to change. As open source hardware has higher costs embedded (as we previously explained), what we are seeing and we can expect more and more is that we switch from a lone developer figure (often too lone :D) to groups and teams of “makers” often focused on starting up a business out of their hacking attempts and often attached to the availability of a dedicated meeting and collaboration space, the so called “makerspace” (or Fablab, Techshop and whatever it is) that is growing an important role in such an ecosystem and it’s often forgiven by open source project leaders that fail to identify a role for such a “collective” player.

Why Open Source? The producer perspective

Apart from the user perspective, it’s now interesting to see the producer’s point of view in choosing Open Source. As I already had the chance to highlight on this blog, Open Source today is no more and no less than a critical strategic move.

When you create an open source project with a relevant industrial vision behind – and so to be considered a credible alternative to proprietary platforms – you can do few key things that others cannot do. First of all, you get a First Mover advantage (assumed no one moved on that market already with an open source proposition backed by a credible company and a strategic vision) and this can be critical in open source. Let me explain better: ideally, there’s no need to start a new open source enabling platform when there’s already one. That’s why for example most of today’s web browsers are all based on WebKit. So to be more clear with hardware: that’s why people is not building another Arduino but, instead, they’re building compatible devices and upgrades. The cost-opportunity of creating something radically new becomes soon too high as soon as your “community of users” grows a bit. Yes, you can still fork an open project but again forking is normally seen as a radical choice and implies no less complexities in terms of loosing access to the ecosystem of contributions and additional modules.

Secondly you can decide what’s open source and what’s not. This is no negligible advantage as you’ve the possibility to design your additional revenue streams and craft your business model to work in top of additional packages, modules, subscriptions. Third point, and that’s how things start to become complicated: you become an enabler for your own competition. Ideally indeed, an open source platform success can be measured by the number of businesses entities it empowers. By being “easy to copy” and by allowing competitors to even try to copy your product tout court you will likely end up in… not being copied, but instead will help the others focus on adding value: as long as your business proposition allows.

That’s the point: players on the markets compete for revenues and tend not to compete on “enabling infrastructures” since running an infrastructure is costly and requires efficiencies and strategic long term thinking an vision. In the case of “platforms” what you typically have is instead a limited form of “competition” between different platform/ecosystems (see Apple vs Android, non Samsung version of Android vs LG version of Android) that end up in having each one its share of a market, instead of having players competing to become the “enabling” platform of the same subset of the ecosystem.

So what to do?

The major problem we live today in the realm of open source hardware platforms is that we still lack some success stories – as we have in software on the other hand. Commercial brands that ended up creating a sustainable business model around an open source proposition in hardware still can be enumerated easily (especially those with bigger numbers) and it’s often a tough decision to take, given the constraints that we highlighted: creating an open source platform for hardware innovation can appear difficult on one hand (people tend to think “they will copy me” and tend to think it as a bad thing) and can appear pointless on the other hand, as good examples still need to unfold properly, even if we have promising firms doing really well.

The role of the successful designer of a product at today is that of understanding what an open source model of development means and how this must be complemented in parallel with several other considerations, mostly related with holistic design and business intuitions: if you really plan to make a business out of your product today you need to try create an ecosystem and community around it and craft your offering around a product-like-a-platform approach. That’s why I recently created a Toolkit that you can explore right here on my blog (The Platform Design Toolikit).

The specific traits I see, of a successful project of such a type, will be that of tapping into markets that are characterized by high entry barriers and try to lower it down by standing the initial amount of capital investment needed to create the starting point and the platform. Looking to enable economies of scope (diversity) where economies of scale (monolithic approaches) exist today and block new entrants can generate a huge growth as untapped, smaller, localized opportunities can be highly promising.

The key to a successful business these days, despite being open source or not, is indeed to point towards a multi-stakeholder approach, which tends to enable opportunities for each of the players that are part of the product ecosystem and generates more equitable opportunities for revenues, across all the chain: remember that open source will only be the channel toward developers and will likely grant you the platform innovation. Making a sustainable business is another story.

With the right vision and strategy you’ll be able to position your product as a de facto “market enabler” and – as long as you can craft a relevant number of other revenue streams around it, both for you and the other players expected to collaborate – you’ll be winning.

Photos courtesy of Johan Larsson, opensource.com