This is first a response to @JxA’s post about the OSHW Definition
Draft and second just general thoughts brewing post-OSHW
Your definition of proto-hardware and hardware could be boiled down to ‘when do
I start inviting the world to collaborate?’ . It is a gray area that you
probably saw a lot more sharing of at OSHW due to the mutual understanding and
passion of the attendees (seriously OSHW was such an awesome time!). Your
‘proto’ seems close to platform, ‘hardware’ close proto + documentation, and
‘product’ close to hardware + usable software + full documentation. At such
early stages in design these blur, as there is another type of consumer that has
different expectations of ‘the product’.
A while ago my father asked why open source wasn’t advertised. To make a long
story short and relevant to this conversation, we agreed that the maker-consumer
cares most about the hackability of a product - to the point that the product
doesn’t really have to do anything out of the box. Seeing OSHW-stamped boxes
would inform the maker ‘hey do not worry about hacking this thing its gonna be
easier and we encourage you to do so!’. This stamp should mean the same thing
regardless of the stage of development of the product.
I am not quite sure where I am going with this, just that although I like the
direction your thoughts are going, describing something clearly that is complex
necessarily requires complex description. It is why this definition is taking a
while to solidify (though it has ‘gelled’ a whole lot in the past few months).
Defining the goals of the definition will bring about a clearer scope, which can
definitely be found through discussion like this.
If you don’t mind, I would like to link to this post and yours in the forums.
Outlining the goals of the OSHW definition will make it easier to describe
complex things in a clear manner
One goal is that compliance should alert makers ‘Hack Me!’ ( though really,
shouldn’t everything? )