<br><div class="gmail_quote">On Thu, Mar 7, 2013 at 11:50 AM, Matt Maier <span dir="ltr"><<a href="mailto:blueback09@gmail.com" target="_blank">blueback09@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div>Catarina,</div>
<div> </div>
<div>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. </div>
<div> </div>
<div>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.</div>
</div></blockquote><div><br></div><div>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: <a href="http://sloanreview.mit.edu/article/the-age-of-the-consumer-innovator/">http://sloanreview.mit.edu/article/the-age-of-the-consumer-innovator/</a>.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div> </div>
<div> </div>
<div>Developers, on the other hand, won't have any trouble finding the source files as long as they are actually publically available.</div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div> </div>
<div> </div>
<div>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.</div>
</div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div> </div>
<div> </div>
<div>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.</div>
</div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
<div> </div>
<div>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.</div>
</div></blockquote><div><br></div><div>Correct, just as the documentation has to change with every new release.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div> </div>
<div> </div>
<div>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).</div>
<div> </div>
<div>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.</div>
</div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
<div> </div>
<div>-Matt</div>
<div> </div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">------------------------------<br><br>Message: 2<br>Date: Thu, 7 Mar 2013 11:26:33 -0500<br>From: Catarina Mota <<a href="mailto:catarina@openmaterials.org" target="_blank">catarina@openmaterials.org</a>><br>
To: The Open Source Hardware Association Discussion List<br> <<a href="mailto:discuss@lists.oshwa.org" target="_blank">discuss@lists.oshwa.org</a>><br>Subject: Re: [Discuss] OSHW Best Practices / Layers of Openness<br>
Message-ID:<br>
<CAH-asVZtQaQsqswJjXXoPWBHtnFpxn422+WmgJvAj22fky-W=<a href="mailto:Q@mail.gmail.com" target="_blank">Q@mail.gmail.com</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>This is why I was so attracted to Tom's idea of a label that, no matter<br>
where it's placed on the product, tells you right away what parts are open.</blockquote></div>
<br>_______________________________________________<br>
discuss mailing list<br>
<a href="mailto:discuss@lists.oshwa.org">discuss@lists.oshwa.org</a><br>
<a href="http://lists.oshwa.org/listinfo/discuss" target="_blank">http://lists.oshwa.org/listinfo/discuss</a><br>
<br></blockquote></div><br>