Open Source Hardware (OSH), also abbreviated (OSHW), is an extension of the philosophy of open source software outside of the cyber domain. It is distinguished from simple sharing, which has existed forever, by the development of official legal structures like licenses. Basically, if you just want to share something, you don’t have to do anything but make it available. OSH is made available under one of many licenses that dictate how other people can use the technology. Rather than the law being used to deny access to technology, open source uses the law to guarantee access to technology.
The biggest difference between open source hardware and software is that the former costs money to design, prototype and reproduce. This has resulted in the now common refrain of, “free as in speech, not as in beer” or “gratis versus libre.” Freedom to do something is not the same as zero cost. The hardware design files might be free, but the hardware itself isn’t.
- Focus on the best possible technical solution regardless of profitability. When profit is the top priority, the natural result is to design things so that they don’t work (as well as they could). Planned obsolescence maximizes profit by ensuring a piece of technology will break at a predictable time, among other tricky things. It increases waste and decreases innovation.
- Use systems engineering for a holistic solution. Instead of optimizing one sub-system at one point in time, optimize the performance of the entire system. Systems engineering is an approach to design that front-loads the design work rather than considering most of it “someone else’s problem.” When one considers how a piece of technology will be manufactured, used, maintained, re-purposed, and ultimately disposed of, rather than merely how it will work, the solution becomes widely useful and longer lasting.
- Enhance modularity and standardization. Most of what we do with technology is always the same (or at least could be). API‘s, calling conventions, contracts, interfaces, standards, plug-and-play, interchangeability, compliance, etc are ways of agreeing to do common things in certain ways so that more time can be spent on the uncommon things. Standards work best when applied to things that have to happen, but are inherently arbitrary. Whenever power, information or force needs to be transferred the receiver has to anticipate the format, but the format itself can vary widely and still work. So, don’t vary it widely.
- Collaborate, communicate and circulate. It usually takes someone with unusual creativity to spark an idea. However, building off of an idea only requires the right person be exposed to the idea at the right time. When a development team is composed of a few people who work in secret their ideas stagnate. Opening up the team to the entire human race allows ideas to flourish. The pace of innovation dramatically increases.
- Design for openness and distribution. It’s great to release design files. It’s greater to release design files in a universal format everyone can interact with freely. It is difficult to divorce the fruits of open source from the process of developing open source, since OSH is always in development. Not only does using open source tools encourage adoption of the philosophy, it accelerates feedback by lowering barriers to entry.
- Strive for self-sufficiency. The reality is that OSH costs (significantly) more than software because it requires more than just time. Unless you have a personal aversion to profit, or are incapable of running a business, it is a good idea to assume you will sell your project(s). Not only does this help open the project by ensuring you track your materials and suppliers, it also helps you focus on innovation rather than resources. If your project is a good idea then it will provide an economic benefit. By tapping into that benefit you fund the further development of the project itself as well as future projects. A good idea should not wither on the vine.
- Choose universal and simple over custom and complex. When you are open sourcing a piece of technology you are presupposing that other people will find it useful and that other people will find it worth the time/money it costs. Customization is for when the project forks sometime in the future. At the beginning, make it as generic as possible. Maximize the chance that someone with the capability and motivation to improve the technology will be part of the group exposed to it. OSH that no one else can comprehend, or that no one else can use, or that no one else can afford is “open source” in name only. Of course, this is relative to the context of your project.
- Try to use existing standards even when they are not ideal. Yes, OSH is a highly innovative playground. No one should ever stop themselves from putting a better idea out there. The kind of people who develop open source technology tend to also be the kind of people who like to “leave their mark” or “do things their way.” That’s probably a large part of why they’re doing it in the first place. However, the more you reinvent standards the higher the barriers to entry and the smaller your pool of collaborators. There’s a limit to how likely someone is to spend time learning your way of doing things, and if they do it then they’re probably the sort of person who will just redo what you did in a “better” way. If at all possible, use a standard that already exists and just create a custom interface for it (if necessary).
- Document. If you don’t document your work no one is ever going to be able to figure out what you did. If no one can figure your technology out no one can help develop it. If you aren’t good at documentation, or aren’t motivated, then find someone else to document for you. Maybe a newbie OSH developer, perhaps an engineering student, it could even be a blogger. Just document somehow.