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.
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.
> Openness for me is first and foremost ideological, not practical, and certainly not just about the results.
The problem is openness took off in software because it's very practical for some kind of developments, and IMHO, this tremendous success wrongly suggests that it could be applied elsewhere. I'll back that statement by pointing out that very little open software had organic success among consumers (products like firefox and VLC), other are either backed by big tech companies (android, Java), many times with the open source software having a closed development process.
Indeed, and this is why there's something to the argument that talking about software freedom, and in this case hardware freedom, is more important than talking about "Open Source."
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.
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."
It only works in software because most don't pay a dime for what they use, except for the computer itself.
When money comes into the picture it always fails down as pure model.
This is also why most successful open source projects are coupled with SaaS, consulting, trainings, books, certifications, hardware. All areas where software is not the main product.
> 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. :-(
Nice teaching tool, but even if was electrically identical and Open there would be little point in using a de-integrated circuit in actual production, surely?
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.
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.
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.
You seem to be discussing a very different level of hardware development than the linked article is.
SoC design, along with FPGAs, and generally any digital logic oriented device lends itself well to software style development approaches because a large portion of it is software. The design of such devices is done in a HDL (Hardware Definition Language), not with schematics.
There really isn't a HDL for board level design (unless you count Spice I guess), mostly because board level design doesn't have the neat and clean abstractions that on chip digital design has. e.g. you can black box a 4-bit adder and glue a few together without much care about the implementation. You can't do the same thing with an audio pre-amp circuit that will be part of some mixed signal board as the implementation will often be driven by complex interaction with the rest of the design, right down to physical placement and layout of the circuit on the PCB.
Sure, I'm not saying they're equivalent. I'm just saying that this points the way.
There was also a time when making software was too expensive to make for modern methods to work. When my dad got started, machine time was way too expensive to spend it on things like frequent compiling and automated testing; it was cheaper to have humans stare very hard at paper printouts and simulate operations using paper and pencil.
That changed with the rise of the personal computer, and changed further as computing power got cheaper. Now developers can spin up whole virtual clusters of machines to test things out, easing the development of open-source software for those environments. If software is eating the easy end of hardware, that at least means that some open-source hardware will become plausible. But I hope the progress will continue over coming decades.
> 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.
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.
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?
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.
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?
This approach is fine until you try to include an IC in your design, at which point you have only an extremely limited version (if any) available for simulation.
I worked at a product design consultancy and saw a number of board designs come through the office. All of them had a prototype run of 3-6 boards, which ended up with one or two modification wires before a second, final, production run was done.
That's another wrinkle. Because boards are so expensive and turnaround's so long you typically want to rework them when possible to validate changes. That takes a talented technician, fairly expensive equipment and time. Reworking e.g. a dozen boards can take days.
HDL (hardware description language) is an interesting case. With lowRISC (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.
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 ?
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."
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.
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.
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.
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.
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.
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.
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.
What will work for 1MHz won't work for 10MHz and for even 50MHz you often need to redesign PCB. Breadboards stop working at about 10MHz - you will experience transient errors that will prevent your design from working properly at all.
Hardware is full of side effects, the higher are frequency and smaller the components, the harder they are manifesting themselves.
For any decent scale project hardware costs (chips, PCBs, assembly, conenctors) shadow developement costs. While in software it is appropriate to have large libraries/frameworks with batteries-included, in hardware it is much cheaper to stitch together custom solution out of very specialized circuits.
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.
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 - 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 :)
This is actually one of the things we're looking at with the open-source lowRISC project. Moving aspects of the I/O system to RISC-V cores to enable you to implement SPI, I2C, I2S etc and other custom protocols in software. http://www.lowrisc.org/docs/memo-2014-001-tagged-memory-and-...
In my view, this is being done continuously. Hardware designers are always conscious of what work can be moved to software. Thus the state of the art in hardware, at any given moment, will be exactly to do the stuff that isn't done well in software, or that is limiting the performance of software.
For this reason I think hardware will always be hard, because we will keep moving the goalposts as technology advances.
Interestingly, outside of the electronics realm, 3-d printing has begun to spur collaborative hardware design. So we should "never say never" about electronic hardware.
Place FPGA blobs down, now you have hardware like software components. But not an option for battery powered products, because of the high power requirements of FPGA's.
Not only that, FPGAs can't do sensing, can't condition analog signals, can't drive large currents. The power consumption is just one of many limitations.
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.