[Discuss] discuss Digest, Vol 10, Issue 35

Thu Mar 7 17:36:58 UTC 2013

On Thu, Mar 7, 2013 at 11:50 AM, Matt Maier <blueback09 at gmail.com> wrote:

>  Catarina,
>
> While I agree that there is value in defining which parts/processes of
> something are open to a high degree of resolution, I'm not sure that anyone
> other than developers are ever going to use that resolution.
>
> The users won't care how much of a thing is open as long as it works, and
> they'll never even try to look for the source files. Users won't realize
> any value from a mark that defines how open a thing is at one of several
> points along a continuum from 0% to 100%. Maybe if "open" acquires some
> cultural weight like "green," but that isn't even on the horizon.
>

One of the most interesting aspects of OSHW is that it blurs the line
between users and producers. So by increasing the number of open and
hackable products we're also increasing the number of
users/hackers/producers - see for example this study:
http://sloanreview.mit.edu/article/the-age-of-the-consumer-innovator/.

The time when people will actually care about opening their products to
personalize them and adapt them to their own needs is not that far off. In
fact, it's not even a new thing. Up until 50 or 60 years ago this was
common practice. We just forgot about it because we grew up in an age of
black boxes.

Also, we're actively trying to grow, promote and solidify the OSHW
community. Saying that we're not quite there yet is not, in my opinion, a
valid reason to slack off on standards. On the contrary, if we want to
grow, we need now more than event to maintain the integrity of what OSHW
means.

>
> Developers, on the other hand, won't have any trouble finding the source
> files as long as they are actually publically available.
>

I often have trouble finding files and get very frustrated when I realize
that the files I've been hunting around for an hour or so are not actually
public even though the project is branded as open source.

>
> The source files can easily define the exact openess of the project to any
> relevant degree of resolution. I mean, that's what they're supposed to do
> anyway. So the developers won't realize any value from the mark itself
> defining precisely how open the project is either.
>

It'll help set expectations and save them the trouble of looking for the
files. The more inexperienced the developer the more important this
becomes. And we do want inexperienced developers: non-engineers, kids,
everyone.

>
> An open mark would be valuable to distinguish the project from the vast
> majority that are not open, but adding enough detail to precisely define
> just how open the thing is won't add enough value. The users won't capture
> any value because they don't care precisely how open the thing is and the
> developers won't get anything out of it because they're going to go
> straight to the source files anyway.
>

A lot of the work we do at OSHWA consists in public outreach. We tell
people that when a project is labeled as open source they have a specific
set of rights. We tell producers that they need to do this right, that
open-washing is not acceptable. I don't feel comfortable doing this if many
or any of those products are in fact falsely advertising their openness and
we're saying that's ok because no one is looking.

>
> And that's not even touching on the fact that open projects are notorious
> for changing constantly. A single open mark can always apply to a project
> even if it becomes more or less open over time. An array of open marks
> specifying different percentages would have to change along with the
> project.
>

Correct, just as the documentation has to change with every new release.

>
> I'm not sure if this makes sense, but off the top of my head what if a
> project includes an FPGA running proprietary IP. Then six months later the
> project releases their own custom open source IP to replace the proprietary
> stuff. Now the physical mark on the project isn't giving it credit for
> being as open as it actually is because the primary software was opened up
> after the hardware was shipped. It would be possible to have a mark that
> can be defaced later (like scratching off a dot) but that only captures
> change in one directly (more open to less open or vice versa).
>
> It's entirely possible that I'm missing something, but at the moment I
> don't see what benefit there is to anything more specific than a mark that
> just says "something in this project is open source." A possible exception
> is a special mark that gives the project credit for being entirely open
> source, to distinguish it from all the projects that are merely partially
> open.
>

Agreed, this could work. I wasn't suggesting that the more detailed label
needs to be on the product itself (though a sticker would make it easier to
deal with), but there should be some sort of clarity about whether or not a
project is open or partially open. And if we say it's partially open then
somewhere (on the documentation? on the website? on the product's
packaging?) we should state which parts are open source.

>
> -Matt
>
>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 7 Mar 2013 11:26:33 -0500
>> From: Catarina Mota <catarina at openmaterials.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:
>>         <CAH-asVZtQaQsqswJjXXoPWBHtnFpxn422+WmgJvAj22fky-W=
>> Q at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> This is why I was so attracted to Tom's idea of a label that, no matter
>> where it's placed on the product, tells you right away what parts are
>> open.
>
>
> _______________________________________________
> 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/20130307/dfd746e5/attachment-0001.html>