Hi all If you are interested in open hardware, please indulge me. The context: On our trip to the Honingklip brewery, Andy and I got talking about open hardware, a big mutual passion. The conversation continued all through the trip.
I would like to write this up as a blogpost, and a draft is copied below. This email is mainly for Andy, Marc, Mark and Graham to give input, but why not build on the discussion with the whole of DebConf? The purpose of the blogpost is not to be decisive on an opinion, but to give an idea of the tensions at play. If there are other posts out there about this topic, I'd appreciate links to them too. (There is also a panel discussion on Saturday 2 July where we can pick up on this more formally) best regards Bernelle ====== DebConf16: Where do you draw the line of "Open" in open hardware? pre-amble - great beer at Honingklip, a brewery that is a good example of open hardware. But what does this mean? At the most basic level, it is about what is available. What is manufactured, and how available are the units once these are not manufactured commercially anymore? There are different levels to consider, including the platform used and the chip architecture. The CPU (central processing unit), I/O (input/output) The thing that it boots from, e.g. an ARM64 tech alpha instruction set. The questions to ask when you need to determine your own level of "openness": - At what level are you willing to buy it? - Can I reproduce this at home? (And this is relative, comes back to the question of, at what point am I willing to buy (some of) the components? Now the units are running stuff we can't even see, it is too complex to analyze. What does it mean to be open? - To be accessible, hackable - To give a 'How To' manual with the hardware, to say what they did, and how the user could do the same thing, explaining how it works. - Open is about the idea that you can at least try to reproduce something. - To share your design, and let other people comment on that design. But, to implement the design, you need money. Hardware is different from software in it's materiality. Software scales exponentially: once you made something, you can sell every new unit with a very small increase in cost. Hardware scales linearly. While the overall cost of design per unit reduces with the more units you produce, there is still a cost associated with each new unit produced. There is material cost, and cost of production, time on a machine, electricity, labour, shipping... There is a difference between 'telling' people something, and 'giving' people something. A challenge to hardware is that it is more and more integrated, and if you want to do a thing, you need to pay someone to do it for you. We then chatted about what to do about this. Appropriate level of complexity is one clear argument. There was talk about overspecification. The metaphor of music cassette tapes were used: they are no longer made, but they may be appropriate for simple applications. You need, for example, a 74 series TTL to control temperature, an Arduino is already much too complicated. There was something about the difficulty of achieving/maintaining open hardware standards, this was a more fuzzy second argument. On the way back from Honingklip we spoke about that hardware always forces a compromise. You can work, for example, on C++, but you still need to rely on something else to compile it. _______________________________________________ Debconf-discuss mailing list Debconf-discuss@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-discuss
