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:

1. You will be pushing socially responsible and sustainable business models
2. Expand your own business model
3. Enhance your technical and entrepreneurial competencies.

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:

• Which skills are present within the community and what weak points need to be balanced out by recruiting people from outside the makerspace’s core community?
• What kind of characters can you rely upon? For knowing this, you must be interested in your makerspace’s community on a day-to-day basis: who are those people and what are they working on?

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:

• No exclusion of target groups: You might need specific skills and know-how in your team. However, there is a lot of perspectives that further team members can contribute, because their expertise lies elsewhere. Have you ever considered including groups that seem to have no connection to your product, for example kids? It could be an enlightening experience.
• Low entrance barriers: Try to make your call for collaboration as welcoming as possible by mentioning that no specific skills are needed and highlighting that everyone is welcome. In the ideation phase try to keep in mind that you wish to collect ideas – not final prototypes.
• Broadly disseminating calls: You have an online platform and a physical notice board where you can advertise your call? That is great. But why not also make postings in external event calendars, ask fellow makerspaces to include your call into their newsletter or send a message to the media, both to local and maker specific publications? You could also design fun stickers and plaster your place with it or attend events, conferences or fairs that are connected to your project’s topic to introduce your upcoming idea.
• Use (at least) gender neutral language: This is not just relevant for calls, but also for documentation and all other communication settings. If you want to go even a step further, make sure that the pictures you use for promoting and presenting your project will show people of as many different physical appearances (sex, age, skin color, clothing and hair style, physical (dis)abilities, visible religious affiliation etc.) as possible. You could also make separate calls that specifically attract underrepresented target groups.
• Have an English version of everything: Website, project description etc. should always be accessible in your local language as well as in English (this is for projects from the European setting – in other parts of the world another language frequently spoken by expats might be more useful). This way you explicitly invite international people who can contribute different perspectives.
• Go for an interdisciplinary project: Have you not defined your project yet? Try to design it to include several disciplines to attract people with different profiles.

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:

• communication
• 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.