Besides more frequent and more useful user integrations such as feedback loops, OSH enables decentralised production, maintenance and extension. For example, a relatively small company with limited resources are suddenly able to cover a relatively big market with a large variety of derivatives of the same product as seen in the case of Arduino and OpenWB. Furthermore, the product comes with the promise of endless support (see Gardena) and modifiability (see CERN hardware, e.g. for White Rabbit). Lastly, market penetration is far easier since anyone using your product is indirectly supporting your concept.
Generally speaking, your innovation process increases. E.g., time to market is shorter when you make use of the power and knowledge of a large and interdisciplinary community. Features are tested in the field in a decentralised manner and development costs are far lower due to building on existing open source solutions, standards and infrastructure. The latter is possible since OSH Development does not just mean that you offer knowledge but that you can also use knowledge that has already been offered by others for free. In other words, there is no need to reinvent the wheel. Furthermore, costs for services such as product support can be externalised via the community that evolves around the product. If applied to external modules, your negotiating position in the supply chain greatly improves since you do not depend on individual manufacturers anymore.
Lastly, the next generation is betting for a more open and inclusive future. Already now, many companies use open source projects for recruiting. If you do the same, you will greatly increase the prospect of getting highly motivated, already incorporated, skilled developers.
That was our TL;DR, but do go and check out:
OPENNEXT focuses on encouraging and supporting SMEs to unleash the potential of open hardware through engagement in the collaborative and open designing of products and services together with fab labs/makerspaces. We thereby enable SMEs to follow a community-driven approach.
Open hardware extends the open source principles known from the software industry to physical products (called open hardware). Open-source software played a huge part in the creation of the internet, and open-source hardware has the potential to upend global industries as we know them.
For the sake of keeping the scope, OPENNEXT is currently focusing on:
SMEs in OPENNEXT work closely with consumers, users, developers and other SMEs. They find support in building communities around an open-source hardware idea, can follow a collaboration path that has been pre-structured based on scientific expertise and best practices, and thus gain valuable experience with open source hardware development. The prototypes benefit from the diversity of skills and perspectives of the contributors. They thus have the potential to be truly innovative. All this remains with the SMEs long after the end of the project.
Participating in open source hardware development enables you to gain an interdisciplinary view on your product and its surrounding environment by collaborating with an interdisciplinary community. You can generate development speed and reduce your development costs by opening up. Collaborating with a makerspace, you have access to a well-equipped lab as well as the makerspace’s prototyping and development infrastructure.
In short: You can go from idea to tried prototype and commercial roadmap with just a few months, whilst creating a long-lasting and sustainable product line and business plan.
OPENNEXT is funded by the European Commission. As such, there are no charges or contractual obligations.
Development of a product is costly, regardless if you do it open source or conventionally. Incurred costs by participating SMEs (e.g. for their own resources or prototypes) can arise. These are expected to be offset by the resulting opportunities. The development can be cheaper due to making use of available resources and communities.
The only investment, really, is time. Time to build up your community and to maintain it, and to raise awareness for your product within the communities. But we still think that beats waiting 2+ years for the patent lawyer to approve you idea.
The OPENNEXT project cannot provide any funding for SMEs applying to the open call. We are currently also not aware of any other means to attain funding.
The four partnering makerspaces offer facilitation free of charge if you are selected to benefit from it. The facilitation offering has been tested with six SMEs within a 12-months period. The OPENNEXT partners will also provide selected SMEs with facilitated check-in sessions, expert consulting and open-source mentoring.
The generally most common advantages and thereby potential unique selling points of Open Source Hardware products are: Transparency, Novelty, Endless customisation, Ensuring future product support and repairability.
When building upon existing open source solutions, the biggest advantage is that some of the basic work is already done. Thus, the customer has to pay only for the individualised service or adaption. Furthermore, the customers know what is inside the product. Therefore, they know what they buy and they are able to repair or modify it to their needs easily. In addition, of course, customers do not depend on the service of the manufacturer if they do not want to. Island products find it more difficult every year to succeed on the market. Opening up products helps creating interfaces and connecting them to other products, which becomes more a basic requirement than a market advantage in our increasingly connected world.
But there are also advantages regarding pricing and interface design. The speed at which OSH innovation happens means that the newest features, retrofitting to different use-cases, tweaks will most often beat any proprietary competing solution. So, you can be among the first to try a new feature.
1. Leverage through expansion with communities
Leverage through expansion with communities is a long-term objective, and it opens up the possibility to become a standard or a brand, like in the case of Arduino. Core of the OSH idea is the collaboration with both developer and consumer/user communities to leverage the potential of innovations, ideas and specific products. As we can learn from Arduino (IoT), the approach helps develop a very flexible product for a variety of uses and modifications and thus becomes the standard, “the brand” of a sector.
2. Selling manufactured products
This is the “classical” and still the most used business model, where basics and components/supplements are sold (e.g. 3D printer and materials), establishing an online shop. Successful examples for this are selling (complex) products like
3. Selling service, knowledge and expertise
Offering consulting and workshops can be a supplement business model, as Arduino does it (IoT). But also offering services like cloud services can be a successful business model from the intangible field as Particle (IoT) does, just as access to knowledge via subscription as with the Air Quality Egg.
Selling platform transactions are another possible business model, for example when establishing and maintaining a 2-sided platform/marketplace. The focus here should be less of a (single) product focus and more an ecosystem and industry focus. A successful example is OpenDesk (furniture), a platform that pushes potential decentralised production by bringing together customers and registered makers that produce the OpenDesk product for the customer, with the platform charging a fee.
5. Crowd- & Third-Party Funding
Sustainability and future-related projects that try to solve grand challenges, probably on a non-profit basis might build their business model around (public) funding strategies. Successful examples for this are:
How much time depends very on the type of project, the project goal and the collaboration format. In the pilot phase of the OPENNEXT project, time investment of the companies ranged in between three hours and more than 50 hours a week. Within the activities of the Austrian matchmaking organisation “industry meets maker”, companies invest roundabout two hours a week for six months to develop a prototype together with maker teams.
More important than the quantity of time allocated to the collaboration is regularity. Regular exchange in between players from company and the maker teams is crucial. It is highly recommended to agree upon at least biweekly touchpoints for the collaboration to work smoothly. OPENNEXT will help facilitate this.
Experience shows that it is most promising to choose a completely new product or add- on to an existing system, rather than trying to turn a formerly closed product into an open one. This is mainly due to the degree of documentation that usually has not been done with the exactness required for an OSH product when the product has formerly been closed. The reconstruct development steps and data subsequently often leads to knowledge or data gaps, resulting in hard to manage numbers of community inquiries. For a new OSH product or add-on, the necessary documentation procedure takes place on the go and the community working on the project and depending on the information will recover gaps in documentation almost immediately. This way it works as a naturally self-controlling system.
However, retrospectively opening up a product might also be possible, depending on the complexity of the product.
The short answer:
Makerspaces and their communities are an integral part of the OPENNEXT project. Building an open source ecosystem without them, frankly, wouldn’t be viable. And we also wouldn’t want to do it without them.
The longer, more elaborative answer:
Having an innovative idea and market experience are a good start for an OSH project. However, one’s own experience also tempts one to see things from a certain perspective, which narrows the space of opportunity.
Makerspaces are places of diversity and often already have a community that deals with OSH. This usually includes more advanced makers who can contribute greatly to the success of OSH projects. Even if no such community exists yet, it is the daily business of makerspaces to build communities. Therefore, they can be ideal partners for initial OSH projects. The diversity of people in such places enables the inclusion of many different use cases that may have not even been considered until then.
Another advantage lies in the working culture prevailing in makerspaces, which is characterised by co-creation and rapid feedback at eye level. Flat hierarchies generate a constructive, honest exchange. Companies that are willing to engage in this can count on great professional added value and a lively, creative and goal-oriented working environment in which the values of open source are lived every day.
The challenge lies in finding the right sub-community in the makerspace’s general community to get started with the product development. Someone needs to identify who has the right skills and who could be interested in the product. People are not hanging around in makerspaces waiting to do boring stuff for others. They need to be involved emotionally. For this, knowing the wider community to recruit from is crucial.
Anyone who wishes to contribute to the project can become part of the community. Which kind of community is needed for which OSH project depends very much on the specific case.
The communities within OSH development can be potential user groups who provide information about their needs in the early development phase, similar to classic marketing, or who test prototypes. It can also be groups that generate product ideas in the first place, or groups of people with more advanced technical skills that deal with design aspects.
It is makerspaces’ daily bread to build up and nourish communities around projects, thus collaborating with a makerspace can really push your community-building. First of all, each makerspace has an active community that is involved with co-creation projects on site. These are practitioners with varying degrees of technical expertise and professionalism. In addition, makerspaces have large networks of former partners from a wide variety of fields who are open to new recruitment if projects resonate with their interests and values.
In OPENNEXT each SME will be collaborating with a makerspace that will bring in its expertise in the field of community building. Furthermore, a structured approach to defining and designing the projects is offered in a sprint format which helps identifying what kinds of community would help push the project forwards.
Collaboration is a respectful mode of working together with people on eye-level who might see things differently. Makerspace operators are not mere service providers, nor is the community a low- cost workforce, nor the company just a financier. Collaboration means that all partners allocate their resources, may it be experience, expertise, money or time, to the common project goal. Team spirit is a major predictor for successful OSH projects, thus hierarchies are low. Especially when working with communities, an appreciative relationship can be a real game changer.
It is important to keep an open mind towards the developments of the project. Planning in phases rather than outcomes is a promising approach when collaborating with communities. An OSH development project might be divided into e.g. initial phase (getting to know each other), opening phase (making an open call, building teams etc.), and development phase (up to a prototype presentation of the individual status reached), followed probably by iteration phases steering towards ongoing community involvement, if this is what the project is aiming for. Those phases can be specified in further detail as things develop.
In OPENNEXT, you will be paired with a best-practice community partner, i.e. a makerspace. Together, you will work on setting clear goals for the success of the collaboration and the project, as well as outline a project plan with clear milestones, commitments etc. Curiosity and openness are essential to creating the biggest possible outcome from the collaboration. A true commitment to OSH development of all partners is indispensable at least for the time of the collaboration. Otherwise, the project is most likely going to be a waste of time, energy and resources for all partners.
The company together with the makerspace defines the challenge or the goal of the development process, coordinates regular meetings and contributes own expert and market know-how as well as sometimes materials, machines and infrastructure. The makerspace can act as a matchmaker, infrastructure provider, coach and communicator. The makers or open source hardware developers develop the product or contribute to the development process. However, it might also be a community that defines a need and recruits a company to collaboratively develop and market a solution.
It is useful to create a team, consisting of both the makers and developers of the company. The makerspace is the infrastructure provider and moderates the process like interpreters, translating between the maker language and the business language, creating events and matching processes and know-how.
You will be required to take part in several development phases and check-ins with the OPENNEXT consortium to document and reflect on your process. For the practical implementation, the collaboration phases follow a sprint design, gearing it towards efficient and effective working modes.
During the “preparation phase” or the “strategy sprint”, the SMEs gain insight into the development of open source business models. Importantly, the ideas of the organisations involved are visualised and mutual expectations and responsibilities are explicitly clarified in this phase. This results in an elaborated shared project vision and project planning.
In the “problem framing sprint” or the “analysis and identifying potential phase”, the SME gets an extended view of reference products and documentation of the state of the art. In addition, it establishes contact with customers/users of similar products/services including their needs situation (e.g. through interviews & surveys). This can lead to new perspectives on the own portfolio. At the end of the phase, a list of possible product profiles (including needs, use cases, customer/user analysis) is created, which documents the actual problem for which a solution needs to be developed and can be evaluated.
From the design sprints of the “concept and specification phase”, the SMEs receive a list of possible solution ideas and concepts for the selected problem, including the evaluation of these to track the decisions. In addition, there is early feedback on the solutions developed through rapid prototyping.
Through further design sprints in the “realisation phase”, elaborated demonstrators are created, which can be integrated into the existing environment and validated. The iteratively developed and sufficiently documented prototype generations enable the development of a series prototype and can also serve as inspiration for future projects. In addition, the SME can build up a good contact/trust relationship with makers/community members and involve them in future projects (e.g. spin-off).
In the “reflection phase”, the SMEs receive an overview of the lessons learned and best practices of the project for future OSD projects and cooperation, so that an internal SME evaluation of such a cooperation is possible.
Depending on the makerspace, existing infrastructure and machinery can be used for prototyping as part of the project. Also access to further machinery from within the makerspace’s network might be possible. If there is scrap material (which is often collected for use in prototyping) available at the partner makerspace this can often be used. However when it comes to bigger loads of material or special materials, these will need to be purchased by the SME.
There are a number of collaboration platforms that can be used, e.g. Wikifactory, Hackster, or Github among others. We don’t recommend relying on email or messenger services as these will most likely lead to misunderstandings, time loss and probably frustrations. Furthermore, since OSH projects need to carefully document their progress, using an openly accessible collaboration platform avoids unnecessary double work and is thus a question of efficiency.
Whatever platform you choose, make sure that it provides the following basic features:
• community building (demonstration and participating options) • documentation
• version management
Within the OPENNEXT project we rely on Wikifactory, which is also one of our project partners.
No matter what you do, there is always a risk of patent trolls suing you. But that doesn’t mean they will be successful in their lawsuit against you.
At least, by publishing the documentation for your innovations openly, you are effectively removing the ability for anyone to get any patents accepted that will create problems for your subsequently to your publishing date. Furthermore, by having a community of users actively using and co-developing your product it can be hard for a patent troll to argue against your case.
Generally, people overestimate the risk of patent infringement with open source and underestimate what simple research on patents related to the item in question can do.
You can even state clearly how you have actively searched for any potential infringement and encourage anyone in the community of co-creators to notify you upfront if they find something.
However, for companies developing bleeding edge technologies as OSH, there might be a risk of being sued since this is a field patent trolls are acting in. And because documentation is open, patent trolls can assess the success of a trial to some degree beforehand. Therefore, companies could outsource their documentation activities to non-profit or research organisations.
In OPENNEXT, our experts on business models, documentation and patenting will help you safeguard you OSH development.
Absolutely, as an open outreach is intended to attract enthusiastic co-creators. If deemed relevant, the makerspace will co-organise open calls with your team around the project idea. They will bring in and attract skilled makers from their network to co-create together with existing and potential customers and other enthusiastic contributors.
The envisaged open hardware project will be shared for open collaboration on the Wikifactory-platform that currently engages 80,000+ members from 190 countries, which are mainly product designers, engineers and enterprises. Moreover, the resulting open hardware product will be linked on an open hardware reference database co-developed by Fraunhofer and WikiMedia to make visible the different components and locations where the product documentation is being developed.
And, of course, the OPENNEXT project will seek to spread the word about the open source hardware journeys of you and other SMEs involved.
The engagement is limited to a maximum of six months. However, SMEs are free to engage in independent future collaboration with the project partners (labs) or externals based on mutual agreements.
Our long-term goal is to create an open ecosystem for open source hardware creation. So, odds are that there will be something happening after OPENNEXT worth being part of.
If you as a makerspace are considering getting involved with open source development on a more professional level by collaborating with companies, there are basically three major advantages for you and your makerspace:
If your goal is to not just add any value but a value that benefits the most, you need access to real customers, who can help to define features that are most valued. Company collaboration could give you access to real target groups. As companies’ collaboration partner you also get the chance to integrate your own ideas into products with no financial risk.
However, if you want a share of revenue in case the product turns out to be a huge success, make sure to settle for respective agreements with your partner company. The learnings you get out of the collaboration regarding OSH development, specific tools and machinery as well as understanding how business works and developing competencies as a professional business partner, will certainly be beneficial to your own business setup.
Makerspaces’ experience in building up communities and engaging with diverse groups of people is a competency that many traditionally organised companies lack. However, when it comes to OSH development, this is a basic requirement. Thus, companies that are interested in OSH development can be expected to be open for makerspaces’ and makers’ input.
For the long run, there are two basic approaches you can consider:
1. Make the foundation of your project open source, but make the part of the project that is the USP of your product proprietary.
2. Build a paid service around the core OSH product, e.g. by customising it to your customers’ individual needs. If you give your customers the opportunity to build the hardware by themselves, it is probably cheaper for them to get started with your service compared to your competitors’ offering.
Engaging in OSH projects that are publicly funded or setting up a project based on crowd-funding can also be good starting points for your OSH engagement.
Search for companies that are already active on OSH platforms. If they have already developed products with open hardware licenses or participated in events like the Open Hardware Summit, even better!
Another question you could ask yourself is “does the company develop products for a type of customer that might be keen to get involved in the development process itself?” In OSH development you can involve your future customers from the very beginning in the product development process, which can be an advantage for both the customers and the companies. However, this only works if the customers are interested in getting involved.
A person of contact is always the best entry point. Therefore, ask around in your community to find people who can introduce you to companies. For example, ask the managers from your makerspace (if you are a member) or from other makerspaces (if you are an operator) if they know someone from the Open Hardware scene and contact that person via his or her profile on Open Hardware platforms or social media profiles. Within companies the innovation managers, if there are any, are good first contacts.
Clarify the expectations of all involved parties, both the short-term, medium and long-term expectations. This is the crucial point in a collaboration. Get to know each other, learn each other’s goals and expectations, and very importantly, working styles. A nice starting point is to arrange a workshop were the partners switch roles, so that the company partners have to look with makers’ eyes at the project and vice versa. By the way, it can be helpful to engage an external moderation for the initial workshop so everyone can fully join the exercise and the moderator can be free of judgement.
After the initial brainstorming workshop sessions, where you clarify your goals and get to know each other, you need to have regular meetings on the progress, where the next steps and the development processes are coordinated. Regular exchange in between players from company and the maker teams is crucial. It is very important to have a communication tool for the running exchange. E.g. a chat tool and a file sharing server make collaboration so much easier. However, live meetings are indispensable, but as we’ve demonstrated in OPENNEXT, running a collaboration online is far from impossible. You could find an agile format with sprints of e.g. two weeks. Then you exchange ideas again, refine what you have done and decide what you want to do next. We recommend using platforms like MIRO to structure your sessions and keep track of what you’ve done and where you’re headed next.
This has to be decided on an individual basis from project to project. The perfect moment to take this decision occurs as soon as possible when all partners are convinced they want to go the open source way. When teams are formed from the makerspace community for the development process, e.g. via an open call, the project is opened up for contribution.
However, experience shows that in the early phase of the development, the team should be kept rather small to be opened up further only a little later. In a time when the direction of the project is not yet clear you do not need hundreds of developers who are doing something and then the management discards 90 % of the work they have done. This demotivates the makers. Thus, it is better to first have a clear vision of where to go, and then invite people to join.
Generally, we recommend trying to avoid inviting pessimists, cynics and choleric individuals. Ideally, you have people in the team that belong to the project’s target group, e.g. makers who feel the need for the envisioned product personally.
When it comes to putting the team together, the makerspace operator needs to know the makerspace’s community. Questions you can ask yourself include:
Diversity within the team is important, especially in the early development phase. The benefit is maximum variety of perspectives and ideas. Depending on the project the following measures can help diversifying your team:
A good connection to your company partner is certainly necessary if you want to let it loose upon your makers later on. As stated before, initial workshops that are only about getting to know each other and negotiate your goals are the very basis of a good relationship. Since working modes might differ in between the project partners, regular calls can help to avoid misunderstandings. A constantly updated platform where all necessary files are shared and communication is supported makes knowledge exchange so much easier and helps avoid frustration due to time loss and complicated communication procedures.
Try to also keep the SME’s position in mind: what are they trying to sell and to whom? This is probably their way to make their livelihood and needs to be respected as such. However, at the same time, make sure to remember your own as well as your makers’ values. Respect for the other one’s position does not mean to let go of one’s own. Rather, understanding each other helps coming to a swift and diplomatic agreement if a conflict of interests arise.
OSH development collaboration for you might be a journey into hitherto unknown lands that you and your partners start out on together…
This expedition will most likely require moving within new surroundings with new working modes, methods and perspectives. Probably even more important than the product might be getting to know the process of engaging in the world of open source hardware.
Collaboration is a respectful mode of working together with people on eye-level who might see things differently. This means that all partners allocate their resources, may it be experience, expertise, money or time, to the common project goal. If this finds general agreement, tensions arising from different perspectives can be overcome.
Collaboration can contribute to develop or evaluate project or product ideas together with users or a community…
It can also aim at putting together a core team as well as a community suiting the project, designing prototypes in a diverse team, or getting access to machines and tools needed for prototyping or production.
Especially when collaborating to develop ideas together up to the prototyping stage, regular exchange in between players from company and the maker teams is crucial. Agile formats with sprints of two weeks can be a very productive working mode. In this scenario, every fortnight the partners exchange ideas again and refine what they have done so far and what to do next.
SMEs find it easier to adapt to the different working mode of makers if some of their “project language” is adapted within the project, e.g. drafting a time line with rough milestones. Of course, it is hard to predict the outcome of open development activities with a community. However, pit stops at which the current development status is presented and discussed can be planned in advance (also together with the community) such as launching an open call.
You could start by planning your collaboration in broad phases e.g. initial phase (getting to know each other), opening phase (making the call, building teams etc.), and development phase (up to a prototype presentation of whatever status has been reached), followed probably by iteration phases steering towards ongoing community involvement if this is what the project is aiming for. Those phases can be specified in further detail as things develop. And you do not have to define at what point which team will present a prototype of which maturity level.
Curiosity and openness are essential to take home the biggest possible output from the collaboration. A true commitment to OSH development of all partners is indispensable at least for the time of the collaboration. Otherwise, the project is most likely going to be a waste of time, energy and resources for all partners.
This of course depends on the kind of project and who is initiating it.
In the classical scenario in which a company is looking for partners to get involved in OSH development, the makerspace operator can be a communicator between the company and the makerspace community, since they know all their members as well as their interests and profiles.
It is useful to create a team of both, makers and developers from the company. The makerspace can act as the infrastructure provider and moderates the process like an interpreter, translating between the maker language and the business language. In this scenario, the company will most likely be in the lead since it should know its customers and the current market needs. The makerspace is the event manager, communicator, matchmaker, and also a coach for using the machines and developing technology. Thus, the makers will develop the actual OSH product.
Collaboration platforms are a necessity of successful collaboration. Relying on e-Mail or mere messenger services will lead to misunderstandings, time loss and probably a frustrated team. Furthermore, since OSH projects need to carefully document their progress, using an openly accessible collaboration platform avoids unnecessary double work and is thus a question of efficiency.
There are a number of collaboration platforms that can be used, e.g. Wikifactory, Hackster, or Github among others. Whatever platform you choose, make sure that it provides the following basic features:
• community building (demonstration and participating options) • documentation
• version management
In OPENNEXT, we rely on Wikifactory.
It is only natural to experience controversies, for example regarding working cultures and expectations.
This is why it is so important to clarify from the beginning: what are the goals, what can you expect and what can you not expect from each other, as well as the makers.
To reduce alienation, you should really take time to generate a common understanding of the collaboration before you start with the actual development. For the ongoing process, it is very important to talk about upcoming issues as soon as they are detected, even if it is in the form of yet an undefined irritation.
A common challenge is the different working speed of companies and maker communities. Processes in companies are often slower than among makers.
Another possible conflict lies in the profit-orientation of companies, which applies much less to makers, especially if they are from the open source scene. You have to make sure that the makers are treated fairly. If it becomes apparent, for example, that the company joined the project not so much because it can identify with open source principles, but because its marketing department thought this would be a good idea, it is better to stop the project or realign with the company.
In OPENNEXT; we’ve seen that SMEs expect makerspaces to support their project in three fields of expertise that the company might lack: experience with communities, technical skills paired with creativity, and OSH experience.
The expectations regarding experience with communities reaches out to the entire field of building up, managing communities, and profiting from communities. Companies hope to get access to a network of contributors via the makerspace and to benefit from the makerspace’s expertise in putting teams together and being in regular exchange with them, probably motivating, negotiating and counselling the team members, e.g. reacting to whatever might come up in a favorable manner. They rely on makerspaces’ skills of knowing their community and how to approach them, probably even hoping to get a framework for that and being counselled to do so. Sometimes companies also believe research institutions and funding organisations to be part of a makerspace’s wider community and expect the makerspace to propose funding opportunities or funding models for co-designers.
Furthermore, makerspaces are perceived to have both technical expertise and creativity, which makes them interesting brainstorming partners for planning OSH development projects, especially in the design phase. Some SMEs might also hope to receive practical technical assistance or counselling from their makerspace partner.
Makerspaces’ orientation towards collaboration and openness nourishes the expectation that makerspaces are also experienced with OSH development. When collaborating with makerspaces, SMEs might hope to receive information about OSH, training on how to use OSH in product development or even ideas for business models around OSH.
These are expectations expressed by SMEs. However, those expectations might not correlate with makerspaces’ reality. Thus, make sure to ask your potential partner about any expectations he or she might have and put those into perspective if they do not match your reality. Make clear what your partner can expect from you and your makers, and what not.
Makerspaces have great expertise in working with communities and rapid prototyping. Ideally, they accompany the product development in the early ideation phase, i.e. at the very beginning of the product development process, when it comes to developing a wide variety of solution ideas and developing initial prototypes.
For all further phases of product development and marketing, the competence clearly lies with the companies. Makerspaces usually do not have the necessary resources to bring products to market, nor is that part of their business model. Thus, the market launch is the company’s responsibility.
However, OSH development is often rather an ongoing process that cannot be easily defined in classical project terms to have a clear end. They can last longer, theoretically even forever. The goal should be permanent involvement of the open source community. Once there is an OSH community developing on the project, they keep working on it even though the product is on the market already. In such an optimum case there is no end point when they give the results to the company and are no longer involved. Of course, the community management can then be done by the company itself and the makerspace plays a role as part of the community. If the product goes into mass production, this is certainly the expertise of the company, not the makerspace.
Nevertheless, many makerspaces have experience in crowdfunding, for example. Marketing activities from this area can certainly be taken over by makerspaces.
Fabman is such an example from the makerspace scene.
Fabman is a management system for makerspaces. It consists of a hardware component and a software service. The project was started by HappyLab Vienna as a closed product with the result that many customers approached the HappyLab with special needs regarding the hardware. Since it was impossible for the team to adapt the hardware product to all those individual needs and get it CE-certified, which is a time-consuming process, they decided to open the product up. The code was shared and the customers could develop hardware solutions meeting their specific requirements. As a result, there was a huge increase of users and customers attracted to the service around the hardware product, which continues to flourish to this day.