
To elaborate on why open-source hardware is hard - striking
http://www.mauve.plus.com/opensourcehw.txt
======
niklasni1
This if obviously true, but I don't think this means we shouldn't demand
openness in hardware, though.

Openness for me is first and foremost ideological, not practical, and
certainly not just about the results. It's really about power, and the
relationship between those who make the technology and those who are dependent
on the technology.

Being dependent on proprietary technology whose continued existence is
completely tied to the financial well-being of a single corporate entity is
not a very good situation to be in for anybody, since it means that you are by
proxy dependent on that entity and its success. Openness does not reduce
dependency on technology, but it does reduce dependency on specific technology
providers, and ultimately I think that's in my best interest.

~~~
angersock
_Openness for me is first and foremost ideological, not practical_

For the case where actually _repairing_ or _maintaining_ hardware is your job,
open design and schematics is _essential_ \--especially if the original
manufacturer is out of business. You'll see this in hospitals, military ships,
machine shops, etc.

------
mbanzi
This article describes why hardware is hard but if you were a small company
designing a closed-source circuit you'll have the same problems.

Being open has the theoretical advantage of having multiple people review your
circuit and help you spot mistakes.

~~~
rektide
The individual perspective is irrelevant. If the rest of the world was closed
source, releasing your program open source wouldn't make much difference.

The difference is collectivization. When practiced widely, open source
hardware means that you can find other designs that have tackled problems
you've encountered. You can borrow one guys power block, find an audio block
that meets your constraints, tack on a core complex from another project, and
use a motor control from a fourth. You probably won't have anything to
contribute to any of these projects: you may face some challenges they face,
but collaborating with them is way harder than with software. That's ok.
There's still a growing of a collective body of knowledge that others can
recycle, and grow atop of. Open source hardware still does what is important
about open source software: it empowers individuals to explore realms they
would never have gotten to meddle with before.

As a small company, you can find a lot better a base than what you might
develop in house if others are practicing open source hardware. And that means
better kit for everyone.

------
pjc50
This came up on electronics.stackexchange:
[http://electronics.stackexchange.com/questions/61873/why-
is-...](http://electronics.stackexchange.com/questions/61873/why-is-open-
hardware-so-rare/61891#61891)

My answer from there: "The "freedom to redistribute copies" and "freedom to
modify" aspects of Free software really don't translate well to hardware.
There is work and cost associated with copying a board, and much more
associated with copying an ASIC (modified or otherwise). It's simply not going
to be within the reach of the average user in the forseeable future.

Another factor is rapid obsolescence. Some of the open UNIX software is thirty
years old; GCC is about 25 years old. Open hardware will generally have a
shorter time before it starts looking horribly obsolete. This is especially
true of all the things that people really want to be open: processors,
graphics hardware, wireless interfaces.

(You could have an open replacement for e.g. the 555 or LM741, which would be
more timeless, but what would be the point? How would it differ materially
from the current ones?)

There is certainly scope for "community" hardware development, but that
depends on having a stable, sensible community that can agree what it wants
and is willing to pay for. Again, requires a lot of work."

~~~
cogburnd02
> You could have an open replacement for e.g. the 555

There is already a kit [1] for a 555-like circuit (I think Dave [2] says
there's some reason it can't be used in place of an actual 555) made of
discrete components.

But there's no indication that it's Open Hardware, though. :-(

[1]
[http://shop.evilmadscientist.com/productsmenu/tinykitlist/65...](http://shop.evilmadscientist.com/productsmenu/tinykitlist/652)
[2]
[https://www.youtube.com/watch?v=U6qZPx4uD0g](https://www.youtube.com/watch?v=U6qZPx4uD0g)

~~~
jpwright
There's a really detailed description of that kit (including full schematic)
here:
[http://shop.emscdn.com/KitInstrux/555/555_principles_revB3.p...](http://shop.emscdn.com/KitInstrux/555/555_principles_revB3.pdf)

------
wpietri
A couple months back I was on a panel on Agile methods with a fellow from
Intel. [1] Normally I scoff at large-company Agile efforts, but I came away
impressed. As I understood his presentation, they had virtualized their entire
System-on-Chip development pipeline [2], allowing them to use software methods
for hardware products.

Clearly we're not there for open hardware, but I think that's the kind of
tooling necessary. If the cost of a build drops from $1k of manufacturing to
$0.01 of electricity, and if the hardware experts express their knowledge as
automated tests, then suddenly randoms like me can, as with open source, jump
in, try a patch, and be given a chance to learn how to do it right.

[1] [http://computer.ieeesiliconvalley.org/agile-update-and-is-
it...](http://computer.ieeesiliconvalley.org/agile-update-and-is-it-for-you-
panel/)

[2] [http://computer.ieeesiliconvalley.org/wp-
content/uploads/sit...](http://computer.ieeesiliconvalley.org/wp-
content/uploads/sites/2/2014/07/harsh_kumar_position.pdf)

~~~
tjradcliffe
For well-established projects with high throughput and lots of resources this
is likely practical, but those aren't the kind of things that "open source
hardware" (a term I personally hate) typically targets.

For niche products being worked on by a small team with shoestring resources,
the problems the article points out just scratch the surface. It gets even
more fun when you add mechanical systems and sensors to the mix. I work in
embedded systems and spend at least as much of my time debugging hardware as
software.

The number of ways hardware can go wrong is astonishingly large. As well as
all the ones mentioned in the article, there are temperature effects, power
supply effects and most of all: noise. Put your system into an industrial
environment with lots of big electric motors generating noise on the mains and
see what it does to your design, even after it's passed EMC testing.

Noise and grounding (particularly leakage between analog and digital grounds)
cause a ridiculous range of hard-to-debug problems. Software by comparison is
easy.

My career has been about 80% software/firmware with 20% hardware, and I'm a
hardware hobbyist (including time as a mentor for an FIRST Robotics Challenge
team, an experience I highly recommend) so I've seen both sides of the coin
and found that the typical "open source hardware" electronics problem is the
kind of flaky, intermittent weirdness that is really rare in well-designed
software these days (it's been years since I've seen a real Heisenbug in
software, whereas they used to be a lot more common). Some of that speaks to
how well-designed a lot of modern software is, especially open source stuff.
Some of it speaks to how difficult it is to predict/ensure the quality of
electronics in the real world.

~~~
wpietri
Sure, but the history of computing has a lot of people solving hard/expensive
problems and then having the techniques trickle down to small/cheap ones.
That's my hope here.

Of course, I doubt it will ever work for the hand-built stuff. I'd guess it
will only make sense for stuff whose fabrication is automated or controlled
enough that it can be reasonably simulated.

------
akiselev
> For something of a smartphone class, a one-off PCB may cost several hundred
> dollars. Then the parts will cost another several hundred dollars in small
> quantities, as well as being difficult to obtain.

> Now, you have to solder the parts onto the board, which is a decidedly
> nontrivial thing - and if you decide you want someone else to do this, it's
> probably another several hundred dollars.

I'd love to live in a developed country where these statements are true. For a
"smartphone class" board with 6-10 layers, 0201 size passives (1.0 x 0.5 mm),
and 0.4-0.5 mm pitch BGAs (almost all mid to high end ARM microprocessors)
you're talking about thousands of dollars of setup costs for each step of the
process _before you even make a single board._ Reducing these costs to the
hundreds of dollars requires a whole different world of expertise dealing with
Chinese suppliers and manufacturers.

To give some perspective on how expensive it is for an EE working in
California on non-trivial projects (more like RPi and less like Arduino): 10
boards with an ARM microprocessor, some DDR2/3 RAM, a multimedia processor,
and a gigabit PHY on an 8 layer board can easily cost on the order of
$5,000-7,000 with a month+ turn around time in the Bay Area. If I want the
same design made in a week by reputable suppliers (such that I'm 90% sure that
the issues I debug aren't from fabrication or assembly errors for a first run
of a design), it can cost me closer to $15,000. The difference between making
10 boards and a one off? Usually less than $500, or 10% of the cost of the
best case. That's usually not including the cost of parts which, unless you're
contracting or working for a big company, you'd be lucky to get without a
friend who can wander around the Shenzhen electronics part markets and
overnight stuff to you.

The problems just go on and on. Many of the useful parts like cameras,
multimedia processors, microprocessors, and high end ethernet MACs/PHY often
require signed NDAs before you can even get the documentation. Oh and if you
want to work with anything considered high speed digital electronics (i.e. bus
speeds of 133/266mhz for DDR1/2 RAM, 1GHZ for MIPI2 cameras), you're now in
the realm of RF (analog) electronics and intermittent bugs that can drive even
the most talented and well equipped debugger insane.

Reality is messy and this is just one of those cases where the decks are
stacked heavily against open hardware that is more complex than an Arduino.
It's telling that many of the open source projects like PandaBoard,
BeagleBoard, or OpenRD were originally made as reference designs by companies
like Texas Instruments and Marvell or as otherwise well funded initiatives
like the RaspberryPi.

~~~
Gracana
I've run into the same wall with my own projects. The differential in cost
between a one-off ARM board of medium complexity compared to even a higher-
complexity dev tool made in decent quantity (gumstix, rpi, beagleboard) is
just amazing.

What I've noticed is that there is a step in cost once you hit a certain level
of complexity. Markup on parts is pretty predictable across the board, but the
fabrication costs jump once you exceed the capabilities of the hobbyist-
friendly services. OSH Park will do 5 mil trace, 4 mil space, 10 mil annular
ring, which is about the best there is when it comes to inexpensive one-offs.
That's enough to break out _some_ of a 0.8mm BGA. To improve your capabilities
with components that size or smaller, you need to look elsewhere, and suddenly
you're looking at "real" services and now the prices are in the several (or
tens-of) thousands of dollars range. That's the point where a hobbyist can no
longer approach this stuff. Now you're investing in prototyping and you've got
to have a business plan.

At least you can get a System-on-Module. That seems to be the only way forward
unless you have lots of money to sink up front.

------
panic
To what extent is it possible to design hardware using a software simulation
of its behavior? Do you actually need to manufacture the hardware in order to
develop it?

~~~
iopq
Most hardware is designed through simulations. It mostly works. That is until
it reaches a certain temperature you didn't simulate and exhibits a bug only
at that temperature.

~~~
GotAnyMegadeth
If you are designing your own ASIC from scratch this is exactly the kind of
problem you face all the time. It is VERY hard to simulate every single corner
case.

If you are designing a board with other people's chips on, where are you going
to get the simulation models from?

------
asb
HDL (hardware description language) is an interesting case. With lowRISC
([http://www.lowrisc.org](http://www.lowrisc.org)) we are working to produce
an open source SoC using RISC-V. The parts of the chip described in high level
HDL (e.g. the main 'Rocket' core) do not have the same issues described in
this document. Assuming you have access to appropriate tools and a design kit
for the technology node you want to target (which can be expensive and/or
difficult) then for the most part, if it synthesises and passes the design
rule checks you can be fairly sure it will work. Where this completely falls
down is for the more analog aspects of the chip, such as the memory PHY
(physical interface). This is typically specific to the fab process being used
and really can not be verified and reasoned about in such a straight-forward
way. People obviously do SPICE simulations and the like, but that only gets
you so far.

~~~
minthd
If i not mistaken, you implement the project in the Chisel hardware language.
How large a productivity benefit has it given you versus standard HDL's ?

------
rian
This is a good description of the state of hardware engineering but I think
the implication is that this will never change is incorrect. Also the main
point has little to do with open-source. By these arguments, even engineering
practices for proprietary hardware are prohibitive to rapid development.

Before we had compilers, debuggers, code analysis tools, garbage collection,
etc. building software was hard too! Some would argue that building software
is _still_ hard.

Hardware engineering clearly needs more accessible and easier to use tools,
open source can actually help this. The best and most-used software
development tools are open-source. An open landscape will encourage
development innovation as more and more people become hardware developers.

With that in mind, I would actually title this article something like "Why
hardware engineering needs to be open-source to advance."

------
GotAnyMegadeth
> it is pure coincidence that all models up till now have booted

This sums up my hatred of electronics.

------
ukrish
Computers-on-module do go a long way in keeping costs down. There are also
services like Gumstix' Geppetto, which let you build a custom expansion board
using their COMs and other functional modules. The price point is a couple
thousand dollars, but after spending a couple hours on a design, you end up
with a high-quality, guaranteed working board in a few weeks without any of
the hassle of parts procurement.

------
ausjke
Not just open-source hardware, actually hardware itself is hard, maybe that's
why it's called 'hard'ware.

Digest thousands pages of datasheet, find the best price of the ICs, making
sure no potential supply issue or long waiting time for the order, PCB, SMT,
cost, more importantly quality assurance at manufacturing, logistics....

I would say it's 100x harder than software, been there done that.

------
bronson
Plus, with software, if you find you're missing something, you download it.
With hardware, you pay through the nose for FedEx and pray that the vendor
offers Saturday delivery. Then you sit on your ass until tomorrow afternoon.

With software, you install updates. With hardware, you milk your device as
long as you can, then throw it away. Board-level rework is rarely worth the
effort.

Yes, hardware is hard.

~~~
ars
I guess that why it's called that? :)

------
flarets
With respect, I don't know if he's suggesting the right approach. Why not
build up a "library" of smaller circuits (e.g. voltage divider, butterworth
filter, debounce circuit etc), that allow people to make bigger circuits by
combining them. Do it on a breadboard to test, then modify.

~~~
tesseract
That sort of library is basically what the industry's vast catalog of
integrated circuits amounts to, except that it is not open source and
generally at a higher level of abstraction than the subcircuits you describe.

~~~
flarets
Really? I thought ICs were more along the lines of microcontrollers which have
things like USB controllers, PWM controllers, GPIO etc. For these, it's mostly
programming.

The library I described was supposed to be about all the external bits: signal
conditioning, power conditioning, sensors etc.

~~~
pjc50
Well, those aren't the hard bits, you can generally pull them out of a
textbook or reference design and expect them to work.

You're overlooking the entire field of analogue ICs. Again, there's a fairly
good cookbook of reference circuits out there. In some cases manufacturers
will help you a lot: TI have a tool for designing switchmode power supplies
around their chips.

So you can compose circuits into schematics. You don't usually compose
_layouts_ as it's more compact to hand-redo them for your particular board
shape. There is some open source hardware at this level; often to be found on
tindie or via hackaday.

Then the other obstacles to shipping a product: regulatory approval. EMC
testing. If it plugs into the mains, a whole bunch of safety testing. In the
EU, CE marking and WEEE registration. If it has a radio, radio approval.

Economy of scale matters as well. That's why things like OpenWRT are so
popular: repurpose hardware that's already mass-manufactured for a slightly
different purpose.

------
mariusz79
We tend to forget that software was hard just a few decades ago. We'll make
hardware easier, but it will take time.

------
alexjv89
This is what I think about Open source hardware. I could be wrong. I would
love to be corrected.

1\. The definition of hardware is different for each person depending on their
background

\- IC engineer's world of hardware is all about transistors and IC design. \-
Mechanical guys world of hardware is all about geometries, material, structure
analysis and it itself has a lot of variations. \- Product designers world of
hardware is just sub-assemblies that already exist.

My point is everyone works with different levels of abstraction. IC designer
has no idea of how product designers work but every one calls themselves a
hardware engineer if they work with atoms (which is fair, but we just need to
know that this difference exists).

2\. Because of this difference in definition of hardware, what do we exactly
mean by open source hardware?

As a product designer, am I interested in an open source version of 555 timer
or NEMA Motor? No - I am just interested in knowing its specs and building
something on top of it. As an IC designer, you might be interested in knowing
the details of the 555 timer and creating an open source version of it. Your
fellow IC designer might find some use out of it, but not the product
designer.

We must understand that an individuals interest lies in different levels of
abstraction. This is true in the software world. Linux is open source but I
might be contributing to a app on linux because thats where my interest lie.
You might be interested in the kernel level.

My point here is that all of the above might be considered open source
hardware but we should understand that modularity and levels of abstraction
exists that makes things possible. As a product designer, 555 timer is a
module, a means to an end.

3\. Hardware land is still very individualistic. Most hardware engineers even
if they make it open source they still work alone on the project, majority of
the time. There might be some levels of collaboration, but most of the time it
is by one person. This is primarily because of limitations in access to
hardware - consumables and equipment as mentioned in the main text. Hundreds
of people collaborating on building one large hardware project has not
happened. Eg - Open source Laptop - Novena is by one person - bunny.

4\. Majority of the open source hardware modules are small modules - like the
sensor modules on sparkfun, adafruit or seeedstudio. Hardware as modules
existed - eg dev board etc. Open source hardware as module was new. This
helped prototypers and system designers work really fast. Also since the
boards were open source, it sort of standardized the modules around the world.
Tutorials and support are easier to find on popular open source boards than on
closed source boards. My point here is that inspite of all this advantage,
open source hardware is still small modules. The primary reason being point 3.
There are limits to what one person can build.

5\. Just making the source open does not cut it for open source hardware. Like
mentioned in the original text, there are so many insights that go into
building a board. That is not reflected in the source file. So for each module
in addition to the source file, you also need to map insights, such as, what
is the reason behind a design choice - Why is there a chamfer? Why was a
particular component chosen? What is the price of a component at scale etc.

6\. What does it take to make large scale open source hardware happen?

My definition of large scale open source is large number of people
collaborating on a single project. Can we have a project that was build by 10
different hardware engineers based out of different locations? This is what I
think takes to build large scale open source hardware a. Modularity - ability
for people to work at different layers of abstraction of their choice.
Contribute to a module b. Ability to map insights - Just open source files
does not help. The associated insights are crucial for someone else to build
on your work c. Access to relevant tools - through maker spaces/techshops.
Here since you are only contributing to a module of the project, you might
only need access to a subset of the tools. d. Version control for hardware is
like software releases - For now we can live without line by line versioning,
but it is important to have access to earlier prototypes that went to the
factory.

We are testing this hypothesis by attempting to build a large scale(defined by
number of collaborators not by size of the project) open source hardware
project - an open source electric unicycle - www.fireflyunicycle.com . This
will be one open source hardware project where others can contribute. This is
primarily an attempt to build a kickass community of hardware developers in
India.

Shameless plug here - I am the founder of a startup -
Makeystreet(www.makeystreet.com). Makeystreet is 'Github for hardware(system
design)'. We are trying to make large scale open source hardware happen.

~~~
kidlogic
To comment on your post (the following numbers correspond to your listing):

1) Yes, "Hardware Engineering" is a very broad term. You'll have multiple
levels of Hardware Engineers all working on different aspects of a design.
However, this isn't much different from Frontend + Backend (and their
associated languages).

3) Multiple parties working on one device, remotely, is possible (see:
[http://www.protoexchange.com](http://www.protoexchange.com) \- shameless
plug). We've worked with multiple engineers on a single hardware device. The
hard-part is that the debugging typically requires each party to have the same
piece of hardware physically available.

It would be interesting to chat more about OSHW if available :)

~~~
alexjv89
Yeah, would love to chat with you more on OSHW. Mail? alex@makeystreet.com

------
guard-of-terra
Most software products exibit all kinds of similar behaviors to his "A-G"
list. The "pure coincidence" thing is how most libraries work in your code.

However, software is usually evolved rapidly to avoid triggering design
problems.

The solution should perhaps be moving more things off hardware and into
software.

~~~
CHY872
What things would you move off hardware and into software?

Typically the reason why we produce something in hardware is because it's
infeasible to do in software. This is because of the costs mentioned.

~~~
guard-of-terra
I imagine we can have SOC of CPU+RAM in one package and save on their wiring,
for example.

~~~
Kliment
Typically you'll use PoP with modern SoCs, where you put the memory on top of
the CPU so connections don't go through the PCB

