Business Models for Open Source (Hardware & Solutions)



Check out the new resource on this question especially made for OSCEdays - A Video Series + A Tool To Work With on: Open Source Business Models for Circular Economy.

First Video out of 9

##Some Resources on Open Source Business Models

"When it comes to Open Source the one of the first questions popping into peoples minds is 'How to make money with that?’ - indeed: ‘You can’t make money being open’ is a common criticism of Open Source. And while true in a few cases, in many cases it’s just the opposite. There are many opportunities to work better and more effectively through an open approach. Open Source is very often an ideal strategy for developing a more innovative, financially successful and sustainable business, where money can be made not DESPITE being open but in fact BECAUSE you are open.

But of course this isn’t a case of just changing a license and carrying on with business as usual – open strategies require certain adjustments to the a company’s business model – sometimes minor alterations, sometimes transformative change.

Only few adptions are needed when the core business remains almost untouched by the openness – a bakery, a glazier’s or carpentry workshop etc. – it is not a monopoly on information that sells the product but factors like quality of the craft, marketing, location etc. (…) But there are also areas where openness asks for fundamental changes to the business model. When you stop relying on “intellectual property“, trade secrets and intransparency, you must engage in other collaboration patterns and unlock other sources for financial income. There’s a growing number of companies and Business Models using the possibilities and potential of openness to optimise the production and sales of physical products." quote source (Open It Agency)

#Resources (Links)
On Business Models For Open Source Hardware

  1. Business Models for Open Source Hardware (Slideshow) by Benjamin Tinq

  2. 8 Ways to Make a Living with Open Source Hardware (by Mathilde Berchon/Making Society – Focused on Makers)

  3. Business Models for Open Source Software (Wikipedia)

There might be some challenges about this question! One is already there. More might come.


SOLUTION - (Videos & Tool on) Open Source Business Models for Circular Economy
OPEN SOURCE - Useful Explanations & Introductions

I think it is rather unhelpful to continuously reiterate that making money is “one of the first questions” specifically with open source anything. If you hit a market (a “customer pain” as the slang goes) you’re very likely to make money with any solution you propose as long as it is working. There is this marvellous misconception created by the more uninspiring management scholars that making money is intrinsically linked to strong IP (intellectual property) protection (like copyright, patenting, trademarks and stuff). IP protection does not create value, it destroys value by forbidding reuse of knowledge. It is from creating value that businesses make money, not from destroying value.

So the question we really need to ask is: what values does my open source thing create – and then we are indeed at the core of the business models: how do we “capture” these values and make customers buy. The business model then describes what we do, how we do it (inking factors of production and upstream and downstream markets) and in what way we govern internal and external activities in upstream and downstream markets (see: Zott, C. and Amit, R. (2010). Business Model Design: An Activity System Perspective. Long Range Planning, 49(2-3), pp. 216 - 226,


Really enjoyed this post and it’s very inspiring. I’m was just about to write down my thoughts and abandon it somewhere deep in my harddrive but why not share.

My Thought’s on Open Source and Business:

Patents require protection and like trox mentioned they are a way of destroying value but not letting others use it.
This ends up in different and competing standards and the best one doesn’t always win. This act generates more pollution than necessary.

It’s better to make a name for yourself not just based on the tech but on your values also. It’s always the nicest way to spend your money when you feel like you’re supporting the person/s behind the product.

I want to open source my hardware because I think you should be able to repair anything you buy.
I also think that others could greatly improve on my designs and through collective iterations we could come up with the most efficient and simple tech possible.

Creativity, imagination & inventing is a byproduct of our society, education and ultimately the global history of mankind, it’s floating around in the collective unconscious waiting for a humble or opportunistic host. I don’t mean to sound like a hippie or something but your spaceship design isn’t original because you’ve seen all the starwars and startrek movies and they influenced you. It’s our job to become the next link in the chain so that we can help each other.

  • I’m sorry I forget how to use commas.


We should also emphasise ‘how you can make money because of open source’ rather than engaging on the terms which most people unfamiliar with open source methodology tend to lead with - that is, ‘how can I make money despite being open source?’

A well-structured, well-stewarded open source project delivers the following benefits much more effectively than a traditional closed-source approach:

  • Cheap, effective, user-led research & development and communications for the project.
  • an active and engaged community, close to and invested in the success of the project.
  • solutions, experiments and use-cases that you and your company would never have thought of alone.
  • community-led bug reporting / fixing, and product development
  • collaboration and cost-sharing with individuals and other businesses involved in the project.
  • the opportunity to build upon existing commons solutions rather than building from scratch
  • an ethical boost for your brand (transparency, freedom and respect for the user!)
  • community-led expansion into different markets, through local adaptation, translation of materials etc.
  • the ability to scale a project with little available resources

these are just the first examples I thought of, there are more, but leading with these benefits helps get people out of the mindset that making something open source is a charitable act, applied with a copyright license to a finished product, by foolish people with no business sense.

Instead, open source should be seen as a development methodology which works best when applied early on in a project’s development, and when the project has been designed to facilitate collaboration and engagement.


In OSCEdays Berlin, we had 2 workshops with Veolia who were curious about the Open Source methodology and the potential to create very different projects and business models than they have had in the past.
Imagine Zero Rainwater Pollution
Imagine Zero Waste

@Justine asked @Lars2i and I for a summary of some of the business models which could be presented to their CEO to show the benefits of the open source approach. My short answer is 'build and share infrastructure with others, and sell unique services.'
For a more in-depth answer, both of us recommended the links Lars referred to in his first post in this topic:

I also want to add a few thoughts about the pros and cons of a large ‘traditional’ company like Veolia trying the open source approach. It’s a bit long, but Justine, feel free to edit as you like!

##Open Source for Veolia
Building or taking part in open source projects could reap sustainable, long-term benefits for large companies like Veolia. However, they need to be aware of the many differences with traditional product development and business models that exist in the open source world, and take the time to develop trust with their potential contributors and collaborators.

There are many financial and not-directly-financial benefits to an open source approach - for example:

  • Unexpected innovation: a diverse group of people who are encouraged to experiment, to solve their own problems and work with unlikely partners can produce a much wider range of developments, ideas and insights than one company could ever produce alone.

  • Lowered R&D costs: if multiple actors share common goals, or require a common tool to achieve different goals, the costs of developing the infrastructure of this common tool or solution can be shared amongst them. Normally activity would include a mixture of contributions to the core of the project, and also some specific customization for one’s own business or personal use case.

  • Ethical boost for the brand: If a company is working collaboratively with others, and sharing the benefits of a open source project, this will generally have a positive impact on the perception and reputation of that brand - especially if their project has a worthy goal (eg rainwater solutions/circular economy).

  • Adaptation to different/local markets: having a community of users and contributors in a variety of locations and situations means that projects are often adapted for local use, and are often designed for easy adaptation. Encouraging and keeping an eye on this process is a cheap, low-risk and effective way to test out different potential markets and use cases.

  • Enabling otherwise impossible collaboration: Imagine if Veolia reached out to a diverse group of sustainability activists, creative hackers and artists, local neighbourhood groups, small businesses, and their direct corporate competition, and asked everyone to work together on a project for Veolia’s exclusive benefit.
    Insanity, right?
    There are clear limits to whom Veolia can work with on a ‘©Veolia, All Rights Reserved’ project. Even when partnerships do occur between large corporate players, it requires careful diplomacy and complicated contracts to ensure effective collaboration.
    Open Source simplifies the transaction - an open license can work as a social contract, and creates a neutral ‘safe space’ with clear, standardised rules. It gives everyone access, and allows unusual collaborations to occur by ensuring that anything developed remains available to anyone, anywhere, to study, use, modify or sell.

In general, Open Source projects require a comparatively low financial investment compared to many other areas of R&D. However, there are many caveats to the above statements.

The first is that open source is not magic. There are many reasons and motivations for people to contribute to open source projects, whether that be personal development, status, money, social aspects, altruism, political purposes… it’s important that anybody wanting to steward an open source community takes the time to understand these motivations, and works with the community to slowly build trust and understanding.

For a collaborative open source project to survive - and to thrive - those coordinating it must keep contributors’ motivations in mind. They must design and guide the project so that motivations are met, contributions are valued, new potential contributors are welcomed, and development is as smooth and effective as possible. There are best practises to help achieve this, but each community is different, and there is an element of trial and error. Careful listening and engagement with the community, and the development of trust is key.

Although open source development has a relatively low financial cost, it takes time and effort to learn and get used to this working method.

Even if a project is well-designed, well-explained and well set-up for contributions, it still needs another key aspect to get people involved: it has to be more than just an idea - you need a proof of concept, a working prototype, or a useful resource to build upon. This emphasises that the project is real, there’s momentum, and there’s a committed, capable team behind it, who have already made the project’s first contribution to the commons. The first interaction should not be to ask for help, but rather a no-strings-attached offer of something useful, as a way to build trust and start a conversation:

“Here’s something I made. You can have it. Is it useful? How do you think I can improve it?”

The ethical boost can only work if it’s honest. You can’t hide anything in an open source project - it’s very difficult, and extremely risky, to say one thing and do another in the field of open source - because the evidence, the truth, is right there for anyone to see in the ‘source code’, the license, and the communication with the community. If you alienate your community of contributors through malpractice or dishonesty, the project loses its reputation, its developers, its marketers, its customers and its business partners. Of course, you may make honest mistakes - but those mistakes should always be acknowledged and learnt from in order to maintain the relationship with a project’s community.

An open license can create a safe space, but it requires that potential collaborators have an understanding of how open source works. They also need to understand the motivations and direction of the person, people or company guiding the project. In software development, most people understand how open source works, so you just need to say “it’s open source, under this open source license” and people understand what they can do with it. The groundwork is laid for collaboration.
But in areas without so much open source development or open source history, convincing people is going to be more difficult, or take more time. This is especially crucial if the central role is played by Veolia, a company with no track-record in open source and one whose motivations may be viewed with a fair amount of scepticism by many people.

In one conversation during the workshop, I talked with someone from a small company who worked in resource management - they were wary of collaborating with Veolia on a shared project because they felt that their small independent company could never compete with a giant like Veolia.
But in this case it’s important to emphasise that you can share infrastructure without competing on business models.

Using their logic, I might look at Google, IBM or Samsung’s investment in (and use of) the Linux kernel and think "Well, I’m not going to contribute to Linux because it will just help the big guys, and they will crush my business."
But in reality, my small independent business probably has a very different business model to Google. Yes, if I as a tiny company try to compete directly with Android, I will indeed be crushed. But there are a huge number of smaller-scale, flexible and local solutions that also make use of Linux - you can build a fridge, a film camera, a spacecraft, or thousands of other IoT devices using Linux, and you’re not going to be competing directly with Google.
If you think of it in terms of our natural ecosystem, and the way that different organisms have evolved to find their niche, you’ll remember that Darwin’s phrase was not “survival of the biggest, the strongest, or those with the sharpest teeth” but “survival of the fittest” - those who best fit their environment, and who can carve out their own particular role amongst the other organisms, no matter who big or strong they may be. Or, to put it another way, an independent taxi driver and a multinational truck company both use the same road, but they don’t necessarily ‘compete’.

Taking part in or leading an open source project can be an worthwhile and valuable endeavour for a company like Veolia - particularly as open source and online collaboration is rapidly growing and moving into new areas. There are also particular areas and problems which are best served by an open source approach - the rainwater issue is one of them.
However, I would recommend taking the time to build relationships, build trust, and understand the open source methodology and community before launching your own project.
Supporting an existing open source project, aligned with your interests and goals, can be a relatively low-cost, low-risk endeavour with the potential for opening up whole new fields, ideas and partnerships. This can be with time, with money, connections or other resources (preferably all of the above). Another approach would be finding and supporting people experienced with open source, who might be interested in helping you develop a project.
This is likely to be gradual process rather than an overnight success - but on the other hand, a large company has the resources and business experience to make rapid changes, so it remains to be seen.
Through engagement with the existing open source community, through listening, learning and gaining experience in this way of doing things, large, traditional companies can develop effective open source projects. To do so they must be transparent and communicate clearly, they must back up words with actions, and they must keep the needs and motivations of the project’s community in mind.


I created a tool and a whole VIDEO SERIES about it to answer the business model question:

First Video out of 9