Overcoming the Open Source Hardware Productivity Problem

I mentioned in an earlier post that there are four major barriers to open source hardware development as a community: knowledge, physical skill, time, and money, as well as a few ways the community might overcome these barriers. These potential solutions came from enhancing the knowledge and skills within the community, and then sharing time and money.

However, there is another way of looking at it. You can have a fully functioning OSH ecosystem by letting each person do what they do best. This means that engineers stick to circuit design, and coders can continue to piece modules together and write software. Not to say that one individual can’t learn more or do both coding and circuit design, but the point is to focus on dividing up the large project of OSH design into specific tasks, or layers.

These layers correspond to the processes of design involved in any hardware project. Several leaders in the field have defined it in their own terms, and the layers are generally as follows:

• Circuit design
• Component layout and assembly
• Software/firmware to interface with hardware

Hence, collaboration can happen on multiple levels. For example, freelance engineers may work together to develop a circuit board- the basis for a new component. Alternatively, other individuals may take different components to build a gadget that they then program, specifically to serve their processes.

So this speaks to more ways we can address the knowledge and physical skill aspects of the OSH productivity problem. However, time and money, arguably the most difficult to address, remain unsolved. Part of the issue arises from the tangible cost investment of producing the hardware. Let's say that the circuit is designed in an open source fashion. Who foots the bill for production of hardware? What about prototyping? And who picks up the revenues from sales: the people who designed, or the people who manufactured the circuit?

The logical answer would be to split it. But the financial valuation of design contributions as well as licensing makes it far more difficult for the system to function, not to mention that a system too restrained may even be counterproductive to open source and collaboration. Especially in the world of open source, it is always a complex issue to monetize the product if "the community" built it. I will present a hybrid model for OSH in my next article.