[Discuss] discuss Digest, Vol 9, Issue 15

Thu Feb 28 18:38:23 UTC 2013

*The way I see it, sticking the logo on something can only convey one or
two very simple pieces of information. For example, the logo could mean
that the thing it's physically on is open. It might also mean that
something inside of the thing it's on is open. If you put an arrow on it
then maybe it could indicate that something adjacent is open.*
* *
*Only extremely simple hardware projects can get away with little-to-no
documentation. Any project of useful complexity is going to have some sort
of document associated with it, and that's the appropriate place to go into
detail on what is open, and how open it is, and stuff like that. The mark
should just indicate that the project has an open component. Or, perhaps
have two marks. One indicates that something about the project is open, so
check the documentation, while the other indicates that the specific thing
the mark is affixed to is open.*
*
*
Still unclear to me who the mark is for. If it is for end-user consumers
then, for the forseeable future, the information density of the mark must
be extremely limited, as most consumers will not be able to interpret it or
know what it means. In this case the mark must provide clear direction, via
script or visible lettering, that may be used to easily find the mark on
the internet via search, so the meaning of the mark can be researched by
the minimally curious..

If the mark is only for those in the club who are versed in the secret
signs and handshakes, and know where to look for it in the secret hiding
place, then the information density may go up, as we can colour code etc to
our hearts content. But then we possibly lose access to the mark as an
advertising and marketing tool driving awareness of our efforts.

Again, who is the target market for the mark?

_________________________________________
malcolm stanley

google.voice:  215.821.6252
Cell: 267.251.9479   <------------- new
email: a.malcolm.stanley at gmail.com
twitter / linkedin: amstanley
Read my blog at http://soaringhorse.blogspot.com
_________________________________________

On Thu, Feb 28, 2013 at 12:23 PM, Matt Maier <blueback09 at gmail.com> wrote:

> David,
>
> It looks like the problem is that y'all are trying to depend on WHERE the
> logo is physically drawn for information regarding WHAT it refers to. That
> seems like an inappropriate hold-over from licenses inserted into open/free
> code. As you guys have all pointed out, where it is convenient and/or
> possible to place the logo can have very little to do with which thing(s)
> you are trying to give the consumer information about.
>
> It made perfect sense back when the entire thing was a text file, but it
> makes no sense now that the "thing" might include elements as diverse as
> text files, binary files, PCBs, chips, adaptors, and parts made out of any
> arbitrary substance (aluminum, steel, wood, etc) of any arbitrary size
> (macro, micro, nano, etc). Then you have to consider that "placing" the
> logo is actually a step in the manufacturing process, which may or may not
> make sense in the context of that particular project because it might
> require more time/money.
>
> Hardware definitions quickly become significantly more ambiguous than
> software definitions. It is possible to clearly define each and every
> detail, but it is not possible to do that merely with the location and/or
> color of a logo.
>
> The way I see it, sticking the logo on something can only convey one or
> two very simple pieces of information. For example, the logo could mean
> that the thing it's physically on is open. It might also mean that
> something inside of the thing it's on is open. If you put an arrow on it
> then maybe it could indicate that something adjacent is open.
>
> Only extremely simple hardware projects can get away with little-to-no
> documentation. Any project of useful complexity is going to have some sort
> of document associated with it, and that's the appropriate place to go into
> detail on what is open, and how open it is, and stuff like that. The mark
> should just indicate that the project has an open component. Or, perhaps
> have two marks. One indicates that something about the project is open, so
> check the documentation, while the other indicates that the specific thing
> the mark is affixed to is open.
>
> Then, of course, there's the question of what "open" means. The more
> detail you want to put into the mark the more complicated it will get and
> the harder it will be to render in the substance of the project.
>
> Good discussion, Cheers.
> Matt
>
>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 28 Feb 2013 11:09:02 -0500
>> From: "David A. Mellis" <dam at mellis.org>
>> To: The Open Source Hardware Association Discussion List
>>         <discuss at lists.oshwa.org>
>> Subject: Re: [Discuss] OSHW Best Practices / Layers of Openness
>> Message-ID:
>>         <CAMmMv3d_rw0EmUfzMAbmnZCrEga=
>> t9-aFgvtkeX+4CO2qYQ9Hw at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> These are interesting examples, Tom, but again I think they mostly point
>> out the need to be specific about what part of a product you're calling
>> open-source. For example, here I think it's clear that the PCBs for the
>> SparkFun and Arduino products (I couldn't find files for the Adafruit one)
>> are themselves open-source even if the components they use are not. I
>> think
>> we're much better off being specific about what's open and what's not
>> rather than trying to set standards for, say, the relative complexity of
>> the board vs. the components required for the overall product to be
>> considered open-source -- especially given that basically every product
>> uses proprietary components (whether ICs or radio modules or just screws).
>> The latter approach seems like a potentially endless conversation. Again,
>> look at Linux distributions, where people are still arguing about what
>> level of proprietary software and binary blobs are appropriate to include.
>>
>> Also, my point about using the logo on an enclosure vs. on the PCB inside
>> it wasn't meant as a comment on the relative importance of those two parts
>> but of the semantic interpretation of placing the logo in those places. If
>> I opened up a product and saw the OSHW logo on some part inside it, I
>> wouldn't interpret it to apply to things around it. But if I saw the logo
>> on the outside of a product, it's not clear whether or not it's intended
>> to
>> apply to the insides as well, making its use there confusing if the
>> outsides are open-source but the insides aren't.
>>
>> As an example in the other direction (of electrical vs. mechanical) would
>> be someone that uses a standard servo or DC motor and builds a complex
>> mechanical assemblage around it. If they open-sourced, say, the CAD files
>> they used to design the laser-cut parts that make up the assembly, I'd
>> consider it reasonable for them to use the open-source hardware logo on
>> their packaging or website, even if the motor were proprietary (since it
>> would be just one component of the larger, open-source design). But again,
>> these situations can be confusing and its important to be explicit about
>> what's open-source and what's not.
>>
>>
>> On Thu, Feb 28, 2013 at 7:16 AM, Tom Igoe <tom.igoe at gmail.com> wrote:
>>
>> >
>> > On Feb 27, 2013, at 12:41 PM, Michael Shiloh wrote:
>> >
>> > 1) The overall guideline might be "can someone reproduce this project
>> to a
>> > reasonable degree (e.g. functionally the same, if perhaps the case is
>> not
>> > identical) with the information provided?
>> >
>> >
>> >
>> > So, let's pick a few specific examples, all of which think highly of,
>> and
>> > use myself (admitted bias on the third). But I struggle with defining
>> them
>> > as entirely open:
>> >
>> > https://www.sparkfun.com/products/11378
>> >
>> > The major piece of hardware on this board is a proprietary module from
>> > Roving Networks.  Though SparkFun's support schematic is clearly open,
>> the
>> > module that makes this functional is not, nor is it reprogrammable. The
>> API
>> > for it is open, though. Is this OSHW?  What's the replacement part that
>> > could drop into this board and make it work, with minor modifications?
>> >
>> > http://adafruit.com/products/746
>> >
>> > Similarly, the major piece of hardware (the GPS radio) is proprietary,
>> > even though Adafruit's support schematic is clearly open. What's the
>> drop
>> > in part (note: Adafruit hasn't put the OSHWA logo on here, so it's
>> possible
>> > they don't claim this is open)
>> >
>> > http://arduino.cc/en/Main/ArduinoWiFiShield
>> >
>> > The WiFi radio on this board is proprietary, even though the support
>> > processor and its firmware and board schematics are open. This is
>> perhaps a
>> > more complex board than the other two, but I'm not sure that complexity
>> > changes things much. Or does it?
>> >
>> >
>> > Contrast those three with this:
>> >
>> > http://logos-electro.com/zigduino/
>> >
>> > This is perhaps closer to the definition than the others, in that the
>> > firmware for the radio module *is* open.
>> >
>> > My question is: do we need to differentiate between these in terms of
>> > their openness,or not?  There are plenty of other examples I could
>> pull. I
>> > know my work would suffer if I decided not to use these parts, they're
>> all
>> > staples in my work. And I'm not an open source hardware absolutist, I
>> use
>> > plenty of proprietary hardware.  But I'm genuinely not sure where the
>> line
>> > is with some of the products we make and use every day.
>> >
>> > t.
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > discuss mailing list
>> > discuss at lists.oshwa.org
>> > http://lists.oshwa.org/listinfo/discuss
>> >
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.oshwa.org/pipermail/discuss/attachments/20130228/62055ca5/attachment.html
>> >
>>
>> ------------------------------
>>
>> _______________________________________________
>> discuss mailing list
>> discuss at lists.oshwa.org
>> http://lists.oshwa.org/listinfo/discuss
>>
>>
>> End of discuss Digest, Vol 9, Issue 15
>> **************************************
>>
>
>
> _______________________________________________
> discuss mailing list
> discuss at lists.oshwa.org
> http://lists.oshwa.org/listinfo/discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.oshwa.org/pipermail/discuss/attachments/20130228/fa26cb51/attachment-0001.html>