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 hardwar

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.